We Keep Coding

Have a NuGet package output a file

I have a Visual Studio project that I have made into a NuGet package. The project has a file in it (called SwaggerIndex.html). I have set that file to have the "Copy to Output Directory" property to "Copy if newer". (I need this file to copy to the build folder on build.)
In that solution it works just fine. (I created another project to test it, and when it references my project that has the SwaggerIndex.html, it outputs it to the build folder just fine.)
However, when I package it into a NuGet and pull it into another solution/project, the SwaggerIndex.html file is not output on build.
I am making my NuGet package by going to the project's "Package" properties tab and selecting "Generate NuGet package on build". All projects involved are running .Net Core 3.1.
How can I get my NuGet Package to create my SwaggerIndex.html file on build (like it does when it is just a normal project)?

Please try these:
I have two solutions for you to solve the issue.
Solution 1
If you just want to install this nuget package only in new sdk projects(Net Core and Net Standard projects), you could use this
1) add these node in your xxx.csproj file:
<ItemGroup>
<None Include="xxx\SwaggerIndex.html(the path of SwaggerIndex.html file in your project)" Pack="true" PackagePath="contentFiles\any\any">
<PackageCopyToOutput>true</PackageCopyToOutput>
</None>
</ItemGroup>
2) then repack your nuget project, and before you install the new version, you should first clean nuget caches first or just delete all cache files under C:\Users\xxx(current user)\.nuget\packages
Solution 2
If you want this nuget package to copy SwaggerIndex.html file in both Net Framework and Net Core projects, you should use this:
1) add a file called <package_id>.props file in your nuget project. You should note that if your nuget package named as SwaggerIndex.1.0.0.nupkg, you should name the file as SwaggerIndex.props file so that it will work.
In my side, I put it into a folder called build.
2) then add these content in SwaggerIndex.props file,
<Project>
<Target Name="CopyToOutputFolder" BeforeTargets="Build">
<ItemGroup>
<File Include="$(MSBuildThisFileDirectory)..\File\*.*"></File>
</ItemGroup>
<Copy SourceFiles="#(File)" DestinationFolder="$(TargetDir)"></Copy>
</Target>
</Project>
3) add these in xxx.csproj file of your nuget project.
<ItemGroup>
<None Include="SwaggerIndex.html" Pack="true" PackagePath="File"></None>
<None Include="build\SwaggerIndex.props" Pack="true" PackagePath="build"></None>
</ItemGroup>
4) then repack your nuget package, before installing this new version of the nuget package, you should first clean all nuget caches first.
When you finishing installing the new version of the nuget package, click Build and the file will be copied into the main project.
Besides, there is also a similar issue about this.

How do I create an individual nuget package for each project in a solution, with project references converted to nuget dependencies?

I have a solution that looks like this.
I would like to generate separate nuget packages for ProjA, ProjB and ProjC, and I would like this process to detect the project references shown above in ProjC, and convert them to nuget dependencies in the nuspec file, rather than just including the dlls for ProjA and ProjB in the ProjC nuget package, which is what happens at the moment when I use the 'nuget pack' command with the -IncludeReferencedProjects option.
This option says something about automatically either including the files or adding them as a dependency, but always includes them, even though I would like them added as a dependency. Weirdly, in my realword solution, one of the project references always gets added as a dependency, but the rest don't and I can't figure out the difference.
How do I tell nuget to add them as a dependency?
I want the references to be project references as it makes it easier for development, rather than having to generate an update local nuget packages every time I want to test.

But always includes them, even though I would like them added as a
dependency. How do I tell nuget to add them as a dependency?
Assuming you're using nuget pack command instead of dotnet pack or msbuild /t:pack.
For nuget pack xx.csproj -IncludeReferencedProjects command, to make sure the referenced projects are contained in your ProjC package with nuget dependency format, you should add corresponding xx.nuspec file in referenced projects's folder.
See the description of IncludeReferencedProjects here: If a referenced project has a corresponding .nuspec file that has the same name as the project, then that referenced project is added as a dependency. Otherwise, the referenced project is added as part of the package.
So here's the workaround:
1.For me, I open cmd.exe and navigate to ProjA's or ProjB's project folder, use nuget sepc command to create a ProjectName.nuspec for me in project folder.
2.Change the content of the ProjA.nuspec to something like this:
<?xml version="1.0"?>
<package >
<metadata>
<id>ProjA</id>
<version>1.0.0</version>
<title>This is title.</title>
<authors>This is author.</authors>
<owners>These are owners.</owners>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>This is description.</description>
<releaseNotes>Summary of changes made in this release of the package.</releaseNotes>
<copyright>Copyright 2019</copyright>
</metadata>
</package>
Now navigate to ProjC's folder and pack the ProjC again, the IncludeReferencedProjects will work as you expected. To check this: Rename the ProjC.nupkg to ProjC.zip, and check the content of generated ProjC.nuspec file in ProjC.zip file. You'll see something like <dependency id="ProjA" version="1.0.0" />.
In addition:
1.Since you're using nuget pack command and your projects target .net framework, I suggest you use packages.config format to manage nuget packages for the three projects.
2.To make your ProjC adds the ProjA and ProjB as nuget dependencies: Apart from using IncludeReferencedProjects+ProjA.nuspec+ProjB.nuspec way, actually we can simply create a ProjC.nuspec file and add content like below to manually define the dependencies.
<dependencies>
<dependency id="ProjA" version="1.0.0" />
<dependency id="ProjB" version="1.0.0" />
</dependencies>
</metadata>

Create multi-target nuget package from several csproj contained in different folders from nuspec file

I am trying to create a nuget package for a library which exists in 2 versions, each of them targeting two different .NET versions.
Here is my folder structure:
As you can see my nuspec file is one directory above my csproj (which are in the /net452 and /netcoreapp2.0 folders).
I am using the following command line to build my nuget package:
nuget pack .\my.nuspec -properties Configuration=Release -Build
The issue is that the build can not be achieved because the csproj files are not in the same folder as the nuspec file.
Please note that the packaging works fine when both projects have been priorly manually built.
I'm very new to this process and I'm not sure what I should do in that scenario, is there a simple way to reference the 2 csproj from the nuspec or - assuming I want to keep this folder structure - would I need to make a script that builds the projects first and then invoke nuget pack?
EDIT: To clarify my issue, I do have two different csproj files, contained respectively in /net452 and /netcoreapp2.0, and they compile the source code in their respective directory to produce two different dll. These two dll are then referenced in my nuspec file in order to offer my package in net452 or netcoreapp2.0 with the following syntax:
<files>
<file src="lib\**" target="lib" />
</files>
Note: after I manually compiled my two projects, the directory looks like this (note the lib folder that contains a net452 and netcoreapp2.0 folder with the appropriate version of my dll).

Not sure if understood correctly - you have one library and want to build it in two versions (net452 and netcore).
Did you try adding following items to *.csproj?
<PropertyGroup>
<TargetFrameworks>net45;netcoreapp2.0</TargetFrameworks>
</PropertyGroup>
Then you can have on project with two outputs from build

Can dotnet pack create a nuget package without adding content files from other nuget packages?

I'm trying to setup a library nuget package for .net core with the dotnet pack command, however, instead of just having a dll included in the nuget package, a content file from another references nuget is added (which makes the nuget file size 9.6MB instead of 59KB).
Is there a way to avoid getting files and content from other nuget packages in a nuget library project?
to reproduce:
Create a .net core library
Add Hl7.Fhir.Specification.STU3 nuget reference
run dotnet pack
The nuspec file in the newly created nuget package, will reveal that the specification.zip file is regarded as content that must be added.
I've tried testing with a custom nuspec file which is basicly a copy from the dotnet output, but without the content reference. The problem I see, is that the nuspec file contains a lot of references which must be maintained somehow.

Peter Wurzinger's suggestion worked for me. It's a shame he posted as a comment, rather than an answer, since he deserves the rep points. Anyway, this is my csproj
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Hl7.Fhir.Specification.STU3" Version="0.96.0" ExcludeAssets="contentFiles" />
</ItemGroup>
</Project>
when I pack, the bin\Debug\test.1.0.0.nuspec file does not contain the specification.zip file elements that exists when I don't use ExcludeAssets.

Override a nuget package reference with a local project reference

I'd like iterate on a nuget package without continuously pushing the package to a nuget feed.
I'm wondering if it's possible to conditionally add a project reference instead of a nuget package reference via a target or props file in csproj files that would allow me to locally debug my nuget package.
In my csproj I would have:
<Reference Include="A">
if(Exists(localOverrides.props) {
<HintPath>localOverrides.A.HintPath</HintPath>
} else {
<HintPath>..\packages\A.dll</HintPath>
}
</Reference>
and localOverrides.props would be a file listed in my .gitignore that developers could add lines to like:
A -> C:\Repos\A\bin\A.dll
Am I on the wrong path? Surely there must be a more sustainable way to quickly iterate and debug a nuget package then creating pre-release packages on every change

The way I have always debugged Nuget package is once you have that package added to your solution through Nuget, you then make changes to the Nuget DLLs and just copy them into the correct folder in the packages folder for the project consuming the Nuget package.
All you have to do is compile the solution that Nuget project solution in debug mode and just copy/paste them into the consuming project's packages folder. You could make this even simpler by writing a batch script and adding it as a post build event to the Nuget project that just copied the DLLs into the correct folder for you.

There is a much easier way, in which you could use both: project references during development (faster), and package references during production.
In your .csproj project file:
<ItemGroup Condition="'$(Configuration)'=='Debug'">
<ProjectReference Include="../../../Library1/Library1.csproj" />
<ProjectReference Include="../../../Library2/Library2.csproj" />
</ItemGroup>
<ItemGroup Condition="'$(Configuration)'!='Debug'">
<PackageReference Include="Library1" Version="1.0.0" />
<PackageReference Include="Library2" Version="1.0.0" />
</ItemGroup>
In development: project compiled in debug mode, so the project reference will be used.
In production (CI server, docker container): project compiled in release mode, so the package reference will be used.

If all you want to acomplish is to debug the NuGet package I suggest you use "dotpeek debug server" option. This way you don't need to do anything with the reference and simply debug the package or whatever you want.
https://confluence.jetbrains.com/plugins/servlet/mobile#content/view/53336814

Sounds like you want a test project (unit or integration) in the same solution as your NuGet packaged assembly project. Then you can prove it's correctness independently of any consumers of the NuGet package. Good tests will also help ensure you don't break anything unintentionally when updating the package in the future.