Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

ASP.NET 5 (vNext) different dependencies for build Release and Debug

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?

like image 952
developer82 Avatar asked Mar 29 '16 13:03

developer82


Video Answer


1 Answers

Short answer

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.

Example from the ASP.NET Core repository

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>

Workflow for local rapid developoment

Here is an approximation of the workflow that we use. It is enough to get you started.

Produce NuGet packages on build

In Visual Studio 2015, create a new Class Library (Package). Configure it to publish packages to a local directory on build. In other words...

  1. Right-click on the project.
  2. Select Properties.
  3. In the Build tab, select "Produce outputs on build."

Each build will now output the class library as a NuGet package to the solution's artifacts directory.

Automatically publish NuGet packages to a local directory on build

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.

Configure the MVC project to use the local NuGet directory

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.

  1. Choose Tools > NuGet Package Manager > Package Manager Settings
  2. Click Package Sources.
  3. Add a new package source called LocalPackages.
  4. Set its source to C:\LocalPackages.
  5. Click Update.

When ready to publish, replace the LocalPackages entry with the appropriate NuGet source for production.

Pointing at the local packages

Add the local NuGet packages to your project

From the MVC project, access the local NuGet packages.

  1. Choose Tools > NuGet Package Manager > Manage NuGet Packages for Solution
  2. Set the package source to LocalPackages.
  3. Choose the browse tab.
  4. Install the local packages.

Using the local packages

Remarks

(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>
like image 82
Shaun Luttin Avatar answered Oct 10 '22 01:10

Shaun Luttin