Using the same static data in both C# classes and JS files in the same MVC project without rebuilding again and again at runtime

Question

Issue

My issue (in as general term as I can put it) is that: * Have some static data (changes rarely and requires a re-compile of the site) in the form of a series of configuration strings like URI, hash, etc for several files that needs to be use in both the c# of the MVC site as well as some of it in some JavaScript. * We don't want to duplicate the data as it's bound to get out of sync and cause us all sorts of hard to track down bugs. * Ideally we would like to create the JS file with the data inserted into it at build time taking the data straight from the c# class it's stored in so it doesn't cause lots of wasted time re-building the JS each time it's asked for and nether does the c# class need to dig around in a js file trying to pull out the data.

Research so far and potential solutions

T4 Text Templates

We have considered T4 (.tt Text Template) to build the JS but have only just come across T4 and have not yet found a way (if one exists) to access existing project classes in the T4 file to generate the JS.

Using something like Gulp

We could also use Gulp and build something in JS to extract the data from the class file directly to build the JS but up to now we have stuck with NuGet, a few VS extensions and our TFS deployment server and didn't really want to add the complexity of Gulp and ether switching everything back over to it or splitting our build across Gulp and MSBuild/TFS. We have a little experience with this and found it caused us more issues with keeping it running than it's worth.

Build & cache JS file at runtime

As mentioned we could also create a page that builds and returns the JS at run time. We could cache the output after the first build as it wouldn't change but that's still hitting my MVC instead of just a file and the cached data would need to be stored and retrieved.

This last method (Build & cache JS file at runtime) is the one I'm leaning towards as it would be the cleanest, easiest to follow by new devs in the future and wouldn't require any extra packages/libraries adding to the project.

Answer 1

While building and caching the .js file at runtime is certainly an option, this would waste a small amount of both RAM and CPU cycles on the web server. Not to mention, the caching could cause confusion during debugging.

IMO, a better option would be

1. Put the static data into a common file format such as JSON or XML
2. Use T4 templates to read the common format and build both the .js and .cs files
3. Create a batch file to run the T4 transformations and add it as a pre-build event in the .csproj file as in this answer

That way the files are built with the data as part of the normal build process (including during debugging), and the .js file can be deployed as a static file to the server as part of the normal deployment process. To help avert confusion, the T4 template can include a warning not to modify the output files during development.

//------------------------------------------------------------------------------
// <auto-generated>
//     This code was generated by a tool.
//
//     Changes to this file may cause incorrect behavior and will be lost if
//     the code is regenerated.
// </auto-generated>
//------------------------------------------------------------------------------

You could of course replace T4 with a custom built console application that reads the source data from JSON or XML if you aren't familiar with the T4 technology and don't want any extra .tt files in your project that may confuse new developers. But you should take into consideration how often the .cs and .js files will change in development - T4 doesn't have to be compiled into a tool in order to use it.

Gulp is also an option, but it isn't worth adding it to the build pipeline for something as trivial as this. Only consider it if you are already using Gulp in the application or build.

But however you slice it, this sounds like a better candidate for a build step than something that happens at runtime.

Answer 2

The solution we went with in the end was to run the creation code when the website first runs by adding a call in the Application_Start() (called/or Global.asax) like this:

protected void Application_Start()
{
    ...

    // Generates (replacing if required) all the static files that require dynamically creating
    DynamicFileConfig.GenerateStaticFiles();
}

This allows the application/website to be up and running and giving us access to all the classes for this project without needing to split them out or add any complex libraries.

It also requires no extra build steps or any extra maintenance and in our case the processing time is done during the release (as our release system tests the site kicking off the Application_Start() code).

The code that kicks off is just a small static class with static functions the generate the file (it's not stored in our repo) or replace if it's already been created.