MSBuildProjectCreator
MSBuildProjectCreator copied to clipboard
Could not load file or assembly 'NuGet.Frameworks, Version=6.2.1.7...
Me again. Getting the same issue as #170, but with a new version this time. Only this time there isn't a newer version of the NuGet.Frameworks package publicly available to force an update. The full version number of the dll in NuGet.Frameworks 6.2.1 is 6.2.1.2. So, there's a newer revision shipped somewhere that we can't get ahold of in a package. Not exactly sure which .NET SDK caused it, but 6.0.302 is currently exhibiting this behavior. I'm not sure I 100% understand the root cause of the problem, but i'd like to in order to drive the issue upstream. Either NuGet or the .NET SDK perhaps? Any suggestions?
Looks like some others are hot on the trail as well: https://github.com/dotnet/roslyn/issues/61454. The last suggestion to copy in the dll from the .NET SDK appears to be working so far. A bit hacky, but that's where are.
Yeah it really is annoying that some other package is depending on NuGet.Frameworks and then since its considered a runtime dependency, the wrong version ends up next to your assembly. It sounds like the discussion on https://github.com/dotnet/roslyn/issues/61454 is leaning towards removing that dependency which will help a lot.
Copying the assembly from the SDK is a pretty good workaround, I wonder if I should just build that into MSBuildProjectCreator?
I'm not sure how I feel about that. Perhaps a simple "Known issues and workarounds" section in your docs might be good?
@craigktreasure yeah that's probably a good idea at the very least. I wonder if I should add the workaround for all "unit test" projects which are probably pulling in the package that ends up referencing NuGet.Frameworks
. I know that I hit this every time there's a new release...
Yea. I just don't know what other implications it might have with other dependencies. It's probably fairly safe, but in the case that it did cause a problem, it could be painful to figure out what has swapped out that dll.
I believe this can be resolved as fixed now. Between the Roslyn change linked above and microsoft/vstest#4693, I think the usual references to NuGet.Frameworks have all been removed.
Fixed