Once https://github.com/dotnet/cli/issues/3199 gets resolved, Victor's answer should work. In the meantime, I'm using the following work around:
Overview
Every time I build my class library project, I'm creating a NuGet package with new version numbers. My ASP.NET Core RC2 project.json references that NuGet package as a regular dependency with a wildcard (*) version reference. I then, have my ASP.NET Core RC2 project restore packages after each time it builds, that way it picks up the latest changes.
Solution
Create NuGet Package After Each Build
In your class library project, add a NuGet reference to https://www.nuget.org/packages/CreateNewNuGetPackageFromProjectAfterEachBuild
This will create a folder structure in your project like this:
Edit the Config.ps1 file and change $appendConfigurationAndPlatformToNuGetPackageFileName to $false. (I found my reference wasn't working correctly with this set to $true)
If you want to be able to debug into your class library project, change $packOptions = "" to $packOptions= "-Symbols"
At this point, if you were to build your project, a NuGet package would be created in your output directory (typically bin). This script uses the AssemblyInfo.cs file to drive the version number of the package.
Update AssemblyInfo.cs version
Let's add a script to update that assemblyinfo.cs file version after each build now, and change the location of our NuGet packages to a local repository.
I went and added this script to my project: https://github.com/eoincampbell/powershell-scripts/blob/master/Update-AssemblyFileVersion.ps1 Everytime you call it, it will update the AssemblyInfo.cs version numbers.
I tweaked the script a bit to update the AssemblyFileVersion and AssemblyVersion lines. Change
if ($_.StartsWith("[assembly: AssemblyFileVersion")) {
to
if ($_.StartsWith("[assembly: AssemblyFileVersion") -or $_.StartsWith("[assembly: AssemblyVersion")) {
Build Automation
Now we want this script to happen after each build, that way we don't have to manually run the script each time. Also, I'm going to change the location of the NuGet output of my class library, since I have multiple class library projects in my solution referenced by the ASP.NET Core project.
Edit your class library .csproj file. You'll find something similar to this:
<PropertyGroup>
<PostBuildEvent>REM Create a NuGet package for this project and place the .nupkg file in the project's output directory.
REM If you see this in Visual Studio's Error List window, check the Output window's Build tab for the actual error.
ECHO Creating NuGet package in Post-Build event...
PowerShell -NoProfile -ExecutionPolicy Bypass -Command "& '$(ProjectDir)_CreateNewNuGetPackage\DoNotModify\CreateNuGetPackage.ps1' -ProjectFilePath '$(ProjectPath)' -OutputDirectory '$(TargetDir)' -BuildConfiguration '$(ConfigurationName)' -BuildPlatform '$(PlatformName)'"</PostBuildEvent>
</PropertyGroup>
Add a PreBuildEvent to run your script, and change your -OutputDirectory to a local NuGet repository (should you already have one). Otherwise, you can dump the packages to a shared folder for all class libraries of this solution (which is what I did)
<PropertyGroup>
<PreBuildEvent>
ECHO Starting Pre Build Event
PowerShell -NoProfile -ExecutionPolicy Bypass -Command "& '$(ProjectDir)_CreateNewNuGetPackage\DoNotModify\Update-AssemblyFileVersion.ps1' -assemblyInfoFilePath '$(TargetDir)..\\..\\Properties\\AssemblyInfo.cs'
</PreBuildEvent>
<PostBuildEvent>REM Create a NuGet package for this project and place the .nupkg file in the project's output directory.
REM If you see this in Visual Studio's Error List window, check the Output window's Build tab for the actual error.
ECHO Creating NuGet package in Post-Build event...
PowerShell -NoProfile -ExecutionPolicy Bypass -Command "& '$(ProjectDir)_CreateNewNuGetPackage\DoNotModify\CreateNuGetPackage.ps1' -ProjectFilePath '$(ProjectPath)' -OutputDirectory '$(TargetDir)..\\..\\..\\LocalPackages\' -BuildConfiguration '$(ConfigurationName)' -BuildPlatform '$(PlatformName)'"</PostBuildEvent>
</PropertyGroup>
If you were to build now, the NuGet packages would be created each time, but your ASP.NET Core application wouldn't pick up the new packages. To resolve, this, I added a pre compile command to dotnet restore.
Note: intellisense is not right, use precompile not prebuild (see https://github.com/dotnet/cli/issues/3338 for more info)
"scripts": {
"precompile": "dotnet restore",
"prepublish": [ "npm install", "bower install", "gulp copy", "gulp clean", "gulp min" ],
}
ASP.NET Core RC2 project.json
My references are just normal dependencies:
"dependencies": {
"Microsoft.AspNetCore.Mvc.Core": "1.0.0-rc2-final",
.
.
"Lib.IO": "*",
"Lib.Core": "*",
"Lib.Data": "*",
}
Outstanding Issues
I haven't bothered writing a script to clean up my NuGet repository,
because after a day of coding, I'll find dozens of my class library
packages. For now, I just manually clean them out at the end of the
day/week.
Every time you build ASP.NET Core, it may take quite a while, since
your restoring packages prior to every build. If you're really
creative, you could execute a script instead to detect if a newer
class library package is available, and run dotnet restore then.
This is the biggest pain. Every time you make a change to your class library, you must remember to build it, since your web project no longer has a project reference, it won't automatically build your class libraries.
