After enabling PackageReference support for projects, some packages may not install or work correctly

[rrelyea]

As described in a recent NuGet team blog post "NuGet now fully integrated into MSBuild", after enabling PackageReference support for projects such as WPF, Windows Forms, or ASP.NET, some packages may not install or work correctly.

The relevant part of the blog post is referenced below:

Will existing NuGet packages work if I am using PackageReference for WPF, Windows Forms or ASP.NET projects?
While we have done a lot of work to ensure that existing packages on NuGet.org just work with the PackageReference format, there are a few scenarios that will not be supported in the PackageReference world and might impact your ability to migrate away from packages.config. Some examples of scenarios that will not be supported include content folders (we have introduced ContentFiles), XDT transforms, PowerShell scripts i.e. install.ps1 and uninstall.ps1 (only init.ps1 is supported) . If you come across a package you consume in your WPF or Windows Forms app that worked previously but does not work on migrating your project to PackageReference, we would love to hear from you, so that we can investigate what the incompatibilities might be.

The NuGet team is current considering the following steps, and will keep this issue updated with progress:

1. We are working with various project systems to ensure that they have the necessary capabilities to light up PackageReference support.

2. We are currently analyzing packages hosted on NuGet.org (and elsewhere) to better understand the usage patterns of the functionality listed above (such as Install.ps1, XDT Transforms, etc.) so we can ensure a smooth transition to PackageReference usage in projects. We are going to consider this from the perspective of both package authors and consumers.

[emgarten]

@nkolev92

[cazzoo]

Any new from nuget team about files set as content with packagereferences?

[nkolev92]

@cazzoo Can you please clarify what you mean?
Package Reference has support for contentFiles (vs content in packages.config).
Some info here:
https://blog.nuget.org/20160126/nuget-contentFiles-demystified.html

contentFiles are static are static and do not pollute the project directory, but they can still be part of the build/publish steps.

[cazzoo]

@nkolev92 Thank you for the reference. I'll try to use that on a fork of a package that currently uses a ps1 file to copy an exe next to the build.
The mentionned package is WinSCP 5.11.3. Based on what you provided to me, it appears that I'd be able to build a new nuspec file that would do the copy with copyToOutput parameter set to true.

Does that sound good to you?

[nkolev92]

@cazzoo
Yeah that should work.
You can also consider using a build target, in case you need to execute a specific action during build.
\build\packageName.targets

[metatem]

Hi guys. I want to ask if there is a way to support adding a content file with Package Reference to a project but adding it as a "link" to the target project file.

I used to do that with the "install.ps1" and "uninstall.ps1" scripts, but it seems they are not supported in Package Reference mode.

Here is what I actually want to achieve: Linking a file from a NuGet package

[nkolev92]

@metatem
What you are articulating can be achieved with content files.

https://docs.microsoft.com/en-us/nuget/reference/nuspec#optional-metadata-elements
https://blog.nuget.org/20160126/nuget-contentFiles-demystified.html.

You'd have something like

contentFiles/cs/tfm/myFile.extension

in your package.

And then in the nuspec you can specify the copyToOutput and build action metadata.

[dee-see]

@nkolev92 You mention

contentFiles are static are static and do not pollute the project directory, but they can still be part of the build/publish steps.

I'm curious to know how I would define a file to be used in a web project (let's say a branding image to use the same example as https://blog.nuget.org/20160126/nuget-contentFiles-demystified.html) where I want the image to be output somewhere in my project's file structure (let's say an image folder or wwwroot) and not in the bin directory.

Sorry if this is not the best place to ask the question, but I have a hard time finding any information about this in the documentation.

[nkolev92]

@dee-see
Why do you want to do that?
We strongly discourage creating packages that can potentially leave a footprint on the project when removed.

If you absolutely have to do that, the copying of those files is only achievable at build time using build targets as mentioned above.

[dee-see]

@nkolev92
We want to do very much like the Nuget.Server package that ships a favicon and a readme.

How are you planning to migrate that to PackageReference?

[nkolev92]

@dee-see I think that package would be simple to move to PackageReference, simply by moving all content to contentFiles.
It'll just end up in the publish directory in the end.

There are some gaps with ASP.NET full framework projects support for PackageReference that we're looking to address soon.

[dee-see]

@nkolev92 Wouldn't it just put the files in the publish directory's bin through? Without respecting the original hierarchy?

[RussKie]

So all packages relying on install.ps1 are broken "by design" (to name a few: #3656, #4318, #4876, #6330) with no meaningful way to upgrade... Upgrade/migration guidelines (#5963) have never arrived either.

We are essentially put in a situation where there is no way forward, and the Nuget team is taking a stance "it is not supported, sucks to be you". That's just not good enough.

[MarkPflug]

Here is a scenario that is now broken. I have a nuget package that contains an xml schema (.xsd) in the content folder. The intent was that this schema would be copied into the VS project that consumes the package, allowing xml intellisense to "light up" when editing xml documents of that particular schema. VS only seems to discover .xsd files in the project or in the xml schemas folder down under the VS install folder (which isn't an option for nuget packages). If nuget/VS could be enhanced to allow shipping xsd in nuget packages, that would be ideal. I don't really want to copy the xsd into the project, I just want intellisense to light up.

[augustoproiete]

I have the same scenario described by @MarkPflug, and would love to have a better alternative for providing Intellisense, other than copying the .xsd file to the project, but if at least content files (the old way) worked in PackageReference, that would be a big win.

Copying files to a project in general is really useful as it allows us to provide code templates within the NuGet package, that can be used as a starting point, right after the user installs the package.

We need the content files in the packages.config way to work in PackageReference too!

[304NotModified]

Same issue. Please fix this. We (NLog) got multiple complaints because it's broken...

also please stop making breaking changes in non-major versions.

[prmces]

We have in our company a scenario where we need to copy a json file to the root folder with some default configuration for our library. I

I can create the package with the file contents, libraries and stuff... but when installing the nuget package they never get copied to the root folder.

Im using .net standard 2.0 class library

[StingyJack]

RE: non \bin targeted files...

Why do you want to do that?
We strongly discourage creating packages that can potentially leave a footprint on the project when removed.

Well @nkolev92, nuget is a tool that delivers packages to other developers to lessen work or improve quality of their output.

Its incredibly useful when you need to provide things like T4 templates for code generation in a package, or to have the package add/remove its needed entries in the .config file via XDT.

With the install.ps1, I can handle all the things I need to manipulate in a project to ease development that NuGet or the project systems do not normally permit like non XDT configuration manipulation or adding files with a BuildAction of AdditionalFiles instead of Content..

Another person here mentioned branding;. With the death of Bower, we could have counted on using a NuGet package with CSS, script, and images to provide a common look and feel when we build a website for a customer. (Don't bother mentioning the replacement, I dont want or really need yet another package manager. I also have no interest or idea in learning how to make an NPM package for .net projects work)

Where nuget is headed means we cant do any of those things, and all of the reasons and restrictions I've seen over the past year seem to stem from the idea that nuget.org is the only package repository or that all package repositories are public.

If you dont want install.ps1 to be abused by "evil" package authors, then ban the install.ps1 scripts from being included in packages submitted to nuget.org. Offer the feature in Nuget.Server to also prevent them. Don't take a tool away from everyone else just because you are concerned that they will run amok in your house with it.

If you don't like content files (content files or contentFiles) "polluting" projects, then give the consumer the choice at install time. Making that choice for them like this removes a sizeable part of the usability of nuget, and nuget needs to remain a tool that is useful or people will stop using it.

[BrunoJuchli]

@304NotModified
Please describe what's not working for NLog anymore.

[304NotModified]

@304NotModified
Please describe what's not working for NLog anymore.

See this excellent post: NLog/NLog#2823 (comment)

[ticktickMOF]

@StingyJack you can use a msbuild .targets or .props file in your package to include files in the package folder in the consuming project. They won't show up in VS due to being in an imported file.
For example if your package name is Foo and you want to include a cs file located at content/foo.cs, in build/foo.targets or build/foo.props put

<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <ItemGroup>
    <Compile Include="$(MSBuildThisFileDirectory)\..\content\foo.cs"/>
  </ItemGroup>
</Project>

if you have content/foo.css that you want to include as AdditionalFiles

<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <ItemGroup>
    <AdditionalFiles Include="$(MSBuildThisFileDirectory)\..\content\foo.css"/>
  </ItemGroup>
</Project>

There is probably a metadata you can add to the item to make it appear in VS but I don't know what it is.

[WeihanLi]

How to config for new project file to install content file for project?

I use the code below, you can find the source here:

  <ItemGroup>
    <None Include="log4net.config" Pack="true" PackagePath="content\log4net.config" />
  </ItemGroup>

it works for .net framework apps, but it can not work for .net core apps

----------- Update ----------------------------

I'm using the code below, it seemed works on .net core but a little strange.

<None Include="log4net.config" Pack="true" PackageCopyToOutput="true" />

it can not work for netfx project with packagereference, and for .net core project it generated an log4net item that links to the package file like C:\Users\liweihan\.nuget\packages\weihanli.common.logging.log4net\1.0.12.1-preview-20190226-104150\contentFiles\any\netstandard2.0\log4net.config

[StingyJack]

@ticktickMOF - I would think that CSS would be a Content file instead of an AdditionalFile so it gets published correctly.

@rrelyea - Can you point to an explanation of why including and distributing files like config, css, etc. in a (private or public) nuget package is somehow bad for us to do? This enforcement of segregation seems to only remove value from NuGet, and at the additional cost of causing commotion and upset for users. If someone could explain the value of doing (without any of purist/idealism, or fear-mongering) it may help us to at least not be so combative.