Home: nuget.exe excludes *.nuspec files and there is no way to bypass this

[deepakaravindr]

@tugberkugurlu

Nice to see NuGet finally moving to GitHub :fireworks:

I was trying to do ASP.NET 5 deployment with Octopus Deploy and I needed to nuget pack all the application stuff. This also contains the packages and their nuspec files. However, nuget.exe excludes those and there is no way to override them. There must be a good reason why this is a default behavior and I don't like to use NuGet for stuff like deploying applications but this made me write following horrible build script (this cheap trick was what I can come up with at 1 AM :smile:):

task NuGet-Pack {

    ## TeamCity stuff. Get this as a parameter
    $buildNumber = $env:BUILD_NUMBER
    if($buildNumber -eq $null) 
    {
        $buildNumber = "0.9.9.9999"
    } 
    else 
    {
        # nuget.exe doesn't include nuspec files. So, zip up and pack that instead
        # but only do this on build server for now, fix this later

        if(test-7za -eq $false)
        {        
            Write-Output "Found 7za.exe. Zipping the application"

            $confidenceAppPath = "$artifactsAppsRoot\Confidence.Client.Web"
            7za a "$artifactsAppsRoot\app.zip" "$confidenceAppPath\*"

            $longPathPath = "$solutionRoot\packages\Pri.LongPath\lib\net40\Pri.LongPath.dll"
            [System.Reflection.Assembly]::LoadFile($longPathPath) | Out-Null
            $directoryInfo = New-Object Pri.LongPath.DirectoryInfo -argumentlist $confidenceAppPath
            $directoryInfo.Delete($true)
            New-Item $confidenceAppPath -ItemType Directory
            Move-Item -Path "$artifactsAppsRoot\app.zip" -Destination $confidenceAppPath
        }
        else 
        {
            throw "7za doesn't exists globally"
        }
    }

    & "$solutionRoot\.nuget\nuget.exe" pack "$solutionRoot\Confidence.Client.Web.nuspec" -OutputDirectory "$artifactsRoot" -Version $buildNumber -NoPackageAnalysis -NoDefaultExcludes
}

Is it possible to provide a switch like -IKnowWhatIAmDoingGetAwayFromMyWay? Here is the nuspec file I am using to create the NuGet package:

<?xml version="1.0"?>
<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
  <metadata>
    <id>Confidence.Client.Web</id>
    <version>0.0.0</version>
    <authors>foo bar</authors>
    <owners>foo bar</owners>
    <requireLicenseAcceptance>false</requireLicenseAcceptance>
    <description>Confidence Web Client</description>
  </metadata>
<files>
  <file src="artifacts\apps\Confidence.Client.Web\**\*" />
</files>
</package>

This issue has been moved from https://github.com/NuGet/NuGet.CommandLine/issues/7

[deepakaravindr]

From @ChaseFlorell

:+1: We're in the same boat. .nuspec and .nupkg files cannot be contained in the manifest, and this is very problematic.

Nuget has definitely expanded far beyond what they thought it could do, and so some of these philosophies need to change. For us it's also Octopus Deploy related. We're trying to bundle a WPF app built using squirrel, and we can't do it out of the box. Instead, I've been creating extensions cepsun and renaming them once they're unpackaged... this is far from convenient.

[deepakaravindr]

From @tugberkugurlu

@ChaseFlorell thinking about this more, I really think that this isn't a NuGet problem. In NuGet's domain, it makes sense to have this restriction. However, we try to NuGet everything possible and that's clearly wrong. This is one of the problems arises from that and there are possibly more.

[deepakaravindr]

From @ChaseFlorell

while you're correct, Nuget is evolving and needs to be more flexible.

[ChaseFlorell]

+1

[yishaigalatzer]

@tugberkugurlu you know the drill, this is something we can consider supporting, but it will be pretty low on our list of must haves given the current requirements and long list of work towards 3.2 and 3.3.

Hence we will gladly take a well thought out PR with tests and whathave you.

I'm moving this to the discussion milestone. Lets plan it out and once a PR is made we can take it. Otherwise we can move it to the vNext milestone and get to it when we get to it.

Make sense?

[tugberkugurlu]

@yishaigalatzer thanks for the response. Yes, it makes sense but I am now more thinking like https://github.com/NuGet/Home/issues/1290#issuecomment-135912775.

Before going and lifting this restriction, that would be good to know the reason why it is there at the first place. My concern is that this might make sense for NuGet but doesn't make sense for others which use NuGet outside of its use case. If that's the situation, I don't think it should be changed.

[ChaseFlorell]

I have two different use-cases where this restriction gets in the way.

I too use Octopus Deploy for my delivery, and because Octopus is built on nuget for it's artifacts, it needs to be able to bundle nuspec manifests.

1. I maintain a nuget package that I push to nuget.org. I want to be able to deliver that nuget package via Octopus, and therefore the app.nupkg needs to be an artifact inside the octopus.nupkg
   
   
   
   • I haven't tried, but my workaround here would be to rename the nupkg to zip when packaging it, and then change it back again when deploying it.
   
   
2. I deploy squirrel apps to different environments. I need to be able to package the nuspec manifest for the squirrel release inside the octopus.nupkg. Releases against the manifest are build during deployment time.
   
   
   
   • my current workaround is to bundle the nuspec as a cepsun and then rename it during deployment.
   
   

[yishaigalatzer]

@tugberkugurlu I think this was done because it is just an old piece of code and it is an easy assumption to assume there will be only one nuspec file, and it is not the one in the project, since nuget will modify it. The easiest thing was to remove all of them no matter where they are and insert a new one.

The complication arises from the fact that nuget clients do not strictly enforce the name of nuspec (should be {packageid} concatenated by {version}), and I'm not sure about the folder in where it needs to be OR if there is a good algorithm in all the versions to find the "right" nuspec.

So fixing the pack command could be relatively easy, but testing all the iterations against the existing clients could be a bit more difficult and it might reveal things that just don't work.

So it comes to some diligence when designing and building this feature as well as proper testing to make sure this doesn't unusable packages (or at least if it does, include a minclient version if possible)

[nkolev92]

Thanks for filing this issue.

At this point we are not planning on fixing this, because of how dangerous something like this would be.

[natemcmaster]

@nkolev92 can we reconsider options here?

I ran into this too trying to create a template package for dotnet-new. Took a while to figure out that NuGet was silently ignoring this directive:

<file src="content/GlobalTool-CSharp/My.Tool.nuspec" target="content/GlobalTool-CSharp/" />

It seems to me like this should be allowed. If my nuspec explicitly says "include this .nuspec file", why would it be dangerous for NuGet to honor that?

At the very least, issue a warning or something when ignoring user input.

[tugberkugurlu]

At the very least, issue a warning or something when ignoring user input.

👍