This document explains some of the design decisions of Visual ReCode, and in particular how they affect the generated solutions.
Single Service per Project
Visual ReCode allows you to migrate multiple WCF services to a single new Solution, but each gRPC service will be generated into a separate project. There are two reasons for this.
- In modern solution architecture, it is considered good practice to deploy multiple services rather than monolithic solutions. .NET Core and .NET 5 projects are easy to deploy and the overhead of running multiple services is minimal. The new projects are easier to maintain and manage.
- The generated code is cleaner, more straightforward and easier to understand.
Migration of Existing Code
The original service implementation is migrated to a new library project with the same name as the service project, which is referenced by the generated gRPC project. This allows the generated code to exist in a completely new and separate namespace, avoiding potential conflicts with types in your code.
Visual ReCode actively finds the types your service depends on and migrates it to the new solution, while leaving any code that is not required behind. This results in a cleaner new project, and may even help to eliminate old, unused code from long-running projects. The downside of this approach is that types which are not referenced directly but are used by some other means, such as reflection, may not be included in the migration and will need to be copied manually.
Workaround: Add code references to required types
You can work around this dependency detection issue by simply adding fields referencing these types to one of the classes or interfaces that is included in the migration.