Thread: Warning to all those wishing to port to .NET 2005

In a word, don't do it.

It's an absolute mess. The entire C standard library has been declared as deprecated which adds a million warnings to your builds. Linking with vc80 runtimes is a major pain in the ass and converting your project from 2003 or MSVC 6 to 05 is equally as painful.

So far I've attempted to port my DLLs and my engine code to no avail. MFC also does not work. Always get application configuration error even doing what people have told me to in order to get it to work.

C libraries are no longer linked statically but dynamically and one website even suggested copying the libraries into the same folder as your project. This is a huge mess and I hope they sort it out soon.

Lots of people, according to what I've seen on the net, are having a lot of trouble porting from 6.0 and 2003 to 2005. I was going to port my recent projects over but I'm going to reinstall MSVC 6 because I have no time to sort out stupid manifest issues when I know the code works.

My advice - don't port anything of importance over to 2005. Finish it with what you have and then use 2005 for brand new projects.

My buddy at at&t has also had problems with porting VB 6 and 2003 over to 2005, and just even porting 6 to 2003.

I would not recommend it.

http://developers.slashdot.org/artic.../09/27/1653224


Will some company please step up and save C/C++ before MS destroys it or turns it into one of their own crap-ridden bloated code bases?

The deprecated issue extends to c++, too, Bubba. I was more than a little surprised to get a 'deprecated' error message while using std::string::copy:

Originally Posted by borg assimilator 2005

warning C4996: 'std::basic_string<_Elem,_Traits,_Ax>::copy' was declared deprecated....

It seems the 'default' msvc 2005 behaviour is to force their(ms) 'standard' rather than accomodate the actual c++ standard. I found myself wondering wtf's the point of having a standard if it isn't actually adhered to in practice(rhetorical!)? Since then I've read a number of takes on this issue, few of them flattering.

Stroustrup: What do you think of C++/CLI? (the uk objection pdf linked to on that page is very interesting but was apparently summarily dismissed by the ECMA (read the 'answer' pdf given on same page).

Here's a couple more from the register:

C++/CLI: a paradigm too far
C++ divided by CLI

I have considerable empathy with the view that c++ is a complex enough language to learn without arguably the most popular compiler on the planet, now free in the form of the 'express' edition, essentially confusing the hell out of anyone and everyone who uses it by issuing what are essentially false errors or warnings.

So, okay, I'm not a professional so ultimately it doesn't really matter to me. I would be interested, however, in the opinions of the professionals and proto-professionals who have to contend with this sort of thing.

For those whom it concerns or anyone interested, this msdn2 page:

http://msdn2.microsoft.com/en-US/library/y9ww7c1a.aspx

goes some way towards describing how to disable this particularly invidious annoyance from Bill & Co. - essentially more preprocessor cluttering until/unless a global compiler/linker switch setting that will do the same can be located.

Thanks, Bubba, for raising this issue.

This page describes how to restore standard c (c89) behaviour:

http://msdn2.microsoft.com/en-US/library/8ef0s5kh.aspx

In short: #define _CRT_SECURE_NO_DEPRECATE (use /D switch).

Well, it's always good to know that:

Originally Posted by msdn2

...these functions are now deprecated...

(more here).

Don't get me wrong - I'm all for improvements in code security (the rather amusing irony of ms offering advice on this subject aside), and it may be that these 'secure' functions are possibly a step in the right direction. I just have a strong objection to having such language extensions set by the compiler by default with misleading descriptions, warnings and errors such as I have quoted above, which are sure to fool the unwary into assuming that such extensions are, in fact, intrinsic to the languages of c and c++.

I wonder just how long it will be before the c and c++ boards here are inundated with posters insisting that perfectly legal standard c or c++ functions are 'deprecated' because the various manifestations of msvc2005 have told them so.

I used that flag and it took care of the deprecation. The execution problem still remains.

This would be a good time for a company to release a pure ISO-conformant C/C++ compiler. Visual Studio is such a hunk of Windows evangelism it's pitiful. And now they are attempting to change C++. Don't be fooled, MS is trying to change the language ever so slowly. After all C++/CLI prob does run better, but only on their stuff. It is not cross-platform and as such it cannot be labeled a universal computer language. It is a proprietary computer language.

I have no problem coding for Windows and making API calls here and there, but to actually add keywords to the language is way beyond the line in my book. Arrogant, stupid, assinine, and 100% confusing. I should throw this 2005 in the trash.

This new move will confuse a lot of people and yes we will be swamped very soon with a lot of posts relating to this very issue as well as game programming posts about doing lighting in Direct3D since DX10 does NOT support FFP lighting.

I love C/C++ and this all just makes me sick. We all know and everyone on the net, it seems, knows that MS code is some of the most bloated, hard to read and inefficient code out there. Now I'm supposed to trust them with C++/CLI? No thanks.
Bjarne was not promoting an operating system with C/C++. Microsoft's 'extensions' to the language are.

Interesting links/articles. Thanks for the info.