I would like to know the pros and cons of using Microsoft .NET for Industrial Software Development as against the conventional VC++/VB.

Would it be backward integrable, give a better performance, runnable on older platforms like Win 95/98/NT and integrable with my applications running in VC++/VB? Basically do I get any advantage?

 

.NET it's an excellent platform for develop automation solutions. It's really multithread, that support this in a simple way. W95 it's not supported for applications developed in .NET.

Check this URL:
http://www.htservices.com/Tools/VBandC/NET.htm

Check this thread in control.com:
http://www.control.com/998923259/index_html

And finally, check our .net modbus driver at this URL:
http://200.40.51.145/severits

Good luck!

Martin
severITS
Information Technology Solutions

 

Your question is very general, and I don't think that anyone is in a position to give you an answer for your particular situation without knowing more details than you could provide in an e-mail.

Microsoft has used the "dot Net" brand name to cover a wide range of software products, many of which were only loosely related to each other. They have recently been removing the "dot Net" brand from a number of products (e.g. their server OS) because no one could figure out what "dot Net" was. This was a classic case of over-stretching a brand.

However, you have mentioned VC++ and VB. I assume then that you are interested in programming langauges. As a very general answer then, I believe that Microsoft intends for C# to replace VB. That is, my understanding of the situation is that they intend to eventually phase out development of and support for Visual Basic and they expect current VB devlopers to switch to using C# instead. The strategy is to concentrate on one major proprietary language rather than have two minor ones.

VB and C# are intended for developing custom business applications quickly (e.g. front ends for databases). In this sense, their direct competiion is Java. C++ however is intended more for applications which must operate at the system level or which require higher performance or which must be portable. In this sense, VB/C# and C++ are not necessarily direct substitutes for each other.

As for backward integration, since Microsoft is terminating support for their older operating systems I don't think you can rely on support for them in future products. Windows 95 is already a terminated product, 98 will be terminated soon, Windows NT desktop was terminated a few months ago, and Windows NT server will be terminated at the end of this year.

Questions about "performance" are not something that is easily answered. I rather doubt that C# could match C++ in simple benchmark tests, since C# runs on a virtual machine (similar to Java) while a normal C++ compiler produces purely native code.

If you are looking for honest, unbiased performance benchmarks comparing various programming languages though, you will have a very hard time finding any on the internet. Most companies publishing performance benchmarks have a point they are paid to prove and construct their benchmarks accordingly. You may have better luck if you are looking for very narrowly constructed benchmarks, but in this case you would have to know exactly what you are looking to compare.

You also need to take a serious look at your applications and decide how important "performance" really is. In many if not most cases, operations requiring intensive computation are performed by library functions, in which case the execution speed of the application calling the library functions is not quite so significant.

A more general answer to your question may point to which progarmming languages are the most popular. There is a company that publishes a monthly ranking of the most popular programming languages. You can get the details of their methodology and criteria from their web site.

http://www.tiobe.com/tiobe_index/index.htm

According to their list, the top (most popular) twenty programming languages are in order:

1 Java, 2 C, 3 C++, 4 Perl, 5 (Visual) Basic, 6 PHP, 7 SQL, 8 C#, 9 JavaScript, 10 Delphi/Pascal/Kylix, 11 Python, 12 COBOL, 13 SAS, 14 RPG, 15 Fortran, 16 Lisp, 17 Awk, 18 Ada, 19 Prolog, 20 Scheme

--

************************
Michael Griffin
London, Ont. Canada
************************

 

No, none of the above. But you _will_ have to use it as all the vendors are committed to Microsoft. You simply won't have any choice. MS needs it for better lock-in, DRM, and other dubious schemes, so it's not optional

Regards

cww

 

1. Backward integrable: yes
2. Better performance: will depend on what your are looking for... in general VB.NET applications seem to be a lot faster than VB6. Critical real time applications should still need to be developed with C++, but you should test the .NET environment though.
3. Runnable on older platforms: not sure if on W95. All other windows versions will need the .NET runtime installed.
4. Integrable: yes, the .NET framework is backward compatible with COM/DCOM.
5. Advantages: easier to debug/install applications, great library of classes in the .NET framework, even faster than most MFC classes, no DLL hell, multiple choices of languages VB.NET, C#, J# and many others. Slower than some C++ apps but faster than java. Applications made in C# for example can be used in VB.NET without problems. There is even an open source port for Linux. Open source IDE for C# is available also.
6. Cons: slow for some real time demanding applications, no native equivalent for serial ports handling in the standard .NET framework class library, you may use MSCOMM activex control if you wish.

In summary is worth to try. Hope this helps.

R.

 

VB.net and VB (as of 6.0) are different beasts and are not compatable from what I have heard. The language had to be changed in order to support the features of .NET (Common language runtime).
VC++ should be unchanged except that with .NET you can write "managed code" or at least mangaged code interfaces that would be available from other .NET languages. You still have a compiled executable. .NET is not required on the clients for VC++ I don't think (that DONT use the managed code portions).

Having said all that. I would use .NET. Theres no reason for you not to, assuming having .NET installed on your clients is not a problem. VB is greatly improved (and I believe the C++ standard support is better). I use Linux, but .NET is the future for MS platforms.

My impression is that is is not backward compatable. VB is not, and you'd have to be carefull with VC++ to make sure you didn't use anything that wasn't supported without .NET.

Richard Higginbotham

 

Romulo Rodriguez: ...
> 6. Cons: slow for some real time demanding applications,


One should point out that "slow" and "real time" are not particularly related concepts...

"Real time" in this context means "programs can be guaranteed to meet timing requirements (whatever those are)". I wasn't aware of any mechanism to do that in VB.NET - could you point me to some docs/howtos, please? A quick google didn't turn up anything.

I was under the impression that VB.NET will execute your code when it gets around to it, which will often be quickly, but sometimes not. It'd be good to know if my impression is wrong.

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
Jiri

 

you are right... check this link:

http://www.computer.org/software/homepage/2003/s1lap.htm

regards,

Romulo

 

I do this sort of work every day for my company, DataFleet, and in a variety of languages including: C#, VB.NET, VB6, LabVIEW and other propriteary languages. We specialize in creating unique software/hardware solutions for industrial testing, automation, and data management.

Your question doesn't really allow for an easy yes/no answer. Like always, it depends on what your task is. I'll try my best to answer your direct questions first.

>backward integrable
>integrable with my applications running in VC++/VB <

I'm not entirely certain of what you mean here. If you mean this in the sense of interacting with older COM based software and components, the answer is "yes". You can usually access COM DLLs through a software wrapper that is usually created automatically by simply adding a reference to it. If your goal is to create a NET component and use it from an older COM-based application, the answer is still "yes" but it is *much* more difficult. If I needed to support a VB6 app and couldn't upgrade or rewrite for .NET, I would keep using VB6 until I could do so. Microsoft has committed to continue to support Visual Studio 6 for an unusually long time for this reason, BUT it won't last forever.

If you are interested in upgrading VB6 code, VS2003 has a great upgrade wizard that I use all the time, and the code it produces works for me 95% of the time.

>runnable on older platforms like Win 95/98/NT <

Win95/NT3.51 - no
Win98/NT4 - yes

>do I get any advantage <

Certainly, and in many ways. The new development environment is a dream to use. Everything that made it easier to create VB6 user interfaces than VC++ is now even better, and applies to all languages. Intellisense is *everywhere*, so you don't need to remember to type nearly as much as before (it even prototypes skeleton code in a very nice way). The .NET Framework has tons of functions that you used to have to write yourself (half the challenge of adopting .NET is learning to not reinvent the wheel repeatedly). Deployment is *much* easier; you can just xcopy if you want to and you don't have to worry about registering DLLs and ActiveX controls. Finally, the runtime engine does not allow you to do things that would normally crash an application, like buffer overflows and such.

One good indicator of where things are going comes right from MS. Early reports seem to indicate that the next version of Windows will have a "preference" for managed code (to promote security), and Win32 apps may run in a managed wrapper, akin to the way Win16 apps ran under Win95. If that's true, that overhead may negate any performance advantage Win32s may have (although somewhat artifically).

Of course, there are reasons to NOT use it too. The big one is hardware accessibility. If you need to write directly to hardware (such as if you are writing a driver) then you are in for some fun. You couldn't to it in VB6, nor can you do it in VB.NET or C#. I'm not a VC++.NET user, but supposedly you can do it from there. Another drawback is speed, but in my experience it isn't as bad as you might be lead to believe. As noted above, there is no direct support for serial communications but there are several vendors that offer decent .NET components for such tasks (I'm in the middle of a big serial-based project, so I have become well-versed in that subject).

Here's my highly flame-able opinion. Go to C# for future development. There are far more example apps and source code out there in C# than for VB.NET. I used to be a hardcore VB6 developer but I found there was litte difference in the learning curve between learning VB.NET and C#, so I just made the jump to the new flagship language.

Shameless plug: DataFleet does this sort of work every day, so please give our website a hit to see if there's anything we can do to help on the professional side.

http://www.datafleet.biz
[email protected]

Robert Gerhart
Director of Business and Product Development
DataFleet
[email protected]