nuget.exe fails to pack NETCore project

[emgarten]

Using nuget.exe 4.0.0 build 2266

Steps

1. Create a NETstandard class library
2. nuget.exe pack <path to csproj>

Expected

Package will be created

Actual

Unable to cast object of type 'System.String' to type 'NuGet.Frameworks.NuGetFramework'.
System.InvalidCastException: Unable to cast object of type 'System.String' to type 'NuGet.Frameworks.NuGetFramework'.
   at NuGet.ProjectManagement.NuGetProject.GetMetadata[T](String key)
   at NuGet.ProjectManagement.PackagesConfigNuGetProject..ctor(String folderPath, Dictionary`2 metadata)
   at CallSite.Target(Closure , CallSite , Type , Object , Dictionary`2 )
   at System.Dynamic.UpdateDelegates.UpdateAndExecute3[T0,T1,T2,TRet](CallSite site, T0 arg0, T1 arg1, T2 arg2)
   at NuGet.CommandLine.ProjectFactory.AddDependencies(Dictionary`2 packagesAndDependencies)
   at NuGet.CommandLine.ProjectFactory.ProcessDependencies(PackageBuilder builder)
   at NuGet.CommandLine.ProjectFactory.CreateBuilder(String basePath, NuGetVersion version, String suffix, Boolean build
IfNeeded, PackageBuilder builder)
   at NuGet.Commands.PackCommandRunner.BuildFromProjectFile(String path)
   at NuGet.CommandLine.PackCommand.ExecuteCommand()
   at NuGet.CommandLine.Command.ExecuteCommandAsync()
   at NuGet.CommandLine.Command.Execute()
   at NuGet.CommandLine.Program.MainCore(String workingDirectory, String[] args)

[rrelyea]

Let's discuss options here.
Seems like in rtm milestone, we should recommend "dotnet pack", right?

[rohit21agrawal]

We already know this doesn't work. This is planned for 4.0.1

[rohit21agrawal]

Yes dotnet pack or msbuild /t:pack

[rrelyea]

let's take a nuget.exe fix for rtm. Get it reviewed, tested and then merge - no shiproom needed.

perhaps something like:

In order to pack a .NET Core based project, use "dotnet.exe pack" or "msbuild /t:pack"

[emgarten]

We already know this doesn't work. This is planned for 4.0.1

My main concern here is preventing the crash and improving the user experience. If it works or not is a different issue.

[emgarten]

We should really look at the user experience here before shipping 4.0.0 RTM.

[petertiedemann]

I have a F# "legacy" fsproj file referencing a project that targets net461 using the new csproj format.

I am also getting this error. Using dotnet pack or msbuild /t:pack does not work, as it will work only on the new project. Does this mean I have to run dotnet pack on one project and nuget pack on the other one? ( requires me manually enumerating the project files of each type in my build script).

[emgarten]

Does this mean I have to run dotnet pack on one project and nuget pack on the other one?

@petertiedemann currently, yes. That is what you would need to do.

I worked around this by adding a Pack target to my legacy projects that ran an Exec with nuget.exe pack to pack the project, then it was possible to run Pack on all projects without manually splitting them up.

[gulbanana]

The workaround of manually packing different project types does not work if you have a legacy project referencing a non-legacy project.

[leftler]

We are now on version 4.1.0, how does this relate to the milestone of 4.0.2 this issue is still assigned to?

[daveaglick]

I noticed this was removed from the milestone and added to the backlog. Does this mean that packing SDK projects with the NuGet CLI is deprecated and we shouldn't expect it to work anytime soon?

[ADD-Juan-Perez]

Related to #5979

We have added a reference to NuGet.Build.Tasks.Pack in a .NET 4.6.1 project.

If we configure the TargetFramework property in csproj an error occurs:

The project system has enountered an error.

'dimensionValuesMap' must contain at least one element.
Parameter name: dimensionValuesMap

But if we set the TargetFramework property through the command line works fine:
msbuild.exe -t:Pack -p:Configuration=Release -p:TargetFramework=net461

Thanks in advance

[gitsparty]

Scenario: Creating a nuget package from a csproj, targeting 4.6.2 with package references.

• nuget.exe pack doesn't work as dependencies are not inferred.
• After adding the nuget.build.tasks.pack nuget, fixing the csproj to import the target file, msbuild /t:pack gives the below error.
  msbuild /t:pack /p:PackageOutputPath="..\Packages" /p:TargetFramework=net462 /p:Authors="CI" /p:PackageVersion=2.0.0

C:\Users<XXX>.nuget\packages\nuget.build.tasks.pack\5.0.2\build\NuGet.Build.Tasks.Pack.targets(216,15): error MSB4064:
The "ProjectReferencesWithVersions" parameter is not supported by the "PackTask" task. Verify the parameter exists on the task, and it is a settable public instance property. [XXX.csproj]
C:\Users\XXX.nuget\packages\nuget.build.tasks.pack\5.0.2\build\NuGet.Build.Tasks.Pack.targets(199,5): error MSB4063: The "PackTask" task could not be initialized with its input parameters. [XXX.csproj]

[karann-msft]

related to #4254

[cyberkito]

Use dotnet task with pack option. That worked for me with multiple platform project.

[IanKemp]

Guys, I just got bitten by this and spent a DAY figuring it out. Why bother adding support for the new-format csproj if you aren't bloody well going to add support for the things inside that file, like PackageReference?

It's been two and a half years, for crying out loud and this isn't fixed, so it's pretty obvious it isn't going to be fixed. Meanwhile the current behaviour of generating an apparently-working NuGet package that has no dependencies listed is not only not helpful, it's actively harmful.

Pull your thumbs out and do what #7778 suggests. Right now you are just wasting developers' time.

[karann-msft]

We are now actively investigating implementing #7778. We currently don't plan to add the ability to pack SDK style projects to nuget.exe.

[wangyoutian]

This is really very depressing, since we have already a lot of automation scripts built upon "nuget pack".

After converting a project from "packages.confg" to "PackageReference", we now have to add referenced package one by one manually; that is really pain, especially the missing of dependency will only be known when we run a project.

I really donot think this patching needs two years, as the dependencies are listed under the project references in our very eyes.

[SimonCropp]

doesnt this #4491 (comment) imply this issue should be closed as wont fix?

[nkolev92]

Hey all,

As mentioned above, we have decided to implement #7778.
You can learn more about that change in #12088.