Are you trying to create a Nuget package to distribute both static files (CSS, Javascript etc) and your C# assemblies to your ASP.Net Core project? Officially, this isn’t supported, but I’ve come up with a pretty good workaround…

I’ve been re-working Blackball’s internal front-end architecture and one of the technologies I wanted to use was the new TagHelpers in ASP.Net Core. This will be a great mechanism for standardizing our HTML across our clients, while keeping things 100% flexible should our client use a third-party designer.

In addition to the Tag Helpers, our library also includes a number of Typescript Definition files. All of these work together to provide our framework as a whole.

The problem

So far so good, but when it came to rolling things up in a Nuget package, I hit a wall - Nuget will include my (compiled) Tag Helpers without problem, but the static files .d.ts files display only as links in the project that consumes the Nuget package - even if I have packed them as “content files” in Nuget.

This is a problem because the Typescript compiler requires the physical presence of files on disk - a virtual link will not suffice.

Here is a screenshot of a CSS file, for example:

In particular, note that:

• there is a tiny blue arrow on the icon, indicating that this is a virtual linked file

• the full path actually refers to the Nuget repo hosted on my computer

What this means is that the project compiles properly, but when the browser makes a request to /css/foundation/foundation.css, we get a 404.

Now, with a CSS file, you can use ASP.Net Core’s ManifestEmbeddedFileProvider to serve the content, but with .d.ts this won’t do because, again, the Typescript compiler does not route through the ASP.Net Core pipeline - it requires the physical files on disk.

This meant that I simply could not deploy my .d.ts files via Nuget.

The fix

I tried all combinations of PackageReference, Nuget, Nuspec, dotnet pack, nuget pack, contentFiles tag, files tag - everything I could find online. But it got me nowhere and more and more I kept seeing that Nuget is not intended to deploy content files - for that you should use npm or similar.

The problem with using npm is:

• my architecture specifically includes both server-side and client-side modules. If I reversion something, my developers would need to remember to upgrade both their npm and Nuget dependencies - keeping them precisely in sync

• I can’t be bothered maintaining an npm package in addition to my Nuget packages

So, I came up with this handy piece of code which does the trick…

Step one - indicate the files you want to publish by setting their Build Action to ‘Embedded resource’

Step two - exclude the files you do not want, by setting their Build Action to ‘None’

Step three - use the built-in Project -> Properties -> Pack to configure your Nuget package

You do not need to create a .nuspec file.

Step four - create your Nuget package using dotnet pack

Here is the command line I used, yours may differ. Note that we are referring to the .csproj file - not a .nuspec file:

At this point, you now have a Nuget package file which contains all your static files embedded in the assemblies. So, how do we get them out?

Extracting the embedded content in your consuming package

The basic idea is that you install the Nuget package in your consuming project, then on Startup, you interrogate the Nuget DLL, extract the Embedded resources and save them to disk - right into your project structure. Here is the code that does it:

It’s actually a pretty simple class. Of note:

• there’s lots of room for improvement. You could customize the file location you save to, for example

• I recommend including this file in the Nuget package itself. After all, it is deployed to your consuming project along with the static files. That’s what I have done.

• it only adds files. With a bit more time, you could track what files were added, and then remove them if an updated Nuget package no longer contained them

• it overwrites files every time, which adds a big performance hit. With a small project, you don’t notice, but ultimately I’ll need to add a CRC file or similar to avoid constantly rewriting over existing

• it only needs to be called when in developer mode.

Finally, you can execute this class wherever you like. For now, I’ve created an extension method (again, in my Nuget package)…

…and then call it in your Startup class:

And that’s it!

It’s frustrating and weird that Nuget doesn’t seem to want to support content files and assemblies. But oh well, here we are. I hope this class helps some other people in my situation.