Specify exact version of a project dependency

[Necroskillz]

Details about Problem

NuGet product used (NuGet.exe | VS UI | Package Manager Console | dotnet.exe): dotnet.exe

dotnet.exe --version (if appropriate): 2.0.0-preview2-006497 / 1.0.4

OS version (i.e. win10 v1607 (14393.321)): win10 enterprise

Worked before? If so, with which NuGet version: works with .nuspec files

Detailed repro steps so we can see the same problem

Right now we have .nuspec files that reference a package built from the same solution. We set the version to be an exact version.

Example:

Solution.sln
 | - Project.Web.csproj
 \ - Project.Core.csproj

Old Project.Web.nuspec:

<package xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <metadata xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
    <id>Project.Web</id>
    <version>$version$</version>
    <dependencies>
      <dependency id="Project.Core" version="[$version$]" />
    </dependencies>
  </metadata>
</package>

Is there a way to specify this in csproj with a project included via ProjectReference?

E.g. using Project.Web.csproj

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net462</TargetFramework>
    <GenerateAssemblyInfo>false</GenerateAssemblyInfo>
    <TreatWarningsAsErrors>True</TreatWarningsAsErrors>
    <DebugType>full</DebugType>
  </PropertyGroup>
  <ItemGroup>
    <ProjectReference Include="..\Project.Core\Project.Core.csproj" />
  </ItemGroup>
</Project>

when we dotnet pack Solution.sln /p:Version=1.2.3, we want the generated Project.Web.nuspec (inside Project.Web.nupkg) to have:

    <version>1.2.3</version>
    <dependencies>
      <dependency id="Project.Core" version="[1.2.3]" />
    </dependencies>

but currently it has:

    <version>1.2.3</version>
    <dependencies>
      <dependency id="Project.Core" version="1.2.3" />
    </dependencies>

[Necroskillz]

I have a very dirty workaround to achieve what I want. It involves hooking into msbuild and rewriting project.assets.json before GenerateNuspec target.

I set Directory.Build.props so all projects have this target:

  <Target Name="_SetExactVersionsOfProjects" BeforeTargets="GenerateNuspec">
    <Exec Condition="'$(IsPackable)' == 'true'" Command="gulp hack-nuget-exact-versions --silent --project $(MSBuildProjectName)" />
  </Target>

I use a command before the nuspec is generated (in my case a gulp task), to change project.assets.json with following:

• find all projects for which i want to set custom version in libraries element, and change their type from project to package
• add all of these projects to project.frameworks[<all_frameworks>].dependencies with the desired version (in my case "[<version>]" where the <version> is parsed from the previous step
• remove project.restore.frameworks[<all_frameworks>].projectReferences not sure if its necessary, but just to avoid any collisions

This is obviously not ideal. Would it be possible to have an options for this in ProjectReference? I imagine something like this (it's very flexible, so you can set the version to whatever range/version you need):

<ProjectReference Include="..\Project.Core\Project.Core.csproj" PackVersion="[$(Version)]" />

[nkolev92]

//cc
@rohit21agrawal Any ideas?

[clairernovotny]

Bump?

[rohit21agrawal]

@emgarten does the P2P ref version take a version range like [1.2.3] ? What is needed to enable that?

[clairernovotny]

@rohit21agrawal it shouldn't take a specific version on the ref, but it should have an option like ExactVersion=true or something, so that whatever the calculated/generated version that the reference is at time of build is used in the [] exact version syntax.

[emgarten]

We need a generic way to override the version range put into the nuspec for a project reference. This shouldn't be specific to exact versions.

Project to project reference versions are ignored by restore for the most part since we aren't going to fail restore if you link to an exact project path but also specified that you want a different version of it.

[Necroskillz]

Sounds like my proposal is pretty close to what you want. Would be nice to remove this workaround after half a year 👍 .

[clairernovotny]

@Necroskillz the issue is that the version needs to come from the target project, not what your project.

I.e., it's not "your" $(Version) that's needed, but the referenced project's $(Version). They may not be the same and they may be calculated. One way to get that is by using the MSBuild task on the referenced project to invoke the new "GetTargetVersion" stub that was just added in to fix calculated versions. Logic that does the calculations hooks into that and would run in that project's context. You'd then return the version you need.

[Necroskillz]

Well $(Version) can be any MSBuild variable, that you are free to calculate however you want. This was just an example that it would take the version from the command line parameter /p:Version that is passed to pack.