ASP.NET v5 on build server

Well, there is no .csproj in the dnx project, everything you need to create dnu for the project is contained in project.json

. There is an xproj file, but you can ignore it. Microsoft has finally decided to see the light of day and only uses xproj for VS-specific "stuff", and the details of an agnostic IDE project are placed in project.json.

So, to create a dnx project, you only need the correct dnx version and the source code of the project. Now AFAIK there are no out-of-the-box solutions, but everything is done using command line commands, so script something should be easy. It all depends on how robust the solution you want to build is.

To create a dnx project from the command line (assuming you have the appropriate dnx installed and set to active), these are just two commands. dnu restore

runs dependency checking, and dnu (part of dnx) has a built-in nuget client, so it will fetch and grab dependencies when needed. dnu build

runs this actual compilation.

So, cd to the root of the project (which contains project.json) and run dnu restore

then dnu build

.

It gets more complicated if you need to dynamically maintain different dnx versions. Be aware that dnx versions are identified by runtime (coreclr or clr), architecture (x86, x64, etc.), and version number. So if you're only aiming to create an x64 build on clr (full .net runtime) that removes two variables, but what happens if the project requires a newer version of the runtime than what's installed on the build server? For example, you installed (manually using dnvm) dnx-clr-win-x64.1.0.0-beta4 on a build server, but at some point in the future a developer needs dnx-clr-win-x64.1.0.0-beta6- 1200 to fix the problem.

The simplest solution would be to just install newer versions at runtime and build all projects against the newest one. This is not as bad as it might seem at first glance. Once dnx exits beta, the runtime should be infrequent. Remember, runtime is very low level code and unmanaged DLLs. This is the botstrap stub that BCL sits on top. Hopefully there shouldn't be many changes to dnx for a given OS, architecture and runtime.

For a more robust solution, you can use scripts to find the runtime required for the project. He is at the decision level global.json

. The script could then use dnvm list

to determine if that runtime was set. If it does not use, then use dnvm install

or dnvm upgrade

to install the required version. Before starting the build, it will use the command dnvm use

to make the correct working environment active and then continue with dnu restore

and dnu build

.

To be honest, I expect you to have some pretty strong solutions. Runners tasks (gulp, grunt, etc.) are first class citizens in .NET 5. Most likely your workflow will include a conversation to resolve client side dependencies, npm, grunt / gulp and some task packages for such things like minifying js files, Build Server will need all of this, so the build task as a gulp or gulp package seems pretty good.