Compiler errors moving from VS2003 to VS2005

[Mike Hildner]

I'm not familiar with C++ at all, but I'm attempting to convert a managed application created on .NET 1.1 to .NET 2.0.

Just opening in VS2005 and letting it convert gave 6 errors and 6 warnings - I'm worried about the errors right now.

I get an error C2371: 'WCHAR' : redefinition; different basic types on the middle line:

#if !defined(UNIX) && !defined(WIN16)
typedef WORD                WCHAR;
#endif

I looked up the error on MSDN, but I don't see where "WORD" is defined someplace else as a different type (I just searched the solution for "typedef WORD").

The other error I get is error C3459: '[System::Runtime::CompilerServices::IndexerNameAttribute]': attribute allowed only on class indexer (default indexed property)

[System::Runtime::CompilerServices::IndexerName(S"Prefixes")]

Again, I checked out MSDN, but it doesn't make sense to me. Can anyone give an explanation of what's happening and point me in the right direction to fix?

Thanks,
Mike

[BillBoeBaggins]

Is your include libraries already defining this?

[Mike Hildner]

Not that I can see - I just searched again.

BTW, this application compiles just fine using VS2003. If that makes a difference.

Thanks,
Mike

[BillBoeBaggins]

Is this code causing the error yours, did you create a new project in the new version of VS and then import the source and compile?

I wish I could be more help, almost looks like your mixing compiler specific included libs. I am still in the old days with Vis Studio 6.

[Mike Hildner]

I downloaded some code that accesses the Windows Address Book from here - http://www.sichbo.ca/DotNetCode/1204

You open it up is VS2003, compile and everything is fine. Open with VS2005, convert, and you get all sorts of troubles.

I did not modify the code at all - I guess these are issues with the compiler used in the different versions? Don't know.

Thanks,
Mike

[BillBoeBaggins]

Since your error is definitely on either a lib/include since I dont think you personally are testing for which OS is running WIN16/Unix etc.. You may have includes your project that define this variable type, and then the next one tries to define it again. Porting code from one version of a compiler (especially Microsoft IDE's) is always a venture in and of its self. I hope someone wiser then me comes along and guides you.

If it were me, I would probably comment out my includes until that specific error goes away and then slowly bring them back in (not sure if your coding your includes or using the menu).

[Mike Hildner]

Ok, thanks for the reply. I haven't coded anything myself at all, this is purely an "upgrade" issue. I can understand the warnings (which I haven't posted because they're deprecated things), but I don't understand the errors.

Very strange indeed that it compiles fine using the VS2003 compiler and blows up using the VS2005 compiler.

Porting code from one version of a compiler (especially Microsoft IDE's) is always a venture in and of its self

Yeah, I guess that's it. And I thought C++ was standardized. Shows you what I know

Thanks again for the help. I don't believe this is a C++ issue, rather, its a Microsoft compiler version issue. Great.

Mike

[Mike Hildner]

For anyone who uses VS2005, here's the info I get when converting. I'm not sure yet if anything applies. Thanks.

Visual C++ now supports a secure version of the C Runtime Library. Use of this library is turned on by default. You may see some warnings about deprecated functions when you build your project. It is advised that you correct these warnings, in order to make your code more secure.
The C/C++ compiler default settings have been modified to be more compliant with ISO Standard C++. Included in those changes are enforcing Standard C++ for loop scoping and supporting wchar_t as a native type. These changes may cause existing code to no longer compile without changes to the code or the compiler options with which it is built.
IMPORTANT: The support for CLR code in the C++ language has changed considerably with this release of Visual Studio. The 'Use Managed Extensions' property, which equated to the C/C++ Compiler switch /clr in Visual Studio 2002 and 2003, has been expanded to several values in order to support new features. /clr has been converted to /clrldSyntax for you, but there are a variety of switch compatibility issues that you need to be aware of. (For instance, /Zl was added to projects that were created with Visual Studio 2003, but may no longer be appropriate. Because it may be appropriate to your particular project we have not removed it if it existed, but you may want to). Please see MSDN for details and additional information. (You may find the topic 'Managed Extensions for C++ Syntax Upgrade Checklist' helpful).
Project file successfully backed up as 'C:\temp\AddressBook-2.0\AddressBook\AddressBook.vcproj.7.10.old'.
Project upgraded successfully.
This project is a .NET project created with Visual Studio 2003 and the C/C++ compiler switch /Zl and the Linker switch /NOENTRY are being set in the 'Additional Options' fields for those tools. This combination of switches was typically set by the Application Wizard in Visual Studio 2003 to work around a possible dead-lock condition. As this condition will no longer arise, it is advised that you remove these switches from 'Additional Options'. (Because these are valid switches to use together in other cases, they have not been automatically removed).
Projects that support the Common Language Runtime have been converted to use dynamic linking to the run-time libraries (/MDd, /MD) because the use of the statically linked run-time libraries for managed code is no longer supported. Please note that dynamically linking the run-time libraries can cause incompatibilties with code that previously relied on static linking of the run-time libraries.
Due to the requirement that Visual C++ projects produce an embedded (by default) Windows SxS manifest, manifest files in the project are automatically excluded from building with the Manifest Tool. It is recommended that the dependency information contained in any manifest files be converted to "#pragma comment(linker,"<insert dependency here>")" in a header file that is included from your source code. If your project already embeds a manifest in the RT_MANIFEST resource section through a resource (.rc) file, the line will need to be commented out before the project will build correctly.
Due to a conformance change in the C++ compiler, code change may be required before your project will build without errors. Previous versions of the C++ compiler allowed specification of member function pointers by member function name (e.g. MemberFunctionName). The C++ standard requires a fully qualified name with the use of the address-of operator (e.g. &ClassName::MemberFunctionName). If your project contains forms or controls used in the Windows Forms Designer, you may have to change code in InitializeComponent because the designer generated code used the non-conformant syntax in delegate construction (used in event handlers).