-
Notifications
You must be signed in to change notification settings - Fork 249
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.exe restore foo.sln - broken with msbuild 15.7 installed #6918
Comments
I hit the same issue. This issue doesn't seem to reproduce when .NET Framework 4.7.1 is installed and thus the GAC contains System.Runtime.InteropServices.RuntimeInformation.dll. From my observation, it does not reproduce in:
It reproduces in:
|
Great spot asmichi - we are running .NET 4.7 (version 460798) on Creator's Update (version 1703). I'll try updating to get around our current issues. |
For me copying System.Runtime.InteropServices.RuntimeInformation.dll from MSBuild to the same directory as NuGet.exe made NuGet work. |
Does it work for you using the 4.7.0 nuget.exe from https://www.nuget.org/downloads? (warning: "recommended latest" listed at the top is actually older) |
@dasMulli thanks, but it seems not - on my affected machines, the entire 4.x range has stopped working since 15.7 was applied. |
Applying .NET 4.7.2 to my affected machine has fixed the issue. However, rolling this out to all my developers, build agents, etc is not an exciting prospect :-) |
I can confirm what @AndrewGretton said. |
I can also confirm this. The error message is really confusing and makes it seem that there's something wrong with the solution, but building the solution with MSBuild directly yields no errors at all. Installing .NET 4.7.1 fixed this issue. |
Yes, 4.7.2 fixes this issue |
We are working with the MsBuild team to determine the right fix(es).
Sorry for the problem. |
@rrelyea we copied System.Runtime.InteropServices.RuntimeInformation.dll from C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin to our nuget.exe location c:\programdata\chocolaty\bin which did not work. I looked at the file version information of the dll and it was 4.6.24705.1. Apparently its trying to load 4.0.1.0. We are using nuget version 4.6.2.5055. Unfortunately we can't update the .net framework to 4.7 or later because this is running on Server 2012 R2 which is not supported. Any clue? |
@Ncage1974 Confusingly, the Can you use |
@rainersigwald thanks for the hint of using fuslogvw which enabled me to figure it out. I not sure if this is the way nuget works or if this is an oddity of chocolatey but you will find nuget.exe at c:\programdata\chocolatey\bin\nuget.exe but this is not the REAL executable (its some type of shim). It essentially points to c:\programdata\chocolatey\lib\Nuget.CommandLine\Tools\nuget.exe. I copied the dll to the directory now everything is working perfectly from the command line: Unfortunately it looks like when VSTS when its doing the builds creates a temporary type location (C:\agent2_work_tasks\NuGetInstaller_333b11bd-d341-40d9-afcf-b32d5ce6f23b\0.2.31\node_modules\nuget-task-common\NuGet\4.0.0\NuGet.exe). Of course the needed dll is not located there and is failing causing our builds to fail. Still trying to determine a work around. |
@Ncage1974 You can work around that by using the NuGet Tool Installer extension which will put it in the agent's tools folder. |
@jdshkolnik Hi John. I tried that and it still fails but at a different location: Should i just stick the required dll (System.Runtime.InteropServices.RuntimeInformation.dll) in c:\agent2_work_tool\Nuget\4.3.0\x64\ folder? If i do that wouldn't it start failing as soon as 4.4.x version of nuget comes out or should i lock the version to nuget 4.3.x? |
Yes, sorry I wasn't clear. I was offering a workaround for the temporary nuget.exe location rather than the root error. It's much easier to copy the dll into a single tool folder per agent. |
Installing the .NET Framework 4.7 SDK on Windows 2016 did not get around the error for me, but installing the .NET Framework 4.7.2 (not the SDK) did. |
Installing .NET Framework 4.7.2 (Runtime, NOT SDK!) did the trick for me. |
We just installed .net 4.6.2 on our build agent which triggered the issue described. |
Update: an MSBuild change that will fix this has been accepted by VS shiproom and will go out with a 15.7 update. I don't have any timing information on when it'll ship. Until that's out, @rrelyea's workarounds in #6918 (comment) are good, except that it should say to install .NET Framework 4.7.1 or later; 4.7 is not enough. |
I had the same issue and installing .net 4.7.2 solved it. I concur. |
This should be resolved with MSBuild 15.7.179, delivered in Visual Studio 2017 15.7.2. |
I experience the same problem but only on VSTS. I seem to be the only having this issue. Could there be anything I can do to fix this? |
Hi @ALL I am getting the same issue when trying to run Command line log
Hints on how to resolve are appreciated. Thanks! |
@elahaha If possible, please update your nuget.exe version. There should be an MSBuild fix in Visual Studio 16.5.5 and 16.6.0 when they are released. |
Environment / tooling
nuget.exe, version 4.6.2
VS2017/msbuild version 15.7
Win10, 1703
Repro steps
Run
nuget restore <any valid .sln file>
Expected result: nuget restore works
Actual result: nuget restore no longer works since 15.6 --> 15.7 upgrade
Sample problem output
This is reproducible on any .sln file, including newly created ones, and is reproducible on the two test machines we have performed an upgrade on so far.
Nuget 3.3 (last public release from the Github releases page) does not exhibit this issue on the affected machines, and restores correctly.
The text was updated successfully, but these errors were encountered: