16

I am trying to pack a library as a NuGet package in powershell, like so:

function Create-NuGetPackages($projects) {

    if (!(Test-Path $NuGetPackageDirectory)) {
        New-Item $NuGetPackageDirectory -ItemType Directory
    }
    
    foreach ($project in $projects) {
        pushd $project.DirectoryName

        & dotnet.exe pack --configuration $Configuration --output $NuGetPackageDirectory --no-build

        popd
    }

    return $NuGetPackageDirectory
}

The project is using a project.json and a .xproj file (there is also a .csproj file for working on the project in .NET 4.5.1). The above command functions, but I end up with a NuGet package name MyProject.Core and I need it to be MyProject to match the legacy packages.

The project is a port and the most sensible thing to do is name the folder after the Java package, which is MyProject.Core, but I can't seem to figure out how to make it generate a NuGet package with a different name.

I have tried using this command on the CLI:

dotnet pack "src\MyProject.Core\MyProject.csproj" --output NuGetPackages\ --configuration "Release"

but it gives the error:

Unable to find a project.json in src\MyProject.Core\MyProject.csproj\project.json

According to this page:

PROJECT

The project to pack. It's either a path to a csproj file or to a directory. If omitted, it defaults to the current directory.

So why if I specify the path of the csproj does it look for a project.json file?

I was able to work around this issue for the name of the assembly by specifying:

"buildOptions": { "outputName": "MyProject" },

But the pack command totally ignores this. There also doesn't seem to be an option to specify the name of the NuGet package in the packOptions section.

I had a look at this old question but it looks like they are talking about the nuget tool, not the dotnet tool.

Is my only option to rename the folder (which will likely cause a lot of other stuff to break now), or is there another way to specify the NuGet package name for the dotnet pack command?

On a side note, I have read in several places that project.json is going away and we are going back to .csproj, but it is unclear when that will take effect. Should I be aiming to eliminate the project.json file or is it too early for that?

Community
  • 1
  • 1
NightOwl888
  • 55,572
  • 24
  • 139
  • 212
  • Re migration from `project.json` to `*.csproj`: see [here](https://learn.microsoft.com/en-us/dotnet/articles/core/migration/#migration-from-projectjson-to-csproj) and [here](https://learn.microsoft.com/en-us/dotnet/articles/core/tools/project-json-to-csproj). – mklement0 Apr 02 '17 at 22:01
  • @mklement0 - Thanks. But as LexLi already pointed out the functionality still isn't fully working. I would rather not trade one partially working solution for another - especially if it means giving up the single `dotnet pack` command that works for both .NET Standard and .NET Framework and going back to .nuspec files and 2 different build commands per project (for 2 different .csproj files) for the interim. – NightOwl888 Apr 03 '17 at 09:49

3 Answers3

27

For whoever still has this issue

dotnet pack -p:PackageID=my_id
Ali Ben Zarrouk
  • 1,891
  • 16
  • 24
  • 1
    This is the correct answer now (old question, so might not have been back then!) – Dave Sep 06 '19 at 12:36
  • Why here (https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-pack) -``p:PackageVersion`` is documented but ``-p:PacjkageID`` is not mentioned at all? – Alex 75 Feb 05 '20 at 12:41
  • @Alex75 you're right, we should report this omission to maintainers. – Natalie Perret Jun 25 '20 at 16:12
  • @Alex75 Tbh I remember just trying this and found out that it works lol then I figured out it wasnt documented. – Ali Ben Zarrouk Jul 23 '20 at 16:02
  • 3
    does this work for anyone? i tried `dotnet pack -p:PackageId=asdfasdfasdfawg` and got `error : Ambiguous project name 'asdfasdfasdfawg'`. trust me, i go no project with such a name – Neville Nazerane Apr 07 '21 at 06:55
  • Ok figured the issue. if your project references another project, this command doesn't work since `dotnet pack` tries to reference both projects – Neville Nazerane Apr 07 '21 at 08:26
  • 2
    I was able to pack with a different package-id by first building the solution normally (dotnet build) and then calling dotnet pack for the specific project and the following arguments: --no-build --no-dependencies -p:PackageId=foo – Peter Ryan May 07 '21 at 14:41
17

Metadata are specified in csproj, as the documentation says,

https://learn.microsoft.com/en-us/nuget/guides/create-net-standard-packages-vs2017#edit-metadata-in-the--csproj-file

<PropertyGroup>
 <TargetFramework>netstandard1.4</TargetFramework>
 <PackageId>AppLogger.YOUR_NAME</PackageId>
 <PackageVersion>1.0.0</PackageVersion>
 <Authors>YOUR_NAME</Authors>
 <Description>Awesome application logging utility</Description>
 <PackageRequireLicenseAcceptance>false</PackageRequireLicenseAcceptance>
 <PackageReleaseNotes>First release</PackageReleaseNotes>
 <Copyright>Copyright 2016 (c) Contoso Corporation. All rights reserved.</Copyright>
 <PackageTags>logger logging logs</PackageTags>
</PropertyGroup>
Vencovsky
  • 28,550
  • 17
  • 109
  • 176
Lex Li
  • 60,503
  • 9
  • 116
  • 147
  • 1
    Yea, I just found that documentation. But I am still confused. Someone else setup the .NET standard support on the project. There are 2 different solution files - one for .NET Framework and one for .NET Core. The .csproj files target .NET Framework, not .NET Core. So, how in the world would I merge these? – NightOwl888 Apr 02 '17 at 18:43
  • 1
    @NightOwl888 please use two separate csproj files for them and only pack against the .NET Core csproj. Just like how we target full and CF in the past. Once Microsoft implements multiple target framework support with csproj, then you might start to merge. – Lex Li Apr 02 '17 at 19:56
  • 1
    Hmm...I thought that document you linked to meant that multiple targets were already supported...? If that isn't done yet, I don't think I will spend the time to convert the project.json files to .csproj for .NET Standard. Not only will it prevent me from having to worry about naming collisions between project files, it would be much less work to make the build script copy that one project (out of 31) to a new folder with the correct name for the NuGet package. – NightOwl888 Apr 02 '17 at 20:30
  • 1
    @NightOwl888 Various sources show that "multiple target framework support" is there, but only partially works. Personally I rather wait till Microsoft officially announces it feature-complete. – Lex Li Apr 02 '17 at 21:30
  • In case you are wondering where that properties came from, here is the [docs](https://learn.microsoft.com/en-us/nuget/reference/msbuild-targets#pack-target) – Vencovsky Jan 15 '21 at 11:09
2

Since Lex Li pointed out that the tooling is still a work in progress, I came up with a hackish solution that doesn't force me to have to resort to .nuspec files again (and much rearranging of the project) just to get it working.

# Hack because dotnet pack doesn't provide a way to override the directory
# name for the NuGet package name when using project.json. 
# So, we copy MyProject.Core to a new directory
# MyProject to work around this.
function Copy-MyProject() {
    Copy-Item -Recurse -Force "$root\src\MyProject.Core" "$ReleaseDirectory\MyProject"
}

function Delete-MyProject-Copy() {
    Remove-Item "$ReleaseDirectory\MyProject" -Force -Recurse -ErrorAction SilentlyContinue
}

function Create-NuGetPackages($projects) {

    try
    {
        Copy-MyProject
        $projects = $projects += Get-ChildItem -Path "$ReleaseDirectory\MyProject\project.json"
        $projects = $projects | ? { !$_.Directory.Name.Equals("MyProject.Core") }

        if (!(Test-Path $NuGetPackageDirectory)) {
            New-Item $NuGetPackageDirectory -ItemType Directory
        }

        foreach ($project in $projects) {
            pushd $project.DirectoryName

            Write-Host "Creating NuGet package for $project..." -ForegroundColor Magenta

            & dotnet.exe pack --configuration $Configuration --output $NuGetPackageDirectory --no-build

            popd
        }
    } finally {
        Delete-MyProject-Copy
    }

    return $NuGetPackageDirectory
}
NightOwl888
  • 55,572
  • 24
  • 139
  • 212