nuget restore: Exception has been thrown by the target of an invocation

L

9

26

When I run nuget restore from the command line, I get

Error parsing solution file at MyProject.sln: Exception has been thrown by the target of an invocation.

but restoring nuget packages from Visual Studio runs without errors. Any workarounds?

Luganda answered 14/7, 2017 at 10:22 Comment(0)

B

42

This error is particularly frustrating on large solutions with many projects, as there is no hint from NuGet at what point in the file parsing failed.

To analyze the problem, try msbuild MyProject.sln; the parser of msbuild is slightly more verbose. At least it will give you a line number, so you will know where to look for the error. Open MyProject.sln in a text editor to inspect that line. In my case, it was simply a blank line that accidentally got introduced while manually resolving a TFS merge conflict.

(It may seem quite obvious to call msbuild, but in our case, that call was part of a larger build script where nuget restore would come first, aborting the build process before msbuild was reached.)

A future release of NuGet should return a more detailed error message; see issue #1150.

Buskirk answered 5/9, 2017 at 13:25 Comment(0)

L

14

I found the solution after examining our source control. There was an incorrect merge (in git) which caused our solution to have 2 nested projects

Project(...) = ...
Project(...) = ...
EndProject
Global
.......

and the last EndProject was missing. What's interesting is that Visual Studio didn't fail even though our solution file was effectively corrupt.

Adding an EndProject between the 2 Projects fixed the error.

Luganda answered 14/7, 2017 at 10:22 Comment(0)

G

11

I Had same issue. The problem was the sln file has same blank lines. I removed the lines. It resolved

Ex Problem

//Blank Line
Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio 15
VisualStudioVersion = 15.0.27130.2010
MinimumVisualStudioVersion = 10.0.40219.1

    GlobalSection(ProjectConfigurationPlatforms) = postSolution
        {658E5ED2-A01E-41DD-A952-F5EDE9E4AEE0}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
        {658E5ED2-A01E-41DD-A952-F5EDE9E4AEE0}.Debug|Any CPU.Build.0 = Debug|Any CPU

        {658E5ED2-A01E-41DD-A952-F5EDE9E4AEE0}.Prod|Any CPU.ActiveCfg = Prod|Any CPU
        {658E5ED2-A01E-41DD-A952-F5EDE9E4AEE0}.Prod|Any CPU.Build.0 = Prod|Any CPU
    EndGlobalSection

Fixed Version

Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio 15
VisualStudioVersion = 15.0.27130.2010
MinimumVisualStudioVersion = 10.0.40219.1

    GlobalSection(ProjectConfigurationPlatforms) = postSolution
        {658E5ED2-A01E-41DD-A952-F5EDE9E4AEE0}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
        {658E5ED2-A01E-41DD-A952-F5EDE9E4AEE0}.Debug|Any CPU.Build.0 = Debug|Any 
        {658E5ED2-A01E-41DD-A952-F5EDE9E4AEE0}.Prod|Any CPU.ActiveCfg = Prod|Any CPU
        {658E5ED2-A01E-41DD-A952-F5EDE9E4AEE0}.Prod|Any CPU.Build.0 = Prod|Any CPU
    EndGlobalSection

Gravitation answered 30/3, 2018 at 9:22 Comment(2)

I too had the same issue and removing the blank lines solved the issue for me. – Midi 23/11, 2018 at 6:9

Did you also remove the blank line at the beginning of the file? – Borst 13/4, 2020 at 13:1

B

7

My solution was to update nuget.exe to the latest version.

Bisson answered 19/3, 2020 at 14:35 Comment(0)

M

3

I had the same problem. This happened on our CI-server (TFS 2018) when using the "Nuget restore" task. Appearantly the build agent was using an old version of nuget (4.1) and it had trouble reading the Visual Studio 2019 solution file (sln and/or csproj) resulting in the error indicated by @sashoalm.

The answer from Microsoft was to use the task "Nuget Tool Installer" but this was not working behind the enterprise proxy wall that I am behind. From what I have read people have a hard time with this. According the Microsoft they have resolved this but only in Azure Devops Server 2019 in an update to the "Nuget tool installer" task.

What is the resolution is to manually download the nuget.exe of your choice and copy it to the build agent. Then, replace your "Nuget" task with a "Powershell" task and do

Write-Host "Restoring packages"
Write-Host "Using nuget.exe at" $(nugetexepath)
$(nugetexepath) restore [PATH_TO_SLN_FILE] -Verbosity Detailed -NonInteractive

I added a variable

nugetexepath

as well in the build configuration.

Perhaps this gets resolved in a future update from Microsoft to help all that are still on TFS 2018 and not on Azure Devops Server 2019.

Marigraph answered 17/4, 2020 at 10:34 Comment(0)

O

2

This can also happen after installing VS 2017 15.7 but without having .Net 4.7.2 installed.

See here for more details: https://github.com/NuGet/Home/issues/6918

Oneway answered 21/5, 2018 at 15:16 Comment(0)

P

1

I got this error from my azure pipeline. I went onto the build server & ran msbuild mysolution.sln. That revealed a different error:

Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.Build.Framework, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. at Microsoft.Build.CommandLine.MSBuildApp.Execute(String commandLine)
at Microsoft.Build.CommandLine.MSBuildApp.Main()

That's when I found that I found this answer Could not load file or assembly 'Microsoft.Build.Framework'(VS 2017) & thought I needed to update nuget, so I added a step in my pipeline for the NuGet Installer task & set it to use a newer version.

https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/tool/nuget?view=azure-devops

No more errors.

Perchance answered 21/10, 2021 at 20:38 Comment(0)

K

1

This is because of the version mismatch of NuGet in Visual Studio 2022 version and NuGet version Downloaded during build. To overcome this download the NuGet version of 6.x in during build as the visual studio 2022 supports the NuGet tool of Version 6.x

Knapweed answered 3/1 at 7:22 Comment(1)

Thank you for your interest in contributing to the Stack Overflow community. This question already has quite a few answers—including one that has been extensively validated by the community. Are you certain your approach hasn’t been given previously? If so, it would be useful to explain how your approach is different, under what circumstances your approach might be preferred, and/or why you think the previous answers aren’t sufficient. Can you kindly edit your answer to offer an explanation? – Meshed 4/1 at 6:47

U

0

I had this same problem and it was a result of running the Self-hosted agent as NT AUTHORITY\NETWORK SERVICE, which is the default if you don't specify a user. This results in a bunch of permission issues.

Once I reconfigured using a user account that had permissions, the task finally completed.

Ultramontanism answered 18/1 at 19:11 Comment(0)

Recommended topics

Hot tags