NuGet package contentFiles artifacts installed as links in ASP.NET Core MVC project

耗尽温柔 提交于 2021-02-05 07:59:05

问题


We have an internal JavaScript library that we'd like to share between multiple projects. Actually we are already sharing it via file copying, but this has (predictably) resulted in multiple forks of the code.

The consuming projects are a mix of "full" ASP.NET (MVC and Web Forms) and ASP.NET Core MVC. (I'm planning on creating two separate packages.)

Installing into ASP.NET projects seems to work fine, but I'm having problems with ASP.NET Core.

Initially I had all the artifacts within a files element, and nothing at all was showing up in the consuming project. After re-reading the docs, I realized that ASP.NET Core projects would use a PackageReference ... so I would have to use a contentFiles element instead of (or in addition to) a files element.

I created a contentFiles folder and a script to copy the requisite files from the source project folder structure into contentFiles/any/any/wwwroot/lib/ourAwesomeWidget, and modified the package manifest accordingly.

This works. Sort of. The package appears to get build correctly. The files do get added to the consuming project, but they get added as links; the actual files (the link targets) reside in my local package cache.

The relevant portion of the package manifest is:

<metadata minClientVersion="3.3">
    ...
    <contentFiles>
        <files include="**/*" buildAction="Content"  
               copyToOutput="true" flatten="false" />
    </contentFiles>
</metadata>
<files>
    <file src="contentFiles\**" target="contentFiles" />
</files>

Part of the issue is that I don't find the docs very clear concerning contentFiles. All the examples show a single file element ... but the include attribute on the files element is required, so it's not clear what the individual file elements would even do.

Is there a way to get the actual files (not links) added to the consuming project? Or, alternatively, is there a way to get the package to install as a "normal" package (rather than a PackageReference)?

Update: I did some further digging and found this answer by @Martin to a similar question -- but he answered this one before I had a chance to update it.
It appears this behavior (adding files as links) is by design.

I find this highly unsatisfactory, because (as @Martin points out), our JavaScript library will not be available during development on consuming projects.

But part 2 of my question still stands. According to the docs,

By default, PackageReference is used for .NET Core projects, .NET Standard projects, and UWP projects targeting Windows 10 Build 15063 (Creators Update) and later.

Is there a way to trigger the non-default behavior, i.e. allow .NET Core projects to consume packages other than via PackageReference?


回答1:


contentFiles are supposed to be added as a link. The contentFiles section controls the msbuild items that are generated for these files into the obj\projectname.csproj.nuget.g.props file.

The copyToOutput="true" will cause the items to be copied to the output and publish directory. However that does not help you when running the application during development, since it will be run from the project directory, not the output directory.

Consider consuming client libraries via npm (since bower is deprecated).



来源:https://stackoverflow.com/questions/48994668/nuget-package-contentfiles-artifacts-installed-as-links-in-asp-net-core-mvc-proj

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!