For migration projects (.gmproj files) containing multiple legacy projects (.vbp files), the initial translation cycles produce .NET projects (.csproj or .vbproj files) that will 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 multi-project system.
...
A productive discussion of these problems and their solutions is beyond the scope of this document -- they require a fair amount of analysis and configuration of the translation scripts 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