Migration Information Visual Studio 2008 and Earlier (C#, .NET, C++)

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


Detailed Links

ASP.NET Design-Time Breaking Changes

C++ Design-Time Breaking Changes

C# Design-Time Breaking Changes

CLR Design-Time Breaking Changes

J# Design-Time Breaking Changes

System.Data Design-Time Breaking Changes

Visual Basic .NET Design-Time Breaking Changes

Visual Studio Design-Time Breaking Changes

Windows Forms Design-Time Breaking Changes

XML and Serialization Design-Time Breaking Changes

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


Detailed Links


ASP.NET Run-Time Breaking Changes

ASP.NET Run-Time Breaking Changes

CLR Run-Time Breaking Changes

Enterprise Services Run-Time Breaking Changes

Fusion Run-Time Breaking Changes

Localization Run-Time Breaking Changes

System.Data Run-Time Breaking Changes

Visual Studio Tools for Office Run-Time Breaking Changes

Windows Forms Run-Time Breaking Changes

XML and Serialization Run-Time Breaking Changes

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).

Skip to main content