Enable support for 'content' folder with PackageReference

[anangaur]

With PackageReference, we started supported content files from contentFiles folder than the existing content folder that was supported with packages.config.

It is getting real difficult for users to be able to influence the package authors to update the existing packages to use contentFiles in addition to content folder to support both PackageReference and packages.config.

Instead we may choose to support additional attribute on PackageReference to use the content folder in the absence of contentFiles in packages.

Examples of issues faced by developers:
On the docs page:

cc: @jainaashish

[nkolev92]

Authors will be more open to making changes to expand their user-base if they see willingness from the consumers to use their packages with PR.

It's not a difficult change to make from their side. We're the ones that need to make the contentFiles experience more seamless (for ex. jquery with contentFiles, a user would want to be able to open those read-only content files in VS, that's not possible today).

This whole thing comes down to actually promoting PackageReference in general, it's pros over packages.config, rather than bridging gaps such as content vs contentFiles.

More over, you need to consider the scenarios for which people use content files. Will just treating content as contentFiles buildAction=None or any other value actually fix the problem?

If they're using content only as a replacement for the non-existence of static files in NuGet v2, then their migration to PR should be seamless.

If they're using content for other scenarios such as xdt transforms, this is a gap that we're not even considering fixing.

XDT transforms are done during build/publish and that's not going to change.

If they're using content for any other scenario, then adding them as static simply won't work.

It might work, but there's some analysis to be done.

jm2c

[rohit21agrawal]

what are we going to do about packages which have both then?

[anangaur]

As I mentioned this would be fallback i.e. only if the contentfiles folder is not present.

[rohit21agrawal]

supporting content folders in PackageReference is basically killing the contentFiles folder. Do we really want to go down that route?

[anangaur]

Note: This option is not the default option and will not be the default option. So recommendation for package authors is still to use the contentFiles folder.

This option is for users who are stuck with a package that does not have the contentFiles folder, they can make the content folder work.

[StingyJack]

If they're using content for other scenarios such as xdt transforms, this is a gap that we're not even considering fixing.

Is that "don't misuse content ", or is that "xdt transforms will not have an equivalent in package ref"?

[nkolev92]

@StingyJack
It's more of the don't misuse content.

xdt transforms work differently in PR as shown in this example.
https://github.com/NuGet/Samples/tree/master/XDTransformExample/

[StingyJack]

I use xdt for config transforms for at least one package, and that example doesnt look much different than I already have (its +targets, but -uninstall). Are the docs pages incorrect then about config files?

[StingyJack]

It is getting real difficult for users to be able to influence the package authors to update the existing packages to use contentFiles in addition to content folder to support both PackageReference and packages.config.

Why should we (users or authors) have to influence change anything?
What is the value this change gives us?

An explanation of how the change makes work easier or how it translates into more output or output of a higher quality is needed, not just a mouthful of buzzwords. In this scope, the value reads as only "conformance to a new spec", but that holds no value and thus only coerces us into more work now or later. The NuGet team has been very guilty of this in the last year or so, and its not like this is an open spec where there is community or committee representation or an interconnection spec for an emerging, necessary technology - its just some roadmap. Please make an effort to consider the ripple. It's never too late to re-assess a position..

[anangaur]

Am I missing something? I think whatever you state above is the reason why this issue exists - to improve the existing behavior to start supporting the content folders.

Today PackageReference does not support content folders and I would not like to change an existing default behavior as existing builds may start showing different behavior with this change. Instead the proposal is to enable users to be able to use the content folders which is much easier than getting the packages to support contentfiles folder

[StingyJack]

Am I missing something?

...just a few months of conversation and complaints I've been having with 3-4 of your coworkers. From my perspective as someone who uses nuget packages and authors private use packages for my coworkers to use, the change from package.config to package ref is an entirely negative value change. I'm not getting less day to day work, but I am going to have to spend the better part of 4 weeks (making the change and a cursory smoke test) moving our projects from package.config to package ref. And this is something that has to be done, because any time I log an issue and mention we still have packages.config, it immediately gets tagged as "packages.config" and closed as 'wont fix'. This means I have to create some workaround for the defect or issue - also at my expense. MSFT usually has 5/10/20 year support cycles on things, so I wont be upset about you not wanting to deal with Windows 7, but I've been getting the same response on other fronts for more recent products (TFS 2015 for example). All the changes you seem to want to make are of the "lift-and-shift" variety, and asking that I do the lifting, and I haven't discerned any concrete, non-perfectionism reasons why pref > pcfg.

For the thread at hand, my questions are directed similarly. What is the need for trying to force package authors to re-create packages or create a secondary work streams, when there is already a way to include content files? It just looks like you decided to forget the element existed and built it again, but at the expense of the entire userbase.

• "Content files in a folder"
• "The content files folder"

These two sets of words mean the same thing in terms of artifacts that are not references or tools or source code that go into a nuget package. The slight difference is that one implies there could be many folders, but the existing content files declarations let you place content files in many folders already.

I think whatever you state above is the reason why this issue exists - to improve the existing behavior to start supporting the content folders.
Today PackageReference does not support content folders

These two statements feed that confusion. How can authors even begin to use something that does not exist? or rather Why didnt you just use the thing that was already there?

If these two content things are remotely equal, and a significant feature including content files works for packages.config but not package ref, how can you consider packref to be production ready, or ready enough to stop fixing bugs in packagecfg? Or worse - blocking the installation of things like jQuery via nuget, and the other avenue of consuming that package is removed by dropping bower support?

[anangaur]

Taking about the current issue at hand, what is your expectation? How should this issue be fixed?

• start supporting content folders by default. This has the possibility of breaking existing users who use PackageReference and do not expect content folder’s assets to available.
• support content folder with a special attribute(option) in PackageReference so that users who use existing packages with content folders do not start to see a different behavior suddenly.
• ?

[StingyJack]

I expect to be able to install something like jquery, as I have for the last several years, without having to bother the author to reauthor or reorganize a package and without me having to do any additional work or delays (that has not been planned for as it is not expected)

There is no difference to me between content files and contentFiles. They are files to be included in the project that will carry the "Content" build action. If the complaint is that users may need them in places other than where the author set them in the package, then its a matter of opting in to redirecting the content files with some sort of declared configuration for that package*. It doesn't necessitate an entire parallel feature that makes more work for all involved with little or benefit, or that creates confusion and negativity due to horrid naming (like the multiple annotates now in my VS context menus).

* if this is because of ASP.NET Core project formats, then VS or nuget can be made to take care of that automagically. Or they should be tarred and feathered for picking a project layout that breaks established, popular tooling, and have to fix that format or handling.

[Zhaph]

I'm still looking for some clear guidance on how this should work - We've built a number of front-end pattern libraries that we include in our ASP.NET Web Projects (not core) via private NuGet packages. They consist of nothing except content files that aren't supposed to be edited by the consuming project (compiled/minified JS, CSS, fonts, images).

With the packages.config, it's very obvious that these files are included in the project correctly and can be easily packaged along with the build output for publishing/deploying further on.

I've just been trying to "update" my nuspec to use the new contentFiles approach, and as far as I can see, there's no reference to the included files in the solution, or indeed on the disk where I'd expect them, even after builds, etc.

I'd expect to be able to see the included folders in the root of my projects so that I can run the web application directly from the source location, but with no clear idea of where the .css or .js files are I can't reference them from my Layout Pages.

It's also telling that packages such as Microsoft.ApplicationInsights.Web and JQuery which also include content haven't updated to this way of working, and so can't be used with the prefs method.

Trying the ContentFilesExample I was unable to see the apparently included txt or image files in my project even though their buildAction is Content - is there a working example somewhere?

[jlchavez]

@StingyJack
It's more of the don't misuse content.

xdt transforms work differently in PR as shown in this example.
https://github.com/NuGet/Samples/tree/master/XDTransformExample/

Sorry for being late to the party.

But whe are here on the NuGet repository, so XDT transformations on the Build stage should be cared by MSBuild. Yes, I know, this is through a .targets file. But them we need this to be an out of the box solution, that Microsoft provides to Visual Studio/.net developers. You have the example, why should we fork it to a new project that the world has to maintain thousands of times?

Now, if we are talking about XDT transformations for a nuget package, is about adding certain features to an XML file on the project when the nuget package was installed or uninstalled, as we used to do in package.config. We might have added a ".update.xdt" file or something if we need to add something, may be that need a little more to think of.

.net core might be the king of flavor you love, where everyone has to code their way through, so if we have 3 million customers, and they need to add one line 3 million times, it's not "microsoft business", they can do it, it would take less than a minute, that would be less that 3 million minutes right? We'll after all I display a "readme.txt" so that everyone knows that they have to waste that minute reading, and on every project they want to use it.

I make my own packages, for whatever I like to do, as the programming concepts of DRY, and making assemblies, packages, inheritance, and everythig else. So if I need to create a new project I won't do the adding of references manually, and modifying a lot of code by hand just to bring the project up to a usable site...

I've been a develepor since 1991 (MS GW-Basic), a .net developer since 2001 (beta), changed to .net core until 2018, and I'm sure I can tell you that the files .Ps1, .xdt, and content files are very useful for getting work done faster. I've decided to go back to .net framework (asp.net) so that I could use the wonderfull server side controls, which noobs hate, but I've done my own controls like forever, so I'm not worried about "html" or "tables" or "session state" (never used it) or "viewstate" since I minimize the use of it. Taghelpers was the worst replacement for productivity.

PackageReference has been a better way to handle what we've added in our project, It's magical, but well, I've always thought about why you didn't added a content folder for specific content for asp.net WebForms or asp.net Core, since you wanted it to be different, and like the "lib" folder with all the subfolders, so that any one can understand we're are this files going to end. Even it could have been useful to know that some content would not be added to a project because it's not a asp.net WebForms project, it was WPF, WinForms, UWP, Xamarin or whatever flavor of app you are developing.

Hopefuly for .net 5 we might reduce complexity of all this spaghetti, and that Microsoft is not planning on add more complexity to the tooling we have already. We have to have the better of both worlds, .net framework and .net core, remember? You might not see usefulness of somethings, may be not a lot of people know about those nifty tricks of XDT, ps1 and addig content files, but we could teach them how to use it, or at least give them very well prepared nuget packages that guide them on how to use it. Event XDT could have some improvements for matching nodes.

For an example of why content files are good, "Identity" has already been included in asp.net core template, but there is no user and role management pages for the administrator, building a "VS Package" for adding a "Item Template" won't add "nuget packages", or show a "wizard" for tweeking anything like scaffolding because "SideWaffle" is the "Wizard"... and the same goes to building a new project template for asp.net core with identity management. We can't even add our own scaffolders, because their is no responde by any one of how you plugin a new scaffolder. This is just to keep in mind that we should have learned from the past our best practices, and not thowing it all away just because we are not up to, or we don't undertand the best use cases for what we already have.

[RobertArmic]

While i do not agree with initial decision to not support "content" in packages config, i see no posibility to change this in non-breaking way (at least no clean way).

So i vote to close this issue.

If you have to copy files to output this can be dona with targets (you get a lot of control this way), this is an example how i made a nuget package copy static file to bin:

</Target Name="VarsAndNotifyCopyConfigToOutDir" AfterTargets="Build" >
</Message Text="VarsAndNotify: Regenerating VarsAndNotify.config in OutDir" Importance="High" />
</Copy SourceFiles="$(MSBuildThisFileDirectory)VarsAndNotify.config"
DestinationFolder="$(OutDir)"
SkipUnchangedFiles="true"
/>
<//Target>

[StingyJack]

I need the files - code and tt files usually - to be added to the project. They are legitimate compile files that need to be present before the compile starts.

Same goes for in house developed and used UI themes and styles. I want those scripts and css files included with the project so we can tweak and adjust them. Nuget was fine for this and it wasn't a security risk.

I'm using a package with a license that allow me to do what I want with the thing. It's not ok that you are coercing me to give up that