-
Notifications
You must be signed in to change notification settings - Fork 4
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
Could not load file or assembly 'NuGet.Frameworks, Version=6.2.1.7... #178
Comments
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. |
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? |
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 |
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. |
* workaround jeffkl/MSBuildProjectCreator#178 * update dependencies * update bctk lib Co-authored-by: Harry <harrypierson@outlook.com>
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 |
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?
The text was updated successfully, but these errors were encountered: