CODEWITHSUNDEEP
c#nugetnuget-spec
cat_in_hat
cat_in_hat

Reputation: 685

nuget.exe doesn't recognize any target framework in nuspec file

I have a project that generates a NuGet package directly in visual studio, by setting the following option in the CSPROJ file:

<GeneratePackageOnBuild>true</GeneratePackageOnBuild>

This causes the generated package to include all the embedded resource files that have been marked as "copy to output directory=Do not copy".

enter image description here

Sadly, Visual Studio's automated packager chooses to always copy these files into the NuGet package, regardless.

To solve that, I've been looking into editing the .NUSPEC file and using NUGET.EXE from the command line to create the package.

Then I run into a new problem. By using NUGET.EXE instead of visual studio, the package generated shows the dependencies section as "unsupported", which I see by opening the package in 'NuGet Explorer':

enter image description here

Here is the .bat file to create the package:

c:\nuget\nuget.exe config -Set repositoryPath="%USERPROFILE%\.nuget\packages"
c:\nuget\nuget.exe pack -IncludeReferencedProjects -properties Configuration=Release

And here is the NUSPEC file:

<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2012/06/nuspec.xsd">
  <metadata>
    <id>Integrative.Lara</id>
    <version>0.5.3</version>
    <authors>Pablo Carbonell, Integrative Software LLC</authors>
    <owners>Pablo Carbonell, Integrative Software LLC</owners>
    <requireLicenseAcceptance>true</requireLicenseAcceptance>
    <license type="file">LICENSE</license>
    <projectUrl>https://github.com/integrativesoft/lara</projectUrl>
    <iconUrl>https://integrative.b-cdn.net/Integrative.ico</iconUrl>
    <description>Lara is ...</description>
    <copyright>Copyright (c) 2019 Integrative Software LLC</copyright>
    <tags>lara, web, html, html5, desktop, gui, cross, framework, mac, osx, platform, ui, blazor, razor</tags>
    <repository url="https://github.com/integrativesoft/lara" />
    <dependencies>
      <group targetFramework=".NETStandard2.0">
        <dependency id="Microsoft.AspNetCore" version="2.2.0" exclude="Build,Analyzers" />
        <dependency id="Microsoft.AspNetCore.WebSockets" version="2.2.1" exclude="Build,Analyzers" />
      </group>
    </dependencies>
  </metadata>
</package>

Is there a way to fix the "unsupported" target? I tried using also "netstandard2.0", and other identifiers, and still get the same "unsupported".

Alternatively, is there a way to use Visual Studio's automatic package generation and prevent it from including files in the package?

Upvotes: 0

Views: 1924

Answers (1)

zivkan
zivkan

Reputation: 14961

As you see, when you use a nuspec, you're responsible for getting every little thing right. Using NuGet's MSBuild pack targets is easier, as it automates things like creating dependencies, including using the correct TFM in the group.

NuGet's docs on the pack targets has stuff relevant to packing with msbuild (which is what happens when you use dotnet pack or GeneratePackageOnBuild). In particular the section on Including content in a package has this sample:

<Content Include="..\win7-x64\libuv.txt">
 <Pack>false</Pack>
</Content>

Since your file is embedded, your csproj will contain something like <EmbeddedResource Include="whatever.ext" />. So, using the information from the docs, you could do <EmbeddedResource Include="whatever.ext" Pack="false" />, or use the multi-line version as the docs do. MSBuild allows you to set item metadata either way.

<GeneratePackageOnBuild>true</GeneratePackageOnBuild>

A note on GeneratePackageOnBuild: it's convenient to have build create packages for you, but it means that when you're debugging and need to change a single line of code before testing again, you have to wait not only for the build, but also for pack. If your package is small, it's probably fairly quick, but still it's slowing down your "inner-loop" experience. Most developers only need to pack far less frequently than they build, so I suggest disabling GeneratePackageOnBuild, and instead run dotnet pack on the project (or solution) when you actually need the nupkg.

Upvotes: 1

Related Questions