Conflict resolution from desktop MSBuild fails to get assembly identity from cross-gen'ed linux binaries
See original GitHub issue- Crete a new console project.
- Modify the contents to the following.
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp2.0</TargetFramework>
<RuntimeIdentifier>centos.7-x64</RuntimeIdentifier>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="System.Threading" Version="4.3.0" />
</ItemGroup>
</Project>
- dotnet restore
- dotnet publish --> works correctly
- msbuild /t:publish --> app will fail to start with a refdef mismatch for System.Threading.
This is because the System.Threading.dll conflict isn’t being resolved. If you examine the log you’ll see
Encountered conflict between 'CopyLocal:C:\Users\ericstj\.nuget\packages\runtime.linux-x64.microsoft.netcore.app\2.0.0\runtimes\linux-x64\lib\netcoreapp2.0\System.Threading.dll' and 'CopyLocal:C:\Users\ericstj\.nuget\packages\system.threading\4.3.0\lib\netstandard1.3\System.Threading.dll'. Could not determine a winner because 'CopyLocal:C:\Users\ericstj\.nuget\packages\runtime.linux-x64.microsoft.netcore.app\2.0.0\runtimes\linux-x64\lib\netcoreapp2.0\System.Threading.dll' is not an assembly.
Compare this to the following in dotnet publish:
Encountered conflict between 'CopyLocal:C:\Users\ericstj\.nuget\packages\runtime.linux-x64.microsoft.netcore.app\2.0.0\runtimes\linux-x64\lib\netcoreapp2.0\System.Threading.dll' and 'CopyLocal:C:\Users\ericstj\.nuget\packages\system.threading\4.0.11\lib\netstandard1.3\System.Threading.dll'. Choosing 'CopyLocal:C:\Users\ericstj\.nuget\packages\runtime.linux-x64.microsoft.netcore.app\2.0.0\runtimes\linux-x64\lib\netcoreapp2.0\System.Threading.dll' because AssemblyVersion '4.1.0.0' is greater than '4.0.11.0'.
It would seem that the desktop implementation for getting the assembly version can’t handle the cross-gened assemblies, however the core implementation can.
Issue Analytics
- State:
- Created 6 years ago
- Reactions:3
- Comments:32 (31 by maintainers)
Top Results From Across the Web
MSB3277: Found conflicts between different versions of ' ...
This error occurs during a build when more than one version of the same dependent assembly is referenced in a build of the...
Read more >Found conflicts between different versions of the same ...
Go to Tools->Options menu in VS · Open Projects and Solutions->Build and Run · Change the value of the MSBuild project build output...
Read more >https://raw.githubusercontent.com/dotnet/samples/m...
Append); ``` You get an exception **FileStream will not open Win32 ... Included also are the assemblies and executables that are used as...
Read more >.NET Blog - RSSing.com
In ML.NET 0.10 we have segregated the IDataView component into a single assembly and NuGet package. This is a very important step towards...
Read more >目录
Secondary AppDomains are not supported on .NET Core. API such as AppDomain.CreateDomain will throw PNSE. Consider alternative isolation.
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
I think it would be interesting to look into using
ILLink
for task assemblies. Merge and tree-shake all dependencies of a task except for MSBuild assemblies into a single DLL. Then we would not have any versioning issues.Spoke to @tmat offline about @jaredpar’s specific concern of just having a mismatched S.R.M or S.C.I on disk in VS install breaking VS ngen. It seems to not be an issue here because the directories probed are defined in vsn.exe.config. There are various copies of different versions in Program Files\dotnet (where we install, not in the list) and they haven’t ever triggered a VS NGEN break.
So I think we can carry v1.5.0 and use it on a fallback path (so that we don’t load / JIT unnecessarily). And without any app-domain or assembly resolve shenanigans.
I think there’s non-negligible risk here, but I’m not seeing how to fix this bug without taking it.
I do like the idea of static linking things like nuget and srm into the build task at some point, but I don’t think we can afford to make that a pre-req of this bug fix.