-
Notifications
You must be signed in to change notification settings - Fork 86
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NuGet version conflicts #127
Comments
Are you seeing this with a specific version of the .NET SDK? This sounds like something we're hoping to fix in MSBuild itself in dotnet/msbuild#6377 that would affect 5.0.300 and 6.0.100-preview builds. I'm hesitant to take this change because MSBuild does some internal ALC manipulation relating to loading plugins like task assemblies, and I don't know if this would confuse it. But I don't know of any problem that it would cause so "working well for you" is a pretty good data point. |
Interesting, thanks for the link to the MSBuild issue, it might be related. I could do a simple repro project with the following versions:
The repro project uses NuGet 5.8.0, then call MSBuild Locator and run a |
I also had a nuget package problem, seemed to be the same problem, details: dotnet/roslyn#61454 |
That definitely looks like the same problem. You can try if |
@baronfel thanks, I tried while it did not work for me 😭 |
Does this ticket belong to MSBuild.Locator? I can see the attached tickets in Roslyn repo. |
Our project references NuGet API directly.
However, since MSBuild also needs its own specific version of NuGet, this results in runtime conflicts (i.e.
Error: The "ResolvePackageAssets" task failed unexpectedly.
).So far I found a workaround which is to override
AssemblyLoadContext.Default.Resolving
but then internally do the assembly loading in anotherAssemblyLoadContext
.It seems MSBuild works fine with that, and I can still use my
PackageReference
to a specific version of NuGet.I am still investigating if there's a better way to do that.
Would the project accept such changes?
Otherwise just having the ability to pass a custom
AssemblyLoadContext
or custom resolver rather than usingAssembly.LoadFrom
inRegisterMSBuildPath
might be enough!The text was updated successfully, but these errors were encountered: