stay in vb6, or move to csharp?

  • Thread starter Thread starter Elhanan maayan
  • Start date Start date
E

Elhanan maayan

hi all..

i work in a company that deals with mainly with hardware devices via serial
comm port. up untill most of the software was writeen in plain old dos c.

that company is planning to move it's applications to windows. the
applications themselves are rather small, they usually just extract binary
data from devices store them in a database or a file and present them in a
report format. the application are being distributed sold outwards, and not
developed for the company itself, so ease of distribution is important (we
have install shield express x).
 
Whether you use C#, J#, S#, VB.NET, Eiffel.NET, COBOL.NET, or whatever .NET
compiler you might choose, it all uses the same common language runtime.
Your language choice boils down to a matter of personal preference and
potentially, whatever minor advantages a particular language syntax might
afford you in your particular environment. For example, VB.NET is slightly
easier to do late binding with; Eiffel kludges multiple inheritance on top
of the CLR, and so forth.

Obviously those of us on this particular newsgroup prefer C#, for reasons
good, bad and indifferent.

Since your legacy code is written in C, it would seem to me that porting to
C# would be your easiest route and your shallowest learning curve. There is
really nothing compelling about VB.NET that I can see for your scenario.

--Bob
 
After everybody told you that .NET and C# are good I have to come with some
drawbacks.

If you are using .NET, you have to ship the .NET framework (~20mb) along
with your apps.
Also, everybody can simply decompile (not just disassemble!) your programs.
Using obfuscator tools will obfuscate some identifiers but does not really
get rid of this problem.
Additionally, if you plan to make your programs run under another OS you
cannot use .NET (at least if you are using a GUI).

These 3 are the big disadvantages that I can see with .NET, but there are
much more advantages for example a big class library, fully
interoperability, safety, security and less debugging.
 
Additionally, if you plan to make your programs run under another OS you
cannot use .NET (at least if you are using a GUI).
Click to expand...

That is a bit of a non-issue. If you write a GUI specific to any platform in
any langauge, you are out of luck. If you can choose a cross platform
library in C++, you can choose one in .NET(I think wxWindows has a .NET
library\wrapper out now, and there is GTK#).

Also, VB6 doesn't have any support on other OS's, so .NET would be *more*
support than the other option suggested in the title.
 
Elhanan maayan wrote:

[...snip...]
i work in a company that deals with mainly with hardware devices via serial
comm port. up untill most of the software was writeen in plain old dos c.
Click to expand...
[...snip...]

IIRC, C# does not support serial communication out of the box, though there
are some (free / commercial) solutions available (mostly PInvoke, I guess).
Not much of a problem, I'd think, but .NET 2.0 might be able to support
serial communication without having to manually invoke os resources.

Someone who knows better ?
 
Michael Voss said:
Elhanan maayan wrote:

[...snip...]
i work in a company that deals with mainly with hardware devices via serial
comm port. up untill most of the software was writeen in plain old dos c.
Click to expand...
[...snip...]

IIRC, C# does not support serial communication out of the box, though there
are some (free / commercial) solutions available (mostly PInvoke, I guess).
Not much of a problem, I'd think, but .NET 2.0 might be able to support
serial communication without having to manually invoke os resources.
Click to expand...

Yup - see http://msdn2.microsoft.com/library/System.IO.Ports.aspx
 
IIRC, C# does not support serial communication out of the box, though there
are some (free / commercial) solutions available (mostly PInvoke, I guess).
Not much of a problem, I'd think, but .NET 2.0 might be able to support
serial communication without having to manually invoke os resources.

Someone who knows better ?
Click to expand...

Under framework 1.1 I use the same ActiveX control that VB6 is using
MSCOMM32.dll.

Jamie
 
Hi,

I may be get excomulgated : ) but...

why don't just change to C++ for win, as per your description the core of
your system is serial com. nothing to do with UI so it should be pretty easy
to convert to a win32 dll or COM.

For the UI you can use either MFC or even VB6 ( now my soul is definely
lost )

If you want to learn .NET you can use the win32 DLL or COM created with the
serial comms lib. and use Crystal Reports for the reports.

Anyway, the thing is that you have several paths to develop you have to
select the best based on the current knowledge base and future directions.

Cheers,
 
Hi,


I think that those are not the biggest problems, but the codebase and the
knowledge of the programmers, they know C for sure
and the code base itself which is C code, this is easier to convert it to a
win32 DLL or COM object, if written in C/C++ they should work almost with no
change.
IF they convert them to c# the old codebase will have to be discarded and
rewritten from scrash.

Those I think should be the main consideration, if they want to move to a
managed environment they can keep the core in win32 and write the UI apps in
..NET to make the transition more smooth.

Cheers,
 
Hi,


IIRC, C# does not support serial communication out of the box, though there
are some (free / commercial) solutions available (mostly PInvoke, I guess).
Not much of a problem, I'd think, but .NET 2.0 might be able to support
serial communication without having to manually invoke os resources.

Someone who knows better ?
Click to expand...

IMO it does not matter that much if the framework itself does not support
it, you have several well documented and FREE implementations
(opennetcf.org ) of serial communications. You can use them with no problem.
The 2.0 provide serial functionality but unless you wait until it's released
you will have to use one of the current implementation, and after doing so,
why change it to use the framework's implementation?

Cheers,
 
Ignacio Machin ( .NET/ C# MVP ) said:
Hi,

I may be get excomulgated : ) but...

why don't just change to C++ for win, as per your description the core of
your system is serial com. nothing to do with UI so it should be pretty
easy
to convert to a win32 dll or COM.

For the UI you can use either MFC or even VB6 ( now my soul is definely
lost )
Click to expand...

I tend to agree, although there is no reason to avoid managed C++ to create
unmanged nad managed interfaces to your core code and the use C# for
wrappers.
 
Back
Top