How Do I Migrate from X to Visual Studio 2005 / .NET
My role at Microsoft is to talk with Communications Sector customers (Media & Entertainment, print, telco, cable, wireless, etc.) about Visual Studio 2005 and the .NET Framework. We have a lot of excitement around the development platform and I am asked quite often for information on tools that can help with migration to Visual Studio and .NET. This blog post lists some of these resources with some commentary at the end with respect to purely migrating vs. refactoring / re-architecting an application.
General Visual Basic 6 to Visual Basic .NET Migration Info
Migration - Upgrading from Visual Basic 6.0
https://msdn2.microsoft.com/en-us/vbrun/ms788233.aspx
Design an Application Migration Strategy for Visual Basic 6.0 to Visual Basic 2005
https://msdn2.microsoft.com/en-us/library/aa288720(vs.71).aspx
Preparing a Visual Basic 6.0 Application for Upgrading
https://msdn2.microsoft.com/en-us/library/14w905kc(VS.80).aspx
Upgrading Visual Basic 6.0 Applications to Visual Basic .NET and Visual Basic 2005
https://msdn2.microsoft.com/en-us/library/aa480541.aspx
Visual C++ 6.0 to Visual C++ 7.1 or later Migration Info (Visual C++ 2005 is version 8.0)
From a migration standpoint, most of the improvements when migrating from Visual C++ 6.0 to Visual C++ 7.1 or later are realized due to the improvements made in CRT security and ANSI/ISO standards compliance. The availability of .NET in Visual C++ 7.1 or higher is an additional feature not a replacement for native C++ development.
This link has general migration guidance:
Migrating From Previous Versions of Visual C++
https://msdn2.microsoft.com/en-us/visualc/aa336429.aspx
The /clr compiler switch is what allows C++ code to make calls into .NET. Here is a page that covers how to include it in various scenarios:
Migrating, Porting, and Upgrading (How Do I in Visual C++)
https://msdn2.microsoft.com/en-us/library/ms235427(vs.80).aspx
Visual Studio .NET: Managed Extensions Bring .NET CLR Support to C++
https://msdn.microsoft.com/msdnmag/issues/01/07/vsnet/
Mixed (Native and Managed) Assemblies
https://msdn2.microsoft.com/en-us/library/x0w2664k(VS.80).aspx
ASP to ASP.NET Migration Info
ASP.NET Migration Home Page
https://msdn2.microsoft.com/en-us/asp.net/aa336621.aspx
ASP to ASP.NET Migration Assistant
https://msdn2.microsoft.com/en-us/asp.net/aa336624.aspx
It has a sample ASP application that can be used to try out migration before touching real code that I highly recommend going through first. The conversion tools converts to ASP.NET 1.1 but migrating from ASP.NET 1.1 to ASP .NET 2.0 isn't nearly as challenging as going from ASP to ASP.NET when purely migrating. Taking advantages of new features in ASP.NET such as the built-in support for roles, profiles functionality when migrating naturally takes some re-write.
This article covers migrating from ASP to ASP.NET 2.0 in general as well as lists some reason on why to upgrade:
https://msdn2.microsoft.com/en-us/library/ms379587(VS.80).aspx
Java to .NET Resources
Java To .NET Migration Resources Home Page
https://msdn.microsoft.com/vstudio/java/migrate/default.aspx
Microsoft Java Language Conversion Assistant 3.0
https://msdn2.microsoft.com/en-us/vstudio/aa718346.aspx
The Java Language Conversion Assistant (JLCA) is a tool that automatically converts existing Java-language code into Microsoft Visual C# for developers who want to move existing applications to the .NET Framework.
JSP to ASP.NET Migration Guide
https://msdn2.microsoft.com/en-us/asp.net/aa336627.aspx
Migration vs. Refactoring or Re-Architecting
I listed a bunch of tools above that can really help with migration. How well the tools do really depends a lot on the existing applications but there will always be some re-write required, if even just to help the tools migrate things better. I highly recommend spending a couple of days with a copy of the applications to test out how well the tools do before making decisions on how much re-write is required. Many of the tools include sample “before” and “after” application migration walkthroughs that I have personally found to be very beneficial to go through first.
Many customers see their migration efforts as an opportunity to re-factor an application and not as a pure migration-only effort. There are lots of reasons to do so such as reducing the amount of source code to maintain or increase functionality. For example, customers just now migrating to .NET have the opportunity to take advantage of the great built-in features of ASP.NET 2.0 such as Forms Authentication, Profile, and Role management, ASP.NET AJAX and .NET 3.0 technologies such WCF, Workflow, etc. (Note that the .NET Framework 3.0 is not a new runtime. .Net 3.0 is still ASP.NET 2.0---the .NET 3.0 technologies install on top of the .NET Framework 2.0 runtime.)
Also, the Patterns & Practices community effort provides a lot of documentation and code for the fundamentals like logging, configuration management, exception management, etc., in the Enterprise Library. Here are some links to consider when going beyond migration:
Enterprise Library 3.1 (May 2007):
Here is a list of the “application blocks” included in the Enterprise Library. These have been in development by some Microsoft folks and the community for several years. Many customers find it beneficial to standardize on these or a customized version of these blocks as part of their enterprise development architecture.
Caching Application Block
Cryptography Application Block
Data Access Application Block
Exception Handling Application Block
Logging Application Block
Policy Injection Application Block
Security Application Block
Validation Application Block.
You may see links and references on the Internet to the “Enterprise Instrumentation Framework”. The Enterprise Library supersedes EIF.
Here is a link to the Microsoft Patterns & Practices home page:
https://msdn2.microsoft.com/en-us/practices/default.aspx
The output of the P&P is not a product. The output of the P&P group is delivered “as-is” in source code format with documentation and samples, which includes the Application Blocks above.
COM as a Bridge between Old and New
Sometimes there is business logic provided by a component that would be just too difficult to re-write, would provide no benefit, or would only be an interim solution so not worth it. In those scenarios, COM is your friend. COM can be used as a bridge between old and new during migration. For example, VB6 can call COM objects as well as expose classes as COM objects. Likewise, .NET classes can call COM objects and be exposed as COM objects as well. So apps or objects migrated to .NET are still callable from VB .NET via COM. Likewise, it may make more sense to leave that C++ component in native C++ and access it via PInvoke or via .NET COM interop. (You may still see benefit in C++ to migrate to Visual C++ 7.1 or later for things like standards conformance).