We have an ASP.NET MVC 5 project that we are developing that depends on projects from a different solution. The other solution are class libraries that are common, and we publish as NuGet packages. When we release we compile the project and have it take from the NuGet repository, but while we're under development we take the reference from the bin folder of that project.
To get this working we did the follow "hack" to the csproj file of out ASP.NET project (we've manually edited the csproj xml file and changed the reference):
<Reference Include="Common.Utilities, Culture=neutral, processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
<HintPath Condition=" '$(Configuration)' == 'Debug' ">..\..\..\Common\Common.Utilities\bin\$(Configuration)\Common.Utilities.dll</HintPath>
<HintPath Condition=" '$(Configuration)' != 'Debug' ">..\..\..\..\ExtrnBin\NuGetPackages\Common.Utilities.1.0.0.8\lib\net451\Common.Utilities.dll</HintPath>
</Reference>
so when we compile debug it takes from the class library project folder and when we compuile release it takes from the downloaded NuGet. This is very useful for rapid development since we don't have to re-publish a new NuGet for every change.
We are now testing ASP.NET 5, and dependencies are no longer defined in the csproj
file, but in project.json
file. So if we add a reference we get something like this in project.json
:
"dependencies": {
"EntityFramework.Commands": "7.0.0-rc1-final",
"EntityFramework.MicrosoftSqlServer": "7.0.0-rc1-final",
"Microsoft.ApplicationInsights.AspNet": "1.0.0-rc1",
"Microsoft.AspNet.Authentication.Cookies": "1.0.0-rc1-final",
"Microsoft.AspNet.Diagnostics.Entity": "7.0.0-rc1-final",
"Microsoft.AspNet.Identity.EntityFramework": "3.0.0-rc1-final",
"Microsoft.AspNet.IISPlatformHandler": "1.0.0-rc1-final",
"Microsoft.AspNet.Mvc": "6.0.0-rc1-final",
"Microsoft.AspNet.Mvc.TagHelpers": "6.0.0-rc1-final",
"Microsoft.AspNet.Server.Kestrel": "1.0.0-rc1-final",
"Microsoft.AspNet.StaticFiles": "1.0.0-rc1-final",
"Microsoft.AspNet.Tooling.Razor": "1.0.0-rc1-final",
"Microsoft.Extensions.CodeGenerators.Mvc": "1.0.0-rc1-final",
"Microsoft.Extensions.Configuration.FileProviderExtensions": "1.0.0-rc1-final",
"Microsoft.Extensions.Configuration.Json": "1.0.0-rc1-final",
"Microsoft.Extensions.Configuration.UserSecrets": "1.0.0-rc1-final",
"Microsoft.Extensions.Logging": "1.0.0-rc1-final",
"Microsoft.Extensions.Logging.Console": "1.0.0-rc1-final",
"Microsoft.Extensions.Logging.Debug": "1.0.0-rc1-final",
"Microsoft.VisualStudio.Web.BrowserLink.Loader": "14.0.0-rc1-final",
"Common.Utilities": "1.0.0.8-*"
}
it also creates a wrapper folder and copies the DLL to lib\dnx\451
folder.
How can we setup something similar to what we had before to support 2 build configurations?
You cannot avoid republishing; but, you can avoid re-publishing remotely.
On each build of your class library solution, publish a NuGet package to a local directory such as C:\LocalPackages
. In your MVC project, use two different NuGet package sources: one for release, the other for debug. Make the debug source C:\LocalPackages
.
Debug will take from the local NuGet source, release will take from the downloaded NuGet.
The ASP.NET MVC repository uses different packageSources
for different builds. One answer to your question is to use the same approach, but with local packageSources
for development builds.
aspnet release
branch > nuget.config
<packageSources>
<clear />
<add key="AspNetVNext" value="https://www.myget.org/f/aspnetmaster/api/v3/index.json" />
<add key="NuGet" value="https://api.nuget.org/v3/index.json" />
</packageSources>
aspnet dev
branch > nuget.config
<packageSources>
<add key="AspNetVNext" value="https://www.myget.org/F/aspnetcidev/api/v3/index.json" />
<add key="NuGet" value="https://api.nuget.org/v3/index.json" />
</packageSources>
Here is an approximation of the workflow that we use. It is enough to get you started.
In Visual Studio 2015, create a new Class Library (Package)
. Configure it to publish packages to a local directory on build. In other words...
Each build will now output the class library as a NuGet package to the solution's artifacts
directory.
To access all our packages in a single local NuGet source, add the following postpack
script to the class library's project.json
. The script copies the package to our local NuGet source directory. The /y
option overwrites existing files.
project.json
"scripts": {
"postpack":
"xcopy /y ..\\..\\artifacts\\bin\\%project:Name%\\Debug\\*.nupkg C:\\LocalPackages\\"
}
See the remarks for an alternate script that copies both debug and/or release packages.
Open the MVC project that lives in a separate solution. See the remarks for a way to specify the solution's packages without modifying global NuGet settings.
LocalPackages
.C:\LocalPackages
.When ready to publish, replace the LocalPackages
entry with the appropriate NuGet source for production.
From the MVC project, access the local NuGet packages.
LocalPackages
.(1) To use both the Debug and Release packages in our project, use the following postpack
script.
for /r "..\\" %i in (*.nupkg) do xcopy /y %i C:\LocalPackages`
(2) Visual Studio adds NuGet package sources to the ~\AppData\Roaming\NuGet\nuget.config
file. Alternatively, create a nuget.config
in the root of our solution.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="LocalPackages" value="C:\LocalPackages" />
</packageSources>
</configuration>
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With