Nuget package install and update fails for Unity target projects with new csproj format even though PackageTargetFallback is specified

[tylerohlsen]

Details about Problem

I have a VS 2017 project with the new csproj format. See file contents attached. Notice I have added the new PackageTargetFallback node to allow VS to allow .Net 3.5 packages to be installed.

If I manually enter a package reference to a package that contains a .Net 3.5 target, the package restore succeeds and all is well. (see NLog in example file)
If I attempt to use the VS 2017 Manage Nuget Packages UI or Package Manager Console or dotnet CLI to install or update the package, I get the below error.

Note: This same issue has been reported to the Visual Studio Developer Community here.

NuGet product used:

• VS UI
• Package Manager Console
• dotnet.exe

NuGet version:

• NuGet Package Manager: 4.2.0
• dotnet.exe: 1.0.4
• VS: 15.2 (26430.13)
• Windows: 10.0.14393

Worked before? If so, with which NuGet version:

• New functionality that has never worked before

Detailed repro steps so we can see the same problem

1. Create a Visual Studio 2017 project with the new csproj format which targets .Net 3.5 Unity Full profile
2. Add the target fallback <PackageTargetFallback>$(PackageTargetFallback);net35</PackageTargetFallback>
3. Attempt to add or update a nuget package which contains a .Net 3.5 assembly using either VS UI, Package Manager Console, or dotnet CLI

All methods produce the same below error and stack trace

Verbose Logs

NuGet.Commands.RestoreSpecException: Invalid restore input. Invalid target framework 'unsupported'. Input files: [Path to my csproj].  
 at NuGet.Commands.SpecValidationUtility.ValidateFrameworks(PackageSpec spec, IEnumerable`1 files)
 at NuGet.Commands.SpecValidationUtility.ValidateProjectSpecNetCore(PackageSpec spec, IEnumerable`1 files)
 at NuGet.Commands.SpecValidationUtility.ValidateProjectSpec(PackageSpec spec)
 at NuGet.Commands.SpecValidationUtility.ValidateDependencySpec(DependencyGraphSpec spec)
 at NuGet.Commands.DependencyGraphSpecRequestProvider.GetRequestsFromItems(RestoreArgs restoreContext, DependencyGraphSpec dgFile)
 at NuGet.Commands.DependencyGraphSpecRequestProvider.CreateRequests(RestoreArgs restoreContext)
 at NuGet.Commands.RestoreRunner.d_11.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
 at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
 at NuGet.Commands.RestoreRunner.d4.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
 at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
 at NuGet.PackageManagement.DependencyGraphRestoreUtility.d4.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
 at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
 at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)
 at NuGet.PackageManagement.NuGetPackageManager.d74.MoveNext() 
--- End of stack trace from previous location where exception was thrown ---
 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
 at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
 at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)
 at NuGet.PackageManagement.NuGetPackageManager.d58.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
 at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
 at NuGet.PackageManagement.NuGetPackageManager.<>cDisplayClass56_1.<b0>d.MoveNext() 
--- End of stack trace from previous location where exception was thrown ---
 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
 at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
 at NuGet.PackageManagement.NuGetPackageManager.d56.MoveNext() 
--- End of stack trace from previous location where exception was thrown ---
 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
 at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
 at NuGet.PackageManagement.UI.UIActionEngine.d6.MoveNext() 
--- End of stack trace from previous location where exception was thrown ---
 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
 at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)  
 at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)  
 at NuGet.PackageManagement.UI.UIActionEngine.d_7.MoveNext()  

Sample Project

UnityNuGet.zip

[emgarten]

This may be fixed by #5154

[tylerohlsen]

I'm not finding a combination that works. Note: In all of these tests, I kept the rest of the above attached csproj unchanged and only changed the <TargetFramework> node (unless otherwise specified).

---

Test 1

<TargetFramework>.NETFramework,Version=v3.5,Profile=Unity Full v3.5</TargetFramework>

dotnet restore - success
dotnet add package NLog -v 4.4.10 - fail: Invalid target framework 'unsupported'
dotnet build - success

---

Test 2

<TargetFramework>.NETFramework,Version=v3.5,Profile=Unity Full v3.5</TargetFramework>
- <PackageTargetFallback>$(PackageTargetFallback);net35</PackageTargetFallback>

dotnet restore - fail: Package NLog 4.4.10 is not compatible with net35-unity full v3.5
dotnet add package NLog -v 4.4.10 - fail: Invalid target framework 'unsupported'
dotnet build - fail

warning MSB3256: No assemblies were read in from the redist lists. A TargetFramework profile exclusion list could not be generated.
error CS0246: The type or namespace name 'NLog' could not be found

---

Test 3

<TargetFramework>net35-unity full v3.5</TargetFramework>

dotnet restore - fail: Invalid target framework 'unsupported'
dotnet add package NLog -v 4.4.10 - fail: Invalid target framework 'unsupported'
dotnet build - success

---

Test 4

<TargetFramework>net35</TargetFramework>

dotnet restore - success
dotnet add package NLog -v 4.4.10 - success
dotnet build - fail

warning MSB3256: No assemblies were read in from the redist lists. A TargetFramework profile exclusion list could not be generated.
error CS0246: The type or namespace name 'NLog' could not be found

---

• Test 1 shows the issue I originally reported with dotnet add package failing because of the spaces in the profile name.
• Test 1 and Test 2 show that PackageTargetFallback is helping. Without PackageTargetFallback dotnet restore fails.
• Test 3 shows that the short name also fails with dotnet restore because of the spaces in the profile name.
• Test 4, as you suggested, does succeed with both dotnet restore and dotnet add package, but fails to compile.

[tylerohlsen]

As @emgarten suggested, this is likely to be fixed by #5154. Waiting for that fix to try this scenario again.

[tylerohlsen]

This issue just got a lot worse after we installed Visual Studio 2017 version 15.3 and .Net Core 2.0 SDK. After that install, Visual Studio will no longer restore NuGet packages. We get the error...

Error occurred while restoring NuGet packages: Invalid restore input. Invalid target framework 'unsupported'.

Previously this issue only broke NuGet package installs, but now it breaks for installs and restores. dotnet restore still functions and we are using that as a workaround for the time being. But that is a pretty interruptive workaround. We now need to manually run dotnet restore frequently when we get latest from source control just to be able to build locally.

@emgarten can we get #5154 in sooner? Or can we get a quicker fix by making a change to allow spaces in profile names?

[emgarten]

I've moved this to the backlog for consideration. I think #5154 is a good approach to fix this. Alternatively NuGet.Frameworks could add an alias for the unity profile so that it can be written as net35-unity.

[tylerohlsen]

Because this flow was so interruptive to our developers, we have since given up on attempting to target the Unity profile. As a workaround, we now target .Net 3.5 Full. This allows us to function without error with NuGet. Though, this is not an ideal workaround. We now run the risk of potentially getting runtime errors because we can no longer catch unsupported framework errors at compile time.

[emgarten]

@tylerohlsen thanks for the update. We're looking into giving unity first class support in nuget to improve this.

[nkolev92]

Closing this as stale right now.

#5154 is a generic feature that can still be worked on.