MSBuildProjectCreator icon indicating copy to clipboard operation
MSBuildProjectCreator copied to clipboard

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

Open craigktreasure opened this issue 2 years ago • 6 comments

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 avatar Aug 06 '22 04:08 craigktreasure

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.

craigktreasure avatar Aug 06 '22 05:08 craigktreasure

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?

jeffkl avatar Aug 09 '22 15:08 jeffkl

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

craigktreasure avatar Aug 09 '22 19:08 craigktreasure

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

jeffkl avatar Aug 09 '22 19:08 jeffkl

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.

craigktreasure avatar Aug 09 '22 19:08 craigktreasure

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.

MattKotsenas avatar Mar 08 '24 03:03 MattKotsenas

Fixed

jeffkl avatar Oct 03 '24 20:10 jeffkl