The .NET projects generated in the initial phase of the release cycles will For migration projects (.gmproj files) containing multiple legacy projects (.vbp files), the initial translation cycles produce .NET projects (.csproj or .vbproj files) that do not reference each other or any other external assemblies besides .NET Framework assemblies. We call these stand-alone, prototype translations. They These projects can be built completely independently in any order and they are useful for upgrade assessment, code review, and initial build work, but they cannot run. In order to make them run, we need to reconfigure the upgrade solution to produce Once the stand-alone translations build, you will proceed to the Integrated Upgrade solution that produces an integrated build, wherein the generated projects depend on each other and must be built from the bottom up, dependencies first.
There are three types of challenges facing us as we do this for a given system.
...
A productive discussion of these problems and their solutions is beyond the scope of this document, but they will require a fair amount of analysis and configurations to produce a satisfactory solution.Note: some systems present special challenges that make the integrated build more difficult:
- Build Cycles: linkages between components that violated the expected build order
- Shared Files: code files that are used by several different projects
Some restructuring may be required to allow for a full system build from the bottom up.
See this article for more information on the Integrated Build