.NET vs Visual Studio 6.0

Our small engineering office is considering a move to .NET from visual studio 6.0.  I have not used .NET yet, and have gathered information anecdotally.  I am excited about the new technology like everyone else but I'm thinking of advising caution, or at least a very gradual phasing out of 6.0, for the following reasons:

(I'm scoring this high to collect as many thoughts as possible; if I'm lucky and this starts a lively discussion, I will split the points among the helpful or thought-provoking responses.)

* we have lots of expertise in VS6.0 which will be forfeited on the move (because .NET is very different then 6.0) (in fact my first project with any drastically different technology is always subpar -- so I'm going to pick that battle carefully)
* we still have lots of legacy code in visual studio 6.0, and we need to retain expertise in it (again, because .NET is very different)
* about one-third of our software is QA/safety software, bugs are very bad.  My instincts tell me that it pays to stay with a more established framework -- simply more mature, fewer bugs
* in order to deploy your .NET apps to a new platform with most current windows OSs, you have to install a big .NET framework component (like you used to have to do in the early 90s for the VB engine) (true?); this will not be true with new windows releases to be sure, but this is a consideration right now
* Microsoft office uses VBA, which is only (as far as I know) VB6.0 based, not .NET based.  It helps us (we do a fair amount of quick-and-dirty excel, access VBA stuff) to stay in sync with that.
* VS6.0 isn't going anywhere -- there are still more people making new code with it than with .NET (true or false?), and there is still more support for VS6.0 than .NET (for example, on this fourm)

Any thoughts?  Are any of these plain wrong?  Are the overwhelming advantages?  How fast should we move from 6.0 to .NET?  Please, any thoughts are welcome.  
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Just what came in mind to me, not sorted in any way - may it help you:

I'm working with the .net framework since it came out and in parallel also with other environments (vb6, vc6, evc3, evc4, ...) and in general I find the framework good to use and would recommend it for most new development projects.

When talking about Visual Studio 6.0 you have to clearly differentiate between VC6 and VB6 programs. You may be able to re-use programs written with VC6 because there is also native VC7 (without .net support) with MFC and ATL in VS.NET 2003. Most VB6 programs cannot be reused and must be ported to VB.NET if VB should be continued.

The .net framework 1.1 is already deployed with current Windows OS's, so that won't be a big impact when releasing your software. The term "big" is relative when you know what it does for you (the programmer)!

Especially if you've written much VC6 code, writing software in C# is much less error-prone than the same in C++ because the language is designed differently and the .net fx has also much stuff to support you. Microsoft incorporated also other good stuff from other languages like Delphi or Java into the language. C# is my preferred language to go in .net.

I think on this forum there are still many people working with VS6 and also many people working with .net. I can't really tell you, you can't give it to one of those groups.

Is that VBA stuff in Office related to macros or could you do that from external programs also? You could write .net to control Excel, write add-ins, etc.

I did not get the point about your QA/safety software. Is that a bug tracking software or is the software full of bugs?

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
riceman0Author Commented:
Interesting about the difference in migrating from VC and VB.  Good stuff, thanks.

I've recently installed .NET and will learn more soon.  I see when you start it up that you can create a new VB, VC, or C# project.  Is the VC project the 'Vc7' you refer to, w/o .NET support, that I could "re-use" my VC6 programs in?  Is there some work in that re-use?  Or could I actually open my VS6 project in .NET studio and seamlessly continue working on it w/o the .NET framework?

About C#, I think of VC6 as hard-to-develop-with, but the end result is very fast.  VB6 as fast to develop with, but the end result always seems slightly sluggish.  Where does C# fall in that spectrum?

Yeah, I think the office macros and VBA are the same thing.  I mean when you are in excel or access (or word, for that matter), you open the tools, macros, visual basic editor -- that's the same syntax as VB6.0, but with included application objects like cells or tables.  It's very handy when you're crunching data.  If all of our engineers go to .NET and we lose familiarity with writing VBA macros that would be an issue.  I've heard VB.NET is very different, and I wonder -- will MSOffice start using .NET for its macros?  Now/soon/later/never -- I have no idea, have you heard?

QA or safety-related software is just a term we use for software that must work, for example for industrial or medical applications, you must demonstrate/prove/argue that it is bug free to a higher standard.  Part of our argument for using the VC6, MFC, ATL (and sometimes even the VB6 stuff) for safety-related things is that it has been around and long time and is very stable.  It's a pretty good bet that the .NET framework, not having been around very long, at this point has a lot more plain bugs.  Or is there some reason why that's not the case?

Appreciate the ideas...
>>QA or safety-related software is just a term we use for software that must work, for
>>example for industrial or medical applications, you must demonstrate/prove/argue that it is
>> bug free to a higher standard

There you have a key issue. Going to .NET also means a change in the programming paradigm, in terms that you are using a P-Code interpreter (CLR or "runtime environment" is just a different word for that) . Apart from "only" that, "Managed C++" is not "ANSI C++". So, in terms of that QA rules, you have to rely on that CLR being conformant. BTW, just as a side note - you are aware that you can still code rock-solid, unmanaged and standard-conforming C++ with VC++7.1.NET, aren't you?
Microsoft Azure 2017

Azure has a changed a lot since it was originally introduce by adding new services and features. Do you know everything you need to about Azure? This course will teach you about the Azure App Service, monitoring and application insights, DevOps, and Team Services.

riceman0Author Commented:

Thank you.

Interesting... so the CLR -- developed recently?? by microsoft?? -- has a couple more layers, i.e., the "management" than plain ANSI C++, that you have to trust.  You're right that sounds like a big deal and I'm sure the industry's already evaluating this, do you know of any references/articles with a good discussion of this?  (I'm not even sure I know enough terminology to google that...)

Also, as an aside, do those additional layers result in a lower-performance end product?  Along the lines of VB?

No, I wasn't aware of your last point... CV++7.1.NET is ANSI C++, therefore not as much a QA concern?  I'll repeat the question I asked Zamba... can I seamlessly port my VC++6.0 apps into it?

Um, just in case there is a misunderstanding here:

.NET is a runtime evironment that interprets code written in a multitude of languages (C#, J#, Visual Basic, ASP, "Managed C++" etc.).

VC7.1 also supports that *cough* "old style C++ programming" (aka "unmanaged C++"), which in fact only means that you get a way more ANSI-C++ compliant compiler than compared with VC6. Actually, be afraid of the amount of compliance to the standard, since fixing things that the previous version allowed to do is probably going the cause a slight initial annoyance with the compiler :o)
Sorry, please read

VC7.1 also supports


VC7.1 of course supports

riceman0Author Commented:

Okay, so I should change my  

"VC++7.1.NET is ANSI C++"


"VC++7.1 .NET supports ANSI C++" right?  Or... what was my apparent misunderstanding?

Any thoughts on :
1) reference/articles/sources for more info on QA concerns with CLR-based development,
2) performance of "managed" C++ vs "unmanaged" C++, or
3) ease of porting VC++6.0 to VC++7.1 .NET

Again, appreciate it.
Well, it still depends on what you want to do - a change to the .NET framework will be a *big* deal.

Migrating your "regular" C++ does not have to be easy, but if you aren't using templates extensively, you might be lucky enough to just have the IDE convert the "old" project file and  compile without errors.
riceman0Author Commented:

Zamba said something about "native VC7 (without .net support) with MFC and ATL in VS.NET 2003".  Is this the same as  VC++7.1.NET?  And if so, then porting VC++6.0 to VC++7.1 shouldn't be "to the .NET framework", right?  (I guess in my question 3 above I meant porting to the .NET studio IDE, but not to the .NET framework... which was possible in my imagination)

OR when you said "to the .NET framework" above did you just mean "to the .NET IDE"... again I thought I heard these are two different things... ?  (I mean just working through the .NET IDE vs. actually using .NET, managed objects, whatever libraries .NET offers...)

These probably sound like dumb questions, I really need to just start using it but don't have time right now.  
Just to get that straight: VC++7.1 (as 7.0) is a fully fledged C++ compiler that does not require you to port to .NET. You might encounter some difficulties, but nothing that cannot be solved.
riceman0Author Commented:

In .NET, I say "new projects", under Visual C++ projects I see .NET, ATL, and MFC projects.  I think I see what you mean now.  

You guys have earned the points, but any thoughts on:

1) more thoughts, or references/articles/sources for more info on QA concerns with CLR-based development,
2) performance of "managed" C++ vs "unmanaged" C++

I would second most of what jkr already said.

I have recently converted a few of my projects from VS6 to VS .NET 2003, and overall the experience has been positive. In each case, the project was converted automatically without having to start from scratch (though these are simpler projects), and the project compiled after a few changes. The most noteworthy change I had to make was to replace all the old-style include files such as <iostream.h> and <fstream.h> with the new standard compliant <iostream> etc. In some cases if you are using older syntax, that would break and editing of the code is necessary.

Re. your specific questions:

(1) The best source of online information of that type is probably MSDN magazine (http://msdn.microsoft.com/msdnmag/) Their "Back Issue Archive" is particularly useful. For example, I did a random check and found that then March 2003 issue (http://msdn.microsoft.com/msdnmag/issues/03/03/default.aspx) contains at least two artciles of interest. There are many others in other issues.

(2) I have so far been pleasantly surprised by the performance of code produced by the .Net 2003 compiler. (Speaking strictly now of traditional C++, not "managed C++" and not C#), I have noticed on average about a 10% improvement in execution speed vs that produced by VS6. This is probably in part due to the newer compiler taking advantage of the newer chip architectures. I would expect "Managed C++" to be slower than just C++, but can't quantify that.

Some other thoughts in no particular order: I am still finding the new GUI a bit awkward, but like the new larger font a lot.

This is probably not something that applies in your case, but I have a lot of Fortran code, and that works a whole lot better with VS6 than with VS .Net. In fact just for that reason I know I will never switch many of my projects to VS .Net. At the same time, any new projects that involve just C++ will be done using the .Net compiler.

Have not played at all yet with "Managed C++" or C# beyond a few sample programs, so can't comment on the CLR.
Here are two general links about .net:
.net introduction: http://www.learnxpress.com/modules/dotnetrc/csharp_show_1.html
How the CLR works: http://samgentile.com/Default.aspx?tabid=30

Especially the second article is interesting when it comes to performance.

I can't tell you anything about managed c++ since I haven't used it up to now.

Regarding the managed performance from my point of view, I haven't observed any performance breaks of my C# programs and services yet. Most of it depends on the particular implementation. For example when creating lots of strings parts instead of using a StringBuilder, you can bring your app also down and you can't blame .net for it, you just haven't used it correctly. Things like this are the important ones to consider when using .net managed code.

> OR when you said "to the .NET framework" above did you just mean
> "to the .NET IDE"... again I thought I heard these are two different
> things... ?  (I mean just working through the .NET IDE vs. actually using
> .NET, managed objects, whatever libraries .NET offers...)

I have to comment on this. ".net framework" means the .net class library and everything needed to run .net programs. This does _not_ include any development IDE or or editing tool. You can write your .net programs with Notepad, if you wish. But you cannot create c++ apps without installing Visual Studio, because this includes the c++ compiler (as it did before).
riceman0Author Commented:
Thanks guys, wish I could distribute more points.  I'm continuing my QA question as another open-ended question, if you're interested...
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Development

From novice to tech pro — start learning today.