A few weeks ago I posted about how to set up a class library project to target multiple .NET platforms in a single project. Essentially you can specify multiple targets directly in the project.json file and then use KPM Pack (or Visual Studio) to build a Nuget package for all the different build targets, which is a pretty nice feature if you’ve ever built multi-targeted code before and that involved setting up separate projects for most targets.

So using Visual Studio 2015 you can build a single project with both .NET 4.5 targets as well as vNext targets (Core or full CLR) and that’s pretty awesome.

Where’s the ‘Add References’ Option?

However, there’s no built in mechanism in Visual Studio 2015 in a vNext project to ‘Add Reference’ and while that makes perfect sense for vNext projects (especially CoreClr) it’s something you will need to do for the classic .NET targets in a vNext project. As you probably have heard by now, vNext projects expect everything to be added as NuGet packages rather than as assemblies, but if you are building for non vNext targets (or for the full CLR vNext target) you are still going to need the ability to add GAC references and possibly some loose assemblies (although I honestly haven’t done that in ages – everything external pretty much comes from NuGet or another project in the same solution which is supported just fine by vNext projects. For the non vNext projects through the GAC references are going to be unavoidable.

Adding a GAC Reference

Adding an assembly reference is done via project.json and using the frameworkAssemblies key:

"frameworks": {
    "net45": {
        "frameworkAssemblies": {
            "System.Configuration": "4.0.0.0"
        },
        "dependencies": { }
    },
    "aspnet50": {
        "frameworkAssemblies": {
            "System.Configuration": "4.0.0.0"
        },
        "dependencies": {
                
        }
    },
    "aspnetcore50": {
       "dependencies": {
            "System.Runtime": "4.0.20-beta-*",
            "System.IO": "4.0.10-beta-*",
            "System.IO.FileSystem": "",
            "System.Runtime.Extensions": "4.0.10-beta-*",
            "System.Text.Encoding": "4.0.0-beta-*",
            "System.Text.RegularExpressions": "4.0.0-beta-*",
            "System.Linq": "4.0.0-beta-*",
            "System.Reflection": "4.0.0-beta-*",
            "System.Reflection.Extensions": "4.0.0-beta-*",
            "System.Reflection.TypeExtensions": "4.0.0-beta-*",
            "System.Threading": "4.0.0-beta-*",
            "System.Threading.Thread": "4.0.0-beta-*",
            "System.Globalization": "4.0.0-beta-*",
            "System.Resources.ResourceManager": "4.0.0-beta-*"
        }
    }
}

Notice the frameworkAssemblies key which allows you to specify GAC registered assemblies and their version number. You can use this key in classic .NET targets as well as in the FullClr vNext project which can reference both classic .NET NuGet reference (anything you’re used to using today) as well as GAC assembly references.

When you look at the project tree in the Visual Studio Solution Explorer with the above you now see the System.Configuration reference in both the .NET 4.5 and the Full CLR vNext projects:

As you can see both the .NET and vNext Full CLR projects can see the reference. The CoreClr project on the other hand does not have the reference and if you try to add it there you will get the reference show as an error with the yellow error triangle.

What about Loose Assembly References?

Currently that is not supported in any way. You can’t use the dependent assemblies key to add loose assemblies to the project, although according to David Fowler there’s some discussion that support for this might be added in the future. But I have to say I’m with David on this one: The use case for loose assemblies is shrinking by the day as most of us get assembly references for third party code from NuGet or for internal code you can either reference a project with the code, or build a NuGet package to make it distributable and if necessary provide it from a private feed (which can be nothing more than a folder on your machine or the network.  Additionally with vNext projects you can very easily build NuGet packages as I outlined in my last post so going forward NuGet will simply be the unit of distribution.

Single Code Base Many Targets

It’ll be interesting to see how moving to the new project system works out. Personally I like the way that project.json works with a simple disk based structure and only requires dependencies in project.json. It’s a lot cleaner than the gobbledygook build target code in .csProj and .sln files that most people (including myself for the most part) have no idea how it all hangs together – we’ll leave that stuff to @sayedihashimi…

But it’s definitely different and it means that existing .csproj based projects have to be moved to take advantage of this functionality. Multi-targeting too will require some experimentation and making a decision on whether you want to build one project that provides features for all supported platforms, or whether you factor out separate projects in the way we pretty much have to do today. For me I think and some of the libraries I have I suspect the new model with bracketing code with #if blocks likely will work… we can probably gauge how well this works by how much of the third party stuff moves to vNext quickly once it ships.

Related Posts

• Creating Multi-Target NuGet Packages with vNext