External runners are unreliable
See original GitHub issueThe external runners (Migrate.exe, dotnet fm, msbuild) are unreliable due to several problems around different target frameworks (net461, netstandard1.3, netcoreapp2.0, etc.) and .NET implementations (Framework, Core, Mono).
The current implementation is very naive and just tries to load the assemblies and its dependencies into the current context.
Situations
The following situations can be found:
Executed from project directory
This would probably require us to use the same method, which requires the user to specify the startup project and the target project.
The following things are of interest for us:
Microsoft.EntityFrameworkCore.Design
(required bydotnet-ef
)dotnet-ef
Executed from bin/
directory
This will only work when all dependencies are available, so I suggest that we don’t support this use case.
Executed on published output
Maybe we can use DotNetCorePlugins
?
Tools
Every tool should support executing the migrations from the published output and only dotnet-fm
and msbuild
tasks should support executing migrations from source code.
Issue Analytics
- State:
- Created 4 years ago
- Comments:13 (4 by maintainers)
@livarcocc has communicated in https://github.com/microsoft/msbuild/issues/4882 that https://github.com/microsoft/msbuild/issues/1309 will be closed and work will focus on https://github.com/microsoft/msbuild/issues/1754
Overall, this is great news. I requested in https://github.com/microsoft/msbuild/issues/1309 that they support more robust .NET Core CLI Tool scenarios.
Couple of thoughts here based on some fast reading today, that I’d like to share. This might not solve our problems, but is in general good to know as it is part of the overall “knobs we can turn”:
PackageReference
s in a .NET SDK project file to be included in the bin directory: