vb2005 to vb2008 express

  • Thread starter Thread starter Galen Somerville
  • Start date Start date
G

Galen Somerville

I converted a VB6 to VB2005 pro awhile back. Had to dump it because it
wouldn't handle my real time data fast enough.

I decided to try VB2008 Express. Brought my old VB2005 app in from a backup
DVD.

It builds quickly with no errors but fails to launch with "Does not support
debugging the code type specified by the project".

Changed compile to net 2 but no help. I understand that net 3.5 is backward
compatible to net 2 (for what it's worth).

So, can I delete all of the VB2005 files except the actual Forms and modules
(xxxx.vb) and start a new VB2008 with them?

Or other suggestions

Galen
 
Galen Somerville said:
I converted a VB6 to VB2005 pro awhile back. Had to dump it because it
wouldn't handle my real time data fast enough.

I decided to try VB2008 Express. Brought my old VB2005 app in from a
backup DVD.

It builds quickly with no errors but fails to launch with "Does not
support debugging the code type specified by the project".

Changed compile to net 2 but no help. I understand that net 3.5 is
backward compatible to net 2 (for what it's worth).

So, can I delete all of the VB2005 files except the actual Forms and
modules (xxxx.vb) and start a new VB2008 with them?

Or other suggestions

Galen
Click to expand...
Consider trying VS 2008 Professional by downloading the free trial, then see
what happens with your VS 2005 project.

http://msdn2.microsoft.com/en-us/vstudio/products/aa700831.aspx
 
I converted a VB6 to VB2005 pro awhile back. Had to dump it because it
wouldn't handle my real time data fast enough.

I decided to try VB2008 Express. Brought my old VB2005 app in from a backup
DVD.

It builds quickly with no errors but fails to launch with "Does not support
debugging the code type specified by the project".

Changed compile to net 2 but no help. I understand that net 3.5 is backward
compatible to net 2 (for what it's worth).

So, can I delete all of the VB2005 files except the actual Forms and modules
(xxxx.vb) and start a new VB2008 with them?

Or other suggestions

Galen
Click to expand...

Why don't you backup existing VB2005 projects? Then see the behaviours
on VB 2008.
 
kimiraikkonen said:
Why don't you backup existing VB2005 projects? Then see the behaviours
on VB 2008.
Click to expand...

I erased all evidence of VB.net long ago.

I just pulled this VB2005 project in off of a June 2007 full system backup,
I'm halfway through a download of VB2008 Pro trial at this moment. VB2008
Express has been deleted.

Galen
 
PvdG42 said:
Consider trying VS 2008 Professional by downloading the free trial, then
see what happens with your VS 2005 project.

http://msdn2.microsoft.com/en-us/vstudio/products/aa700831.aspx
Click to expand...

Well you are correct. The VB2005 app works fine under VB2008 Pro.

But it has the same problem. The app is a Heart Sound Simulator and normally
runs at 75 BeatsPerMinute (BPM) in VB6. With animals and birds it runs well
up into the area of 250 BPM. The trace display is similiar to an
oscilloscope display in real time.

The data comes from a USB proprietary device using Jungo drivers. With the
Jungo net drivers (way back in 2007) the best I could get was 0.5 BPM. So I
made a VB6 transmitter/receiver with shared memory and the app sets up a
thread for the USB calls.

This gets me up to about 2 BPM and VB2008 does the same. Jungo is at least
three versions higher now so I will try their new net drivers and see what
happens.

Galen
 
Hi Galen,

You said, "The data comes from a USB proprietary device using Jungo
drivers. With the
Jungo net drivers (way back in 2007) the best I could get was 0.5 BPM. So I
made a VB6 transmitter/receiver with shared memory and the app sets up a
thread for the USB calls.""

By this, do you mean that you created a VB6 ActiveX dll, and then call that
dll (and wait for responses) in a .NET thread? If so, did you set that
thread priority to HIGH? Realize the COM marshaling is rather slow in .NET,
and there may well be another level of marshaling in the Jungo drivers.
Shared memory may be the most efficient way to pass data back to your .NET
app -- on the surface, this seems intuitive. However, that might not be so.
It might be more performant to call such code directly (perhaps via a
Windows forms Timer), than in a worker thread.

If, however, your VB6 ActiveX object is an EXE... (Thus, the ability to
"thread" on the VB6 side), I suspect that your performance will be poorer
than the attack that I've outlined above. Of course, without actually
trying it, I'm only speculating. However Ax EXEs are out-of-process, and
actually are much slower than Ax dlls (in-process), due to the extra level
of marshaling.

Dick

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
See www.hardandsoftware.net for details and contact information.
 
Dick Grier said:
Hi Galen,

You said, "The data comes from a USB proprietary device using Jungo
drivers. With the
Jungo net drivers (way back in 2007) the best I could get was 0.5 BPM. So
I
made a VB6 transmitter/receiver with shared memory and the app sets up a
thread for the USB calls.""

By this, do you mean that you created a VB6 ActiveX dll, and then call
that dll (and wait for responses) in a .NET thread? If so, did you set
that thread priority to HIGH? Realize the COM marshaling is rather slow
in .NET, and there may well be another level of marshaling in the Jungo
drivers. Shared memory may be the most efficient way to pass data back to
your .NET app -- on the surface, this seems intuitive. However, that
might not be so. It might be more performant to call such code directly
(perhaps via a Windows forms Timer), than in a worker thread.

If, however, your VB6 ActiveX object is an EXE... (Thus, the ability to
"thread" on the VB6 side), I suspect that your performance will be poorer
than the attack that I've outlined above. Of course, without actually
trying it, I'm only speculating. However Ax EXEs are out-of-process, and
actually are much slower than Ax dlls (in-process), due to the extra level
of marshaling.

Dick

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
See www.hardandsoftware.net for details and contact information.
Click to expand...
Briefly the USB driver is a net exe that uses an activex dll to grab the
timed bursts of data. So it's the net exe that is on a separate thread with
shared memory.

When just sending/receiving control data, the exe talks to the USB device.

I'm looking at the whole shebang again using VB2008 pro

Galen
 
Back
Top