There are many different types of projects that can be upgraded. For example, you may have a C++, web projects, console applications, control libraries, There is also many types of tools that might be part of the software stack, such as testing tools, performance analysis, source control, and so on. There is also issues with deployment options, whether you should use Click Once, MSI, or third party, such as InstallShield.
Design-Time Breaking Changes – All Changes
Design-time breaking changes impact applications only when they are migrated from Visual Studio .NET 2002 or Visual Studio .NET 2003 to Visual Studio 2005/2208, or when the application is just recompiled on the .NET Framework 2.0. They do not impact applications when they are run against the .NET Framework 2.0 but not recompiled.
See the link
Runtime Breaking Changes – All Technologies
Run-time breaking changes impact applications built against the 1.0 and 1.1 version of the .NET Framework when they run on the 2.0 .NET Framework. They can also impact applications originally built against the 1.0 or 1.1 .NET Framework and then recompiled on the 2.0 .NET Framework.
See the link
Microsoft .NET Framework 1.1 and 2.0 Compatibility
The Microsoft .NET Framework 2.0 builds on the success of the Microsoft .NET Framework 1.0 and 1.1 to provide the best runtime environment for Web and Microsoft Windows client applications. Microsoft’s compatibility goal for .NET Framework 1.1 applications is that they should work smoothly on the .NET Framework 2.0 except for a set of documented changes as provided here.
This article discusses application compatibility scenarios and provides recommendations on best practices for developers to handle compatibility issues.
Migrating from .NET Framework v1.x to Visual Studio 2008
VS 2008 – This topic lists the breaking changes in Visual C++ 2008.
VS 2005 – Breaking Changes in the Visual C++ 2005 Compiler
Breaking Changes in Visual C++ 2005
Includes the following topics
Breaking Changes in CRT
Breaking Changes in dynamic_cast
Breaking Changes in MFC, ATL, and ATL/MFC
Breaking Changes in the Visual C++ Compiler
Breaking Changes in the Standard C++ Library
Porting Visual C++ Code to Visual Studio 2005 (Note: Many of the issues still relate to Visual Studio 2008)
Visual Studio 2005 migration guide (Note: Many of the issues still relate to Visual Studio 2008)
Consuming Unmanaged C++ Class Libraries from .NET Clients
While the .NET Interop Services offer very good support to integrate C-style DLLs and COM objects directly into your C# or VB.NET code, the same is not true for unmanaged C++ class libraries. If you want to make calls into an unmanaged C++ class library, you definitely have to write a wrapper class, and you have to write it in managed C++. No way out.
In this tutorial, I will introduce a set of three sample projects to demonstrate the most basic concepts of writing a managed wrapper around an unmanaged C++ class library.
64-Bit Programming with Visual C++
64-bit Applications – General Information
Security Enhancements in the CRT
Significant enhancements have been made to make the CRT more secure. Many CRT functions now have more secure versions. If a new secure function exists, the older, less secure version is marked as deprecated and the new version has the _s (“secure”) suffix.
It should be noted that in this context, “deprecated” just means that a function’s use is not recommended; it does not indicate that the function is scheduled to be removed from the CRT.
It should also be noted that the secure functions do not prevent or correct security errors; rather, they catch errors when they occur. They perform additional checks for error conditions, and in the case of an error, they invoke an error handler (see Parameter Validation).