How can I share common js/css in an MVC app?

Question

I have a number of solutions. There is much overlap, so that code goes into another solution of "common" code, and I reference it as a DLL or git submodule.

But there's also lots of common JavaScript and CSS, and even some .config files and XML. I need to duplicate them for every solution!

How can I pull shared js/css into a solution? Keep in mind the shared assembly's DLL won't contain those static files.

Also, importantly, I need to be able to reference those js/css files in MVC's bundling system (that's the whole point, after all).

Answer 1

OK I found a way which works, is simple, self-contained - and does not need a local nuget server (which is overkill for something so simple, and I prefer less tools and less servers if I can help it).

Note: my common code, styles, scripts, everything are contained in a git submodule in my solution. If you don't work this way, just adapt the paths below to point to your shared stuff.

Add to pre-build event to delete all files (not required, but deletes files from destination which were deleted in the source):

rd /S /Q "$(ProjectDir)Scripts\include"
rd /S /Q "$(ProjectDir)Styles\include"
md "$(ProjectDir)Scripts\include"
md "$(ProjectDir)Styles\include"

Add to post-build event to copy files:

xcopy /D /S /F /Y $(SolutionDir)gitsubmodulename\projectname\Styles\*.min.css $(ProjectDir)Styles\include
xcopy /D /S /F /Y $(SolutionDir)gitsubmodulename\projectname\Scripts\*.js $(ProjectDir)Scripts\include

If using git, add those directories to .gitignore:

/*/Scripts/include/
/*/Styles/include/

Pros:

• At every build, new/changed files are pulled into your web project
• Since they are placed within the scripts/styles directories, they can be served in both debug and release modes
• Bundling works exactly as you'd expect. To deploy, just do a regular bin deployment
• You can make changes to the source files (in the git submodule, not the web project), and build, and the changes are available immediately (no need to edit, repack, update, etc. nuget packages)

Cons:

• ?

Answer 2

If you are going to have a lot of this, build your own nuget packages and host them on a share or on your own private nuget server. It's remarkably easy to do, you get to execute scripts if necessary when the package is added to your project, and nuget packages are versioned, so you when you update your library, you can release an updated package with an incremented version number, and they will coexist.

Answer 3

There's no way to truly share static resources between projects, and especially between solutions - at least in the sense that you have only one copy of the file. For most things, adding an item as a link will usually work, but static resources don't fall under that umbrella, especially if you need them to work with the bundling system.

However, you aren't without hope. The best way to achieve this is actually to create your own Nuget package. You can have a project/solution that contains all these common resources and use that to build a Nuget package from. Then, you can install this Nuget package in your other projects/solutions. When you make changes to the static resources, release an update to the Nuget package and then upgrade all the projects that utilize it. You can even create a private Nuget repo so that the packages are only available internally.

Here's a few resources to help you in that endeavor:

• Creating and Publishing a Package
• Using A GUI (Package Explorer) to build packages
• Hosting Your Own NuGet Feeds

Answer 4

Just toying with some ideas, but some possibilities:

• a post-build copy into the appropriate bin directory
• a T4 template (which runs on build) which pulls in the external files

Though they are both "hacky"...

• Also there is maybe the possibility of a custom VirtualPathProvider, but that I think assumes you have access to IIS.

Also
- A working method to include them as linked files, but only works in RELEASE mode