Could not load file or assembly 'NuGet.Frameworks, Version=6.2.1.7...

[craigktreasure]

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?

[craigktreasure]

Looks like some others are hot on the trail as well: dotnet/roslyn#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.

[jeffkl]

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 dotnet/roslyn#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?

[craigktreasure]

I'm not sure how I feel about that. Perhaps a simple "Known issues and workarounds" section in your docs might be good?

[jeffkl]

@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...

[craigktreasure]

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.

[MattKotsenas]

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.