Home: Framework assemblies are no longer added to .nuspec when using the new .csproj project system

[kevinchalet]

_Moved from https://github.com/NuGet/Home/issues/4412#issuecomment-287148113:_

---

In the marvelous world of project.json, specifying a frameworkAssemblies node was enough to tell NuGet to add the corresponding entries in the .nuspec file:

{
  "frameworks": {
    "net451": {
      "frameworkAssemblies": {
        "System.IdentityModel": "4.0.0.0",
        "System.Xml": "4.0.0.0"
      }
    }
  }
}

<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2012/06/nuspec.xsd">
  <metadata>
    // ...
    <frameworkAssemblies>
      <frameworkAssembly assemblyName="System.IdentityModel" targetFramework=".NETFramework4.5.1" />
      <frameworkAssembly assemblyName="System.Xml" targetFramework=".NETFramework4.5.1" />
    </frameworkAssemblies>
  </metadata>
</package>

With .csproj, this is no longer true when using Reference:

<Project Sdk="Microsoft.NET.Sdk">

  <ItemGroup>
    <Reference Include="System.IdentityModel" />
    <Reference Include="System.Xml" />
  </ItemGroup>

</Project>

This breaking change has obviously important implications, as framework assemblies are no longer brought transitively, which means that the final user of the package has to reference the framework assemblies in his own app.

[rohit21agrawal]

@dsplaisted Can <Reference> in Net Core projects point to a random DLL on disk which is not a framework assembly?

[dsplaisted]

It will be able to in the 2.0 tools.

[rohit21agrawal]

@dsplaisted will there be a way to distinguish what References come from the framework and what come from a DLL on disk? Is there a design doc for this so we can adapt pack accordingly?

[dsplaisted]

Here's the PR where this was added to the SDK: https://github.com/dotnet/sdk/pull/876

It turns out we mentioned that nuget pack would need to handle this but never filed an issue.

The logic to figure out where the references actually come from is very complicated and involves the ResolveAssemblyReferences task. I doubt there is a current spec for it.

It might be OK to just see whether the ItemSpec has a .dll or .exe extension, and if so assume it's a file reference, otherwise assume it's a framework reference. Also, .NET Core and .NET Standard projects wouldn't support framework references anyway.

@rainersigwald, @nguerrera, or @eerhardt may be able to provide more feedback.

[NickCraver]

This is a pretty big blocker to find out about at the end of a port. Is there a workaround? I'm porting major libraries here (Dapper, MiniProfiler, StackExchange.Redis, etc.) and this is a big step backwards for the consumer, having to reference framework libraries manually that just worked on the old system.

From a user point of view, they're better off with me not moving to the VS 2017 project system - what can we do so this isn't the case?

[dsplaisted]

One work around would be to continue to use a nuspec, I think.

[davidfowl]

@dsplaisted that's a pretty big hammer of a workaround.

[rohit21agrawal]

A better workaround in my opinion would be to use the GenerateNuspec task to get a nuspec without the framework assemblies in your obj folder, then write a custom task that takes in this nuspec and adds the framework assemblies (can use any xml reader writer for this), and then pack the resulting nuspec.

I know its not the most convenient thing but its not terribly hard either. I can come up with a small example of how to do this if you think this might help. Let me know.

[NickCraver]

Are we expecting every library author that writes a package that supports .NET full framework (the vast majority of packages) to do this in under to use the new tooling for the next 3 minor releases? Am I the only one that sees this as a large blocker that really needs to be addressed in NuGet 4.1 (or hopefully, sooner)?

Let me be as blunt as possible: We aren't porting our projects to the new .csproj system, and this issue is why.

[rohit21agrawal]

Cc: @rrelyea for your urgent triaging attention

[NickCraver]

Is there any hope of getting this fixed soon? We're ready to merge in .csproj ports on several major NuGet packages with millions of downloads and we're blocked by only this issue. This is incredibly frustrating.

Remember to port to .csproj we had to abandon project.json all together and move our projects over. From the moment we do that, the move itself starts to decay if unmerged. We have to pause all project-related PRs and changes, or make them on both branches and merge all along the way (which users and PRs won't do). To have to hang on merging .csproj formats or indefinitely not release on NuGet are terrible options and they're costing time and frustration. I'm personally up to 6 blocked projects now, and other maintainers at Stack are hitting the same.

Please up the priority on this, it needs a fix very soon.

[rohit21agrawal]

@NickCraver to get you a workaround as fast as we can, can you help me understand how are you packing projects? msbuild or dotnet or VS?

[NickCraver]

@rohit21agrawal I have steps and an easy repro for you, an example library is MiniProfiler (current commit link). You only need to run this:

.\build.ps1 -VersionSuffix "alpha1234"

You can see everything in the simple build script, but here's the relevant bits:

dotnet msbuild "/t:Restore;Pack" "/p:Configuration=Release" "/p:VersionSuffix=$VersionSuffix" "/p:PackageOutputPath=$packageOutputFolder" "/p:CI=true"

Note that I have to currently use /t:Restore;Pack instead of dotnet restore and dotnet pack because https://github.com/NuGet/Home/issues/4337 is another bug with pre-release package references in play.

cc @onovotny who also noticed this break

[m0sa]

The packaging in this case is done by the PackTask from the Nuget.Client repo:

The build already walks all the framework targets to get it's output files per target framework. The same way it could get the required <Reference> items per target framework. But currently, even if it did that, there's no way of passing those to the PackTask, as you can see in the latest code for it on the ˙dev˙ branch , there's no way of passing frameworkAssembly references to it.

[m0sa]

I've dug around a bit more, and there is an AssemblyReference task property that gets populated from the _Reference item group, but it doesn't seem to do anything, e.g.:

I added this task to the .csproj

  <Target Name="_ReferencesTest" BeforeTargets="GenerateNuspec">
    <ItemGroup>
      <_References Include="System.Data" />
      <_References Include="System.Xml" />
    </ItemGroup>
  </Target>

Those were passed in to the PackTask:

But no changes to the nuspec. The AssemblyReferences property doesn't seem to be used anywhere yet.

[mgravell]

Context: I have changes I want to deploy in multiple fairly high usage libs: dapper, protobuf-net, stackexchange.redis, etc (including multiple MS PRs that I'm sure they'd love to see deployed). Being "bleeding edge, feel the pain", I've updated from csproj to project.json back to csproj. And the thing that makes me not want to push to nuget: this glitch, because it will actively hurt my users.

[NickCraver]

@rohit21agrawal @rrelyea Is there any update here? This is a HUGE pain for us. We'll soon have to throw away the ports of projects we've done or face severe merge headaches, and we don't know which route is worse.

We have an entire pipeline of new tooling in play that works from start to finish (even if it's a workaround in place) up until the final packaging. We can't release the libraries generated by the tooling to our users; that'd be actively harmful to the community. Why isn't this a higher priority? There's no way this can linger for months, unless we simply don't care about any library authors moving to VS 2017 until the Update 3 timeframe.

This is the worst kind of bug, one developers very likely don't even know they're causing. I highly doubt we're the only ones affected - there's just no way, and I've already heard from other authors. I think we're just some of the few who noticed.

Please, please treat this as higher priority than months away. It is so insanely frustrating to be blocked by only this issue on so many large projects. We'd take any fix here, including any incredibly hacky workaround.

[rohit21agrawal]

@NickCraver I am working on this issue, I will update this thread very soon.

[kevinchalet]

We'd take any fix here, including any incredibly hacky workaround.

Personally, I opted for the "custom .nuspec approach". It's not ideal, but it works:

• https://github.com/aspnet-contrib/AspNet.Security.OpenIdConnect.Server/blob/dev/src/Owin.Security.OpenIdConnect.Server/Owin.Security.OpenIdConnect.Server.csproj#L32-L61
• https://github.com/aspnet-contrib/AspNet.Security.OpenIdConnect.Server/blob/dev/src/Owin.Security.OpenIdConnect.Server/Owin.Security.OpenIdConnect.Server.nuspec#L24-L27

[NickCraver]

@PinpointTownes I'm torn on whether the bug or the workaround is worse. While it gets you to a buildable state, any lapse in adding or changing a dependency reference in the .nuspec (or many .nuspecs) along with any .csproj (or other .targets) changes will result in a schism between what's actually built and what's reflected NuGet. That quickly results in another set of user breaking changes.

I agree it's a workaround, my concern is not that it's "hacky", but that it's a very dangerous route, and not intuitively so for anyone making changes. What was your overall thinking with this tradeoff?

[kevinchalet]

What was your overall thinking with this tradeoff?

@NickCraver well, easy: this package must go RTM soon and introducing a dependency change like the one implied by the lack of Reference -> frameworkAssemblies transformation support in the new .csproj format was unfortunately not an option for me ; so I had to move forward and find a workaround, good or bad. I 100% agree that it sucks, but it's the only one I could come up with with my (very) limited MSBuild skills, and it's still better than breaking the users of my package :smile:

[kevinchalet]

@NickCraver the cool thing is that the NuGet team is now working on a better workaround/fix, so I hope I'll be able to get rid of this ugly hack soon.

[NickCraver]

@PinpointTownes totally understood - I appreciate the thoughts. We may have to go this same route and hope we don't break anyone with any changes, PR, etc. I hate to put this into a dozen major projects, but it so far it seems like the only option proposed...so we have to choose a roll back to project.json or the more dangerous route.

@rohit21agrawal I very much look forward to updates here, and hope we can work around it some way in the current tooling. Thanks for the update, this is incredibly frustrating, so your work is very much appreciated.

[rohit21agrawal]

Would you guys be willing to take a dependency on private bits?

[gulbanana]

In my builds, I would - i'm building packages for an internal enterprise ecosystem, so we can treat the actual library-dev process as an expert activity (and accordingly, we are already using the handwritten-nuspec workaround).

It wouldn't address the problem of OSS package authors unknowingly breaking full-framework consumers, though.

[m0sa]

Since the .nuspec file is emitted to /obj, maybe a better workaround would be to add a separate build target, depending Pack, that would do a "nuspec transform", adding the required framework references, and re-pack the package?

[NickCraver]

@rohit21agrawal I'm not against testing private bits (I'm already doing that - see the MVP threads) - but how would this work on a build server? These packages are built by Appveyor and published to MyGet in an automated way...I'm not sure how that could work and be private at the same time.

We may be able to temporarily build a release internally/locally for NuGet.org, but any automated feeds would remain broken until we could make this work on a build server. It's certainly better than nothing, though.

[m0sa]

Here's the code for the workaround I've described earlier (using Dapper's csproj as an example). It's not ideal though, since the framework assembly extraction and nuspec patching should be per target framework.

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
     <!-- ommited -->
  </PropertyGroup>
  <ItemGroup Condition=" '$(TargetFramework)' == 'net40' OR '$(TargetFramework)' == 'net45' OR '$(TargetFramework)' == 'net451' ">
    <Reference Include="System.Data">
      <NuSpecFrameworkAssembly>true</NuSpecFrameworkAssembly>
    </Reference>
    <Reference Include="System.Xml">
      <NuSpecFrameworkAssembly>true</NuSpecFrameworkAssembly>
    </Reference>
    <Reference Include="System.Xml.Linq">
      <NuSpecFrameworkAssembly>true</NuSpecFrameworkAssembly>
    </Reference>
    <Reference Include="System" />
    <Reference Include="Microsoft.CSharp" />
  </ItemGroup>
  <Target Name="_CleanNuSpec">
    <PropertyGroup>
      <_NuSpecPrefix>$(MSBuildProjectDirectory)\$(BaseIntermediateOutputPath)$(MSBuildProjectName).$(PackageVersion)</_NuSpecPrefix>
      <_NuSpec>$(_NuSpecPrefix).nuspec</_NuSpec>
      <_NuSpecPatched>$(_NuSpecPrefix).patched.nuspec</_NuSpecPatched>
    </PropertyGroup>
    <Delete Files="$(_NuSpec)" Condition="Exists('$(_NuSpec)')" />
    <Delete Files="$(_NuSpecPatched)" Condition="Exists('$(_NuSpecPatched)')" />
  </Target>
  <Target Name="_ExtractReferences">
    <ItemGroup>
      <_ExtractReferenceTarget Include="$(TargetFrameworks)" />
    </ItemGroup>
    <MSBuild Projects="$(MSBuildProjectFullPath)" Targets="ExtractReferencesPerTarget" Properties="TargetFramework=%(_ExtractReferenceTarget.Identity)">
      <Output TaskParameter="TargetOutputs" ItemName="_Reference" />
    </MSBuild>
  </Target>
  <Target Name="ExtractReferencesPerTarget" Outputs="@(_AssemblyReference)">
    <ItemGroup>
      <_AssemblyReference Include="@(Reference)" Condition="'%(Reference.NuSpecFrameworkAssembly)' == 'true'">
        <NuSpecFrameworkAssembly>$(TargetFramework)</NuSpecFrameworkAssembly>
      </_AssemblyReference>
    </ItemGroup>
  </Target>  
  <UsingTask TaskName="AddFrameworkAssemblies" TaskFactory="CodeTaskFactory" AssemblyFile="$(MSBuildToolsPath)\Microsoft.Build.Tasks.v4.0.dll" >  
    <ParameterGroup>
      <NuSpecFile ParameterType="System.String" Required="true" />
      <PatchedNuSpecFile ParameterType="System.String" Required="true" />
      <References ParameterType="Microsoft.Build.Framework.ITaskItem[]" Required="true" />
    </ParameterGroup>  
    <Task>  
      <Code Type="Fragment" Language="cs"><![CDATA[
        var content = System.IO.File.ReadAllText(NuSpecFile);

        var end = content.IndexOf("</metadata>");
        var newContent = content.Substring(0, end);
        newContent += "<frameworkAssemblies>\n";
        foreach (var r in References)
        {
          var targetFrameworksStr = r.GetMetadata("NuSpecFrameworkAssembly");
          foreach (var targetFramework in (targetFrameworksStr ?? "").Split(new char[] {',', ' ', ';'}, System.StringSplitOptions.RemoveEmptyEntries))
          {
            newContent += "    <frameworkAssembly assemblyName=\"" + r.ItemSpec + "\" targetFramework=\"" + targetFramework + "\" />\n";
          }
        }
        newContent += "  </frameworkAssemblies>\n  ";
        newContent += content.Substring(end);
        File.WriteAllText(PatchedNuSpecFile, newContent);
      ]]></Code>
    </Task>
  </UsingTask>
  <Target Name="PackWithFrameworkAssemblies" DependsOnTargets="_CleanNuSpec;_ExtractReferences;Pack" Condition="'$(IsPackable)' == 'true'">
    <Message Text="Repackaging -> '$(MSBuildProjectName)' from '$(_NuSpecPatched)'" Importance="high" Condition=" '@(_Reference)' != '' " />
    <AddFrameworkAssemblies NuSpecFile="$(_NuSpec)" PatchedNuSpecFile="$(_NuSpecPatched)" References="@(_Reference)" Condition=" '@(_Reference)' != '' " />
    <MSBuild Projects="$(MSBuildProjectFullPath)" Targets="Pack" Properties="NuspecFile=$(_NuSpecPatched)" Condition=" '@(_Reference)' != '' " />
  </Target>
  <ItemGroup Condition=" '$(TargetFramework)' == 'netstandard1.3' ">
    <!-- ommited -->
  </ItemGroup>
</Project>

[NickCraver]

@m0sa anything stopping us from putting that into a FrameworkAssembliesWorkarounds.targets so we can do a few props and an include in the .csproj? (since we'll have to mirror in many projects at the moment) I'm certainly game to try it.

[rohit21agrawal]

so here is the solution i am working on as of now:

<Reference Include="System.Xml" >
         <Pack>true</Pack>
</Reference>

The above will cause a reference to show up in nuspec as a frameworkAssemblyReference. You can put conditions for target frameworks too:

<Reference Include="System.Xml"  Condition="'$(TargetFramework)' == 'net45'>
         <Pack>true</Pack>
</Reference>

If putting Pack=true seems messy on each framework, you can make it better by using an ItemDefinitionGroup and put Pack=true as default metadata on each Reference item.

CC: @NickCraver @PinpointTownes

[kevinchalet]

@m0sa thanks for the workaround :+1:

@rohit21agrawal sounds really great, but could Pack be an attribute? Something like:

<Reference Include="System.Xml" Pack="true" />

[nguerrera]

@PinpointTownes Yes, msbuild 15 lets you write all metadata that way.

[nguerrera]

@rohit21agrawal I'm not sure if Pack=true is very-intuitive. I would prefer something more explicit like PackAsFrameworkReference=true.

I think we should update the SDK to make sure that implicit framework assembly references have the metadata by default. We can also probably auto-set it if it's explicit, but matches a well-known framework assembly name. Can you file an SDK issue for that when the corresponding nuget feature is done?

[rohit21agrawal]

@nguerrera as far as i understand, avoiding implicit framework assembly references is exactly the reason we might want to have separate metadata here. We do not want all implicit framework assembly references to show up in the output nuspec, do we?

I think Pack=true might actually be intuitive because that is the metadata we set on every other file too, but I'll let that be open for discussion. And this makes the packing metadata uniform across files and references.

[nguerrera]

Are there other cases where Pack=true implies putting a reference to another asset in the nuspec and not putting a file inside the nupkg?

[rohit21agrawal]

no, but my point is that setting Pack=true should do the appropriate thing for whatever it is being set on - which maybe packing it as a file or writing it out as a reference, as appropriate.

[m0sa]

I've updated my workaround. The issue with it is, that it uses the CodeTaskFactory which isn't supported in dotnet msbuild.

What's the ETA on an official fix here? Is it worth packing my workaround up into a nuget package with the MSBuild task in a DLL and a .targets file? Before I do that (and I hope, I won't have to do it), though, it would be nice if we can settle on the

<Reference Include="System.Xml"  Condition="'$(TargetFramework)' == 'net45'">
         <NAME_ME>true</NAME_ME>
</Reference>

NAME_ME metadata name? My vote goes to @nguerrera's PackAsFrameworkReference suggestion.

[rohit21agrawal]

@m0sa i will fix it in the dev branch within the next couple of days, however, it will be a while before it gets integrated into the official visual studio release or the dotnet cli release. there would still be ways ( might still be a bit of a hack) to pick up the bits published from our dev branch and use them in your projects. more details soon.

[rohit21agrawal]

For people willing to test private bits, I have attached a NuGet.Build.Tasks.Pack.nupkg here. In order for this to work, you need to add a package reference to the given nupkg, and call msbuild /t:pack /p:NuGetBuildTasksPackTargets="asasda" or dotnet.exe pack /p:NuGetBuildTasksPackTargets="asasda" . Passing a junk value to NuGetBuildTasksPackTargets property via command line is necessary to make this work right now.

You need to add <Pack>true</Pack> to any reference that you want to show up as frameworkAssemblyReference in output nuspec.

Link: https://1drv.ms/u/s!AqkZZxvzm4PPg90hewqVkLnVyW6gMw

CC: @NickCraver @m0sa @PinpointTownes

[m0sa]

@rohit21agrawal finally came around to taking your nupkg for a spin. The build fails with the following errors:

V:\StackExchange\Dapper\Dapper\Dapper.csproj : error MSB4057: The target "pack" does not exist in the project.
V:\StackExchange\Dapper\Dapper.EntityFramework\Dapper.EntityFramework.csproj : error MSB4057: The target "pack" does not exist in the project.
~\.nuget\packages\nuget.build.tasks.pack\4.3.0-beta1-1234\buildCrossTargeting\NuGet.Build.Tasks.Pack.targets(171,15): error MSB4064: The "TfmSpecificAssemblyReferences" parameter is not supported by the "PackTask" task. Verify the parameter exists on the task, and it is a settable public instance property. [V:\StackExchange\Dapper\Dapper.EntityFramework\Dapper.EntityFramework.StrongName.csproj]
~\.nuget\packages\nuget.build.tasks.pack\4.3.0-beta1-1234\buildCrossTargeting\NuGet.Build.Tasks.Pack.targets(140,5): error MSB4063: The "PackTask" task could not be initialized with its input parameters.  [V:\StackExchange\Dapper\Dapper.EntityFramework\Dapper.EntityFramework.StrongName.csproj]
~\.nuget\packages\nuget.build.tasks.pack\4.3.0-beta1-1234\buildCrossTargeting\NuGet.Build.Tasks.Pack.targets(171,15): error MSB4064: The "TfmSpecificAssemblyReferences" parameter is not supported by the "PackTask" task. Verify the parameter exists on the task, and it is a settable public instance property. [V:\StackExchange\Dapper\Dapper.Contrib\Dapper.Contrib.csproj]
~\.nuget\packages\nuget.build.tasks.pack\4.3.0-beta1-1234\buildCrossTargeting\NuGet.Build.Tasks.Pack.targets(140,5): error MSB4063: The "PackTask" task could not be initialized with its input parameters.  [V:\StackExchange\Dapper\Dapper.Contrib\Dapper.Contrib.csproj]
~\.nuget\packages\nuget.build.tasks.pack\4.3.0-beta1-1234\buildCrossTargeting\NuGet.Build.Tasks.Pack.targets(171,15): error MSB4064: The "TfmSpecificAssemblyReferences" parameter is not supported by the "PackTask" task. Verify the parameter exists on the task, and it is a settable public instance property. [V:\StackExchange\Dapper\Dapper.Rainbow\Dapper.Rainbow.csproj]
~\.nuget\packages\nuget.build.tasks.pack\4.3.0-beta1-1234\buildCrossTargeting\NuGet.Build.Tasks.Pack.targets(140,5): error MSB4063: The "PackTask" task could not be initialized with its input parameters.  [V:\StackExchange\Dapper\Dapper.Rainbow\Dapper.Rainbow.csproj]
~\.nuget\packages\nuget.build.tasks.pack\4.3.0-beta1-1234\buildCrossTargeting\NuGet.Build.Tasks.Pack.targets(171,15): error MSB4064: The "TfmSpecificAssemblyReferences" parameter is not supported by the "PackTask" task. Verify the parameter exists on the task, and it is a settable public instance property. [V:\StackExchange\Dapper\Dapper.SqlBuilder\Dapper.SqlBuilder.csproj]
~\.nuget\packages\nuget.build.tasks.pack\4.3.0-beta1-1234\buildCrossTargeting\NuGet.Build.Tasks.Pack.targets(140,5): error MSB4063: The "PackTask" task could not be initialized with its input parameters.  [V:\StackExchange\Dapper\Dapper.SqlBuilder\Dapper.SqlBuilder.csproj]
~\.nuget\packages\nuget.build.tasks.pack\4.3.0-beta1-1234\buildCrossTargeting\NuGet.Build.Tasks.Pack.targets(171,15): error MSB4064: The "TfmSpecificAssemblyReferences" parameter is not supported by the "PackTask" task. Verify the parameter exists on the task, and it is a settable public instance property. [V:\StackExchange\Dapper\Dapper\Dapper.StrongName.csproj]
~\.nuget\packages\nuget.build.tasks.pack\4.3.0-beta1-1234\buildCrossTargeting\NuGet.Build.Tasks.Pack.targets(140,5): error MSB4063: The "PackTask" task could not be initialized with its input parameters.  [V:\StackExchange\Dapper\Dapper\Dapper.StrongName.csproj]

You can try it out for yourself by running .\build.ps1 -SkipTests from this commit: https://github.com/StackExchange/Dapper/commit/972db0625b2a1d0912591bb5a9cf4c62c269f13c

[m0sa]

I've played around a bit more, the error above seems to happen as soon as /p:NuGetBuildTasksPackTargets="asasda" is passed to dotnet pack, regardless of @rohit21agrawal's package being added or not.

[rohit21agrawal]

Let me get back to you in a few hours to see why this is happening.

[jbogard]

I got the same as @m0sa as well.

[NickCraver]

@rohit21agrawal Any progress on this? We're still blocked on every library here :(

[gulbanana]

i've been using XmlPoke to add nodes to the generated nuspec 😰
not the most maintainable of workarounds.

[NickCraver]

What is the priority on this? Is it just extremely low? We've paused changes/fixes on ported open source projects because we can't merge in. See my comments earlier in this issue.

Is everyone just supposed to shred zip files and XML, or are we all supposed to generate our own .nuspecs again and effectively throw out the new packaging system? I'm sorry, but this is incredibly frustrating for library developers. And we're getting no responses for weeks at a time.

If this isn't a priority please, just comment and let us know this won't be fixed for some time. This uncertainty of this in itself causes pain. If it's low priority on the NuGet team for whatever reason please just tell us that, so we can throw away our VS 2017 ports and keep our projects running on VS 2015 tooling.

[rohit21agrawal]

@m0sa @jbogard did you guys restore after the adding the package reference to the private nupkg? I couldn't repro this issue on my end. I am currently building another version and upload it here in ~10 mins.

[NickCraver]

@rohit21agrawal Yep - note restore is part of the build script in our repro above. Same behavior after a manual restore.

Our repro is public, you can test the branch in Dapper here, commits are here showing the test: https://github.com/StackExchange/Dapper/commits/vs2017 - @m0sa listed the output above and I just re-confirmed it locally.

Repro:

git clone -b vs2017 https://github.com/StackExchange/Dapper.git
cd Dapper
.\build.ps1 -SkipTests

[rohit21agrawal]

can you try this nupkg : https://1drv.ms/u/s!AqkZZxvzm4PPg91FocTf74llC9Z-sA

[NickCraver]

@rohit21agrawal Is there another package in that chain, NuGet.Commands? Here's my build output with that package:

PS C:\git\Dapper> .\build.ps1 -SkipTests
Restoring...
  Restoring packages for C:\git\Dapper\Dapper.Rainbow\Dapper.Rainbow.csproj...
  Restoring packages for C:\git\Dapper\Dapper.Contrib\Dapper.Contrib.csproj...
  Restoring packages for C:\git\Dapper\Dapper.EntityFramework\Dapper.EntityFramework.StrongName.csproj...
  Installing NuGet.Build.Tasks 4.3.0-xprivate-37.
C:\Program Files\dotnet\sdk\1.0.3\NuGet.targets(97,5): error : Unable to resolve 'NuGet.Commands (>= 4.3.0-xprivate-37)' for '.NETFramework,Version=v4.5'. [C:\git\Dapper\Dapper.sln]
  Generating MSBuild file C:\git\Dapper\Dapper.EntityFramework\obj\Dapper.EntityFramework.StrongName.csproj.nuget.g.props.
  Generating MSBuild file C:\git\Dapper\Dapper.EntityFramework\obj\Dapper.EntityFramework.StrongName.csproj.nuget.g.targets.
  Writing lock file to disk. Path: C:\git\Dapper\Dapper.EntityFramework\obj\project.assets.json
  Restore failed in 844.1 ms for C:\git\Dapper\Dapper.EntityFramework\Dapper.EntityFramework.StrongName.csproj.
  Restoring packages for C:\git\Dapper\Dapper.SqlBuilder\Dapper.SqlBuilder.csproj...
  Installing Microsoft.Build.Tasks.Core 14.3.0-prerelease02.
  Installing Microsoft.Build.Utilities.Core 14.3.0-prerelease02.
  Installing Microsoft.Build.Framework 14.3.0-prerelease02.
C:\Program Files\dotnet\sdk\1.0.3\NuGet.targets(97,5): error : Unable to resolve 'NuGet.Commands (>= 4.3.0-xprivate-37)' for '.NETFramework,Version=v4.5'. [C:\git\Dapper\Dapper.sln]
C:\Program Files\dotnet\sdk\1.0.3\NuGet.targets(97,5): error : Unable to resolve 'NuGet.Commands (>= 4.3.0-xprivate-37)' for '.NETStandard,Version=v1.3'. [C:\git\Dapper\Dapper.sln]
C:\Program Files\dotnet\sdk\1.0.3\NuGet.targets(97,5): error : Unable to resolve 'NuGet.Commands (>= 4.3.0-xprivate-37)' for '.NETFramework,Version=v4.5'. [C:\git\Dapper\Dapper.sln]
C:\Program Files\dotnet\sdk\1.0.3\NuGet.targets(97,5): error : Unable to resolve 'NuGet.Commands (>= 4.3.0-xprivate-37)' for '.NETStandard,Version=v1.3'. [C:\git\Dapper\Dapper.sln]
C:\Program Files\dotnet\sdk\1.0.3\NuGet.targets(97,5): error : Unable to resolve 'NuGet.Commands (>= 4.3.0-xprivate-37)' for '.NETFramework,Version=v4.5'. [C:\git\Dapper\Dapper.sln]
C:\Program Files\dotnet\sdk\1.0.3\NuGet.targets(97,5): error : Unable to resolve 'NuGet.Commands (>= 4.3.0-xprivate-37)' for '.NETStandard,Version=v1.3'. [C:\git\Dapper\Dapper.sln]
  Generating MSBuild file C:\git\Dapper\Dapper.Rainbow\obj\Dapper.Rainbow.csproj.nuget.g.props.
  Generating MSBuild file C:\git\Dapper\Dapper.SqlBuilder\obj\Dapper.SqlBuilder.csproj.nuget.g.props.
  Generating MSBuild file C:\git\Dapper\Dapper.Rainbow\obj\Dapper.Rainbow.csproj.nuget.g.targets.
  Generating MSBuild file C:\git\Dapper\Dapper.SqlBuilder\obj\Dapper.SqlBuilder.csproj.nuget.g.targets.
  Generating MSBuild file C:\git\Dapper\Dapper.Contrib\obj\Dapper.Contrib.csproj.nuget.g.props.
  Writing lock file to disk. Path: C:\git\Dapper\Dapper.SqlBuilder\obj\project.assets.json
  Generating MSBuild file C:\git\Dapper\Dapper.Contrib\obj\Dapper.Contrib.csproj.nuget.g.targets.
  Writing lock file to disk. Path: C:\git\Dapper\Dapper.Contrib\obj\project.assets.json
  Restore failed in 1.4 sec for C:\git\Dapper\Dapper.SqlBuilder\Dapper.SqlBuilder.csproj.
  Writing lock file to disk. Path: C:\git\Dapper\Dapper.Rainbow\obj\project.assets.json
  Restoring packages for C:\git\Dapper\Dapper.Tests.Contrib\Dapper.Tests.Contrib.csproj...
  Restore failed in 2.3 sec for C:\git\Dapper\Dapper.Contrib\Dapper.Contrib.csproj.
  Restore failed in 2.28 sec for C:\git\Dapper\Dapper.Rainbow\Dapper.Rainbow.csproj.
  Restoring packages for C:\git\Dapper\Dapper.Tests.Performance\Dapper.Tests.Performance.csproj...
  Restoring packages for C:\git\Dapper\Dapper.Tests\Dapper.Tests.csproj...
C:\Program Files\dotnet\sdk\1.0.3\NuGet.targets(97,5): error : Unable to resolve 'NuGet.Commands (>= 4.3.0-xprivate-37)' for '.NETFramework,Version=v4.6.2'. [C:\git\Dapper\Dapper.sln]
C:\Program Files\dotnet\sdk\1.0.3\NuGet.targets(97,5): error : Unable to resolve 'NuGet.Commands (>= 4.3.0-xprivate-37)' for '.NETFramework,Version=v4.6.2 (win7-x86)'. [C:\git\Dapper\Dapper.sln]
  Generating MSBuild file C:\git\Dapper\Dapper.Tests.Performance\obj\Dapper.Tests.Performance.csproj.nuget.g.props.
  Generating MSBuild file C:\git\Dapper\Dapper.Tests.Performance\obj\Dapper.Tests.Performance.csproj.nuget.g.targets.
  Writing lock file to disk. Path: C:\git\Dapper\Dapper.Tests.Performance\obj\project.assets.json
  Restore failed in 456.75 ms for C:\git\Dapper\Dapper.Tests.Performance\Dapper.Tests.Performance.csproj.
  Restoring packages for C:\git\Dapper\Dapper\Dapper.StrongName.csproj...
C:\Program Files\dotnet\sdk\1.0.3\NuGet.targets(97,5): error : Unable to resolve 'NuGet.Commands (>= 4.3.0-xprivate-37)' for '.NETFramework,Version=v4.5'. [C:\git\Dapper\Dapper.sln]
C:\Program Files\dotnet\sdk\1.0.3\NuGet.targets(97,5): error : Unable to resolve 'NuGet.Commands (>= 4.3.0-xprivate-37)' for '.NETFramework,Version=v4.5.1'. [C:\git\Dapper\Dapper.sln]
C:\Program Files\dotnet\sdk\1.0.3\NuGet.targets(97,5): error : Unable to resolve 'NuGet.Commands (>= 4.3.0-xprivate-37)' for '.NETStandard,Version=v1.3'. [C:\git\Dapper\Dapper.sln]
C:\Program Files\dotnet\sdk\1.0.3\NuGet.targets(97,5): error : Unable to resolve 'NuGet.Commands (>= 4.3.0-xprivate-37)' for '.NETCoreApp,Version=v1.0'. [C:\git\Dapper\Dapper.sln]
C:\Program Files\dotnet\sdk\1.0.3\NuGet.targets(97,5): error : Unable to resolve 'NuGet.Commands (>= 4.3.0-xprivate-37)' for '.NETFramework,Version=v4.5.2'. [C:\git\Dapper\Dapper.sln]
C:\Program Files\dotnet\sdk\1.0.3\NuGet.targets(97,5): error : Unable to resolve 'NuGet.Commands (>= 4.3.0-xprivate-37)' for '.NETCoreApp,Version=v1.0'. [C:\git\Dapper\Dapper.sln]
  Generating MSBuild file C:\git\Dapper\Dapper\obj\Dapper.StrongName.csproj.nuget.g.props.
  Generating MSBuild file C:\git\Dapper\Dapper\obj\Dapper.StrongName.csproj.nuget.g.targets.
  Writing lock file to disk. Path: C:\git\Dapper\Dapper\obj\project.assets.json
  Restore failed in 455.33 ms for C:\git\Dapper\Dapper\Dapper.StrongName.csproj.
  Restoring packages for C:\git\Dapper\NuGet.FrameworkAssemblyPacker\NuGet.FrameworkAssemblyPacker.csproj...
C:\Program Files\dotnet\sdk\1.0.3\NuGet.targets(97,5): error : Unable to resolve 'NuGet.Commands (>= 4.3.0-xprivate-37)' for '.NETStandard,Version=v1.3'. [C:\git\Dapper\Dapper.sln]
  Generating MSBuild file C:\git\Dapper\NuGet.FrameworkAssemblyPacker\obj\NuGet.FrameworkAssemblyPacker.csproj.nuget.g.props.
  Generating MSBuild file C:\git\Dapper\NuGet.FrameworkAssemblyPacker\obj\NuGet.FrameworkAssemblyPacker.csproj.nuget.g.targets.
  Writing lock file to disk. Path: C:\git\Dapper\NuGet.FrameworkAssemblyPacker\obj\project.assets.json
  Restore failed in 255.81 ms for C:\git\Dapper\NuGet.FrameworkAssemblyPacker\NuGet.FrameworkAssemblyPacker.csproj.
  Restoring packages for C:\git\Dapper\Dapper.Tests.Contrib\Dapper.Tests.Contrib.csproj...
  Generating MSBuild file C:\git\Dapper\Dapper.Tests.Contrib\obj\Dapper.Tests.Contrib.csproj.nuget.g.props.
  Generating MSBuild file C:\git\Dapper\Dapper.Tests.Contrib\obj\Dapper.Tests.Contrib.csproj.nuget.g.targets.
  Writing lock file to disk. Path: C:\git\Dapper\Dapper.Tests.Contrib\obj\project.assets.json
  Restore failed in 1.59 sec for C:\git\Dapper\Dapper.Tests.Contrib\Dapper.Tests.Contrib.csproj.
  Restoring packages for C:\git\Dapper\Dapper.Rainbow\Dapper.Rainbow.csproj...
  Generating MSBuild file C:\git\Dapper\Dapper.Tests\obj\Dapper.Tests.csproj.nuget.g.props.
  Generating MSBuild file C:\git\Dapper\Dapper.Tests\obj\Dapper.Tests.csproj.nuget.g.targets.
  Writing lock file to disk. Path: C:\git\Dapper\Dapper.Tests\obj\project.assets.json
  Restore failed in 1.6 sec for C:\git\Dapper\Dapper.Tests\Dapper.Tests.csproj.
  Restore completed in 1.03 sec for C:\git\Dapper\Dapper.Tests.Contrib\Dapper.Tests.Contrib.csproj.
  Restore completed in 843.64 ms for C:\git\Dapper\Dapper.Rainbow\Dapper.Rainbow.csproj.

  Errors in C:\git\Dapper\Dapper.EntityFramework\Dapper.EntityFramework.StrongName.csproj
      Unable to resolve 'NuGet.Commands (>= 4.3.0-xprivate-37)' for '.NETFramework,Version=v4.5'.

  Errors in C:\git\Dapper\Dapper.SqlBuilder\Dapper.SqlBuilder.csproj
      Unable to resolve 'NuGet.Commands (>= 4.3.0-xprivate-37)' for '.NETFramework,Version=v4.5'.
      Unable to resolve 'NuGet.Commands (>= 4.3.0-xprivate-37)' for '.NETStandard,Version=v1.3'.

  Errors in C:\git\Dapper\Dapper.Contrib\Dapper.Contrib.csproj
      Unable to resolve 'NuGet.Commands (>= 4.3.0-xprivate-37)' for '.NETFramework,Version=v4.5'.
      Unable to resolve 'NuGet.Commands (>= 4.3.0-xprivate-37)' for '.NETStandard,Version=v1.3'.

  Errors in C:\git\Dapper\Dapper.Rainbow\Dapper.Rainbow.csproj
      Unable to resolve 'NuGet.Commands (>= 4.3.0-xprivate-37)' for '.NETFramework,Version=v4.5'.
      Unable to resolve 'NuGet.Commands (>= 4.3.0-xprivate-37)' for '.NETStandard,Version=v1.3'.

  Errors in C:\git\Dapper\Dapper.Tests.Performance\Dapper.Tests.Performance.csproj
      Unable to resolve 'NuGet.Commands (>= 4.3.0-xprivate-37)' for '.NETFramework,Version=v4.6.2'.
      Unable to resolve 'NuGet.Commands (>= 4.3.0-xprivate-37)' for '.NETFramework,Version=v4.6.2 (win7-x86)'.

  Errors in C:\git\Dapper\Dapper\Dapper.StrongName.csproj
      Unable to resolve 'NuGet.Commands (>= 4.3.0-xprivate-37)' for '.NETFramework,Version=v4.5'.
      Unable to resolve 'NuGet.Commands (>= 4.3.0-xprivate-37)' for '.NETFramework,Version=v4.5.1'.
      Unable to resolve 'NuGet.Commands (>= 4.3.0-xprivate-37)' for '.NETStandard,Version=v1.3'.

  Errors in C:\git\Dapper\NuGet.FrameworkAssemblyPacker\NuGet.FrameworkAssemblyPacker.csproj
      Unable to resolve 'NuGet.Commands (>= 4.3.0-xprivate-37)' for '.NETStandard,Version=v1.3'.

  Errors in C:\git\Dapper\Dapper.Tests.Contrib\Dapper.Tests.Contrib.csproj
      Unable to resolve 'NuGet.Commands (>= 4.3.0-xprivate-37)' for '.NETCoreApp,Version=v1.0'.

  Errors in C:\git\Dapper\Dapper.Tests\Dapper.Tests.csproj
      Unable to resolve 'NuGet.Commands (>= 4.3.0-xprivate-37)' for '.NETFramework,Version=v4.5.2'.
      Unable to resolve 'NuGet.Commands (>= 4.3.0-xprivate-37)' for '.NETCoreApp,Version=v1.0'.

  NuGet Config files used:
      C:\git\Dapper\NuGet.Config
      C:\Users\ncraver.STACKEXCHANGE\AppData\Roaming\NuGet\NuGet.Config
      C:\Program Files (x86)\NuGet\Config\Microsoft.VisualStudio.Offline.config

  Feeds used:
      C:\git\Dapper\Nugets
      https://www.nuget.org/api/v2/
      C:\NuGet
      C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\

  Installed:
      1 package(s) to C:\git\Dapper\Dapper.EntityFramework\Dapper.EntityFramework.StrongName.csproj
      4 package(s) to C:\git\Dapper\Dapper.SqlBuilder\Dapper.SqlBuilder.csproj
      4 package(s) to C:\git\Dapper\Dapper.Contrib\Dapper.Contrib.csproj
      4 package(s) to C:\git\Dapper\Dapper.Rainbow\Dapper.Rainbow.csproj
      1 package(s) to C:\git\Dapper\Dapper.Tests.Performance\Dapper.Tests.Performance.csproj
      4 package(s) to C:\git\Dapper\Dapper\Dapper.StrongName.csproj
      3 package(s) to C:\git\Dapper\NuGet.FrameworkAssemblyPacker\NuGet.FrameworkAssemblyPacker.csproj
      4 package(s) to C:\git\Dapper\Dapper.Tests.Contrib\Dapper.Tests.Contrib.csproj
      4 package(s) to C:\git\Dapper\Dapper.Tests\Dapper.Tests.csproj
restore failed with exit code 1
At C:\git\Dapper\build.ps1:13 char:5
+     throw "restore failed with exit code $LASTEXITCODE"
+     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (restore failed with exit code 1:String) [], RuntimeException
    + FullyQualifiedErrorId : restore failed with exit code 1

[rohit21agrawal]

@NickCraver have uploaded the full closure as a zip here : https://1drv.ms/u/s!AqkZZxvzm4PPg91G_ndQi1koKpzMLg

[NickCraver]

Here's output with all those packages (note it doesn't support net40):

PS C:\git\Dapper> .\build.ps1 -SkipTests
Restoring...
  Restoring packages for C:\git\Dapper\Dapper.Rainbow\Dapper.Rainbow.csproj...
  Restoring packages for C:\git\Dapper\Dapper.EntityFramework\Dapper.EntityFramework.StrongName.csproj...
  Restoring packages for C:\git\Dapper\Dapper.Contrib\Dapper.Contrib.csproj...
  Installing NuGet.Packaging.Core 4.3.0-xprivate-37.
  Installing NuGet.Packaging 4.3.0-xprivate-37.
  Installing NuGet.Versioning 4.3.0-xprivate-37.
  Installing NuGet.Protocol 4.3.0-xprivate-37.
  Installing NuGet.Frameworks 4.3.0-xprivate-37.
  Installing NuGet.LibraryModel 4.3.0-xprivate-37.
  Installing NuGet.Common 4.3.0-xprivate-37.
  Installing NuGet.DependencyResolver.Core 4.3.0-xprivate-37.
  Installing NuGet.Configuration 4.3.0-xprivate-37.
  Installing NuGet.ProjectModel 4.3.0-xprivate-37.
  Installing NuGet.Commands 4.3.0-xprivate-37.
C:\Program Files\dotnet\sdk\1.0.3\NuGet.targets(97,5): error : Package NuGet.Build.Tasks 4.3.0-xprivate-37 is not compatible with net40 (.NETFramework,Version=v4.0). Package NuGet.Build.Tasks 4.3.0-xprivate-37 supports:\r [C:\git\Dapper\Dapper.sln]
C:\Program Files\dotnet\sdk\1.0.3\NuGet.targets(97,5): error :   - net45 (.NETFramework,Version=v4.5)\r [C:\git\Dapper\Dapper.sln]
C:\Program Files\dotnet\sdk\1.0.3\NuGet.targets(97,5): error :   - netstandard1.3 (.NETStandard,Version=v1.3) [C:\git\Dapper\Dapper.sln]
C:\Program Files\dotnet\sdk\1.0.3\NuGet.targets(97,5): error : One or more packages are incompatible with .NETFramework,Version=v4.0. [C:\git\Dapper\Dapper.sln]
  Writing lock file to disk. Path: C:\git\Dapper\Dapper.EntityFramework\obj\project.assets.json
  Restore failed in 909.45 ms for C:\git\Dapper\Dapper.EntityFramework\Dapper.EntityFramework.StrongName.csproj.
  Restoring packages for C:\git\Dapper\Dapper.SqlBuilder\Dapper.SqlBuilder.csproj...
  Installing System.Security.Cryptography.ProtectedData 4.0.0.
C:\Program Files\dotnet\sdk\1.0.3\NuGet.targets(97,5): error : Package NuGet.Build.Tasks 4.3.0-xprivate-37 is not compatible with net40 (.NETFramework,Version=v4.0). Package NuGet.Build.Tasks 4.3.0-xprivate-37 supports:\r [C:\git\Dapper\Dapper.sln]
C:\Program Files\dotnet\sdk\1.0.3\NuGet.targets(97,5): error :   - net45 (.NETFramework,Version=v4.5)\r [C:\git\Dapper\Dapper.sln]
C:\Program Files\dotnet\sdk\1.0.3\NuGet.targets(97,5): error :   - netstandard1.3 (.NETStandard,Version=v1.3) [C:\git\Dapper\Dapper.sln]
C:\Program Files\dotnet\sdk\1.0.3\NuGet.targets(97,5): error : One or more packages are incompatible with .NETFramework,Version=v4.0. [C:\git\Dapper\Dapper.sln]
C:\Program Files\dotnet\sdk\1.0.3\NuGet.targets(97,5): error : Package NuGet.Build.Tasks 4.3.0-xprivate-37 is not compatible with net40 (.NETFramework,Version=v4.0). Package NuGet.Build.Tasks 4.3.0-xprivate-37 supports:\r [C:\git\Dapper\Dapper.sln]
C:\Program Files\dotnet\sdk\1.0.3\NuGet.targets(97,5): error :   - net45 (.NETFramework,Version=v4.5)\r [C:\git\Dapper\Dapper.sln]
C:\Program Files\dotnet\sdk\1.0.3\NuGet.targets(97,5): error :   - netstandard1.3 (.NETStandard,Version=v1.3) [C:\git\Dapper\Dapper.sln]
C:\Program Files\dotnet\sdk\1.0.3\NuGet.targets(97,5): error : One or more packages are incompatible with .NETFramework,Version=v4.0. [C:\git\Dapper\Dapper.sln]
C:\Program Files\dotnet\sdk\1.0.3\NuGet.targets(97,5): error : Package NuGet.Build.Tasks 4.3.0-xprivate-37 is not compatible with net40 (.NETFramework,Version=v4.0). Package NuGet.Build.Tasks 4.3.0-xprivate-37 supports:\r [C:\git\Dapper\Dapper.sln]
C:\Program Files\dotnet\sdk\1.0.3\NuGet.targets(97,5): error :   - net45 (.NETFramework,Version=v4.5)\r [C:\git\Dapper\Dapper.sln]
C:\Program Files\dotnet\sdk\1.0.3\NuGet.targets(97,5): error :   - netstandard1.3 (.NETStandard,Version=v1.3) [C:\git\Dapper\Dapper.sln]
C:\Program Files\dotnet\sdk\1.0.3\NuGet.targets(97,5): error : One or more packages are incompatible with .NETFramework,Version=v4.0. [C:\git\Dapper\Dapper.sln]
  Writing lock file to disk. Path: C:\git\Dapper\Dapper.Rainbow\obj\project.assets.json
  Writing lock file to disk. Path: C:\git\Dapper\Dapper.SqlBuilder\obj\project.assets.json
  Writing lock file to disk. Path: C:\git\Dapper\Dapper.Contrib\obj\project.assets.json
  Restore failed in 1.84 sec for C:\git\Dapper\Dapper.Rainbow\Dapper.Rainbow.csproj.
  Restore failed in 894.22 ms for C:\git\Dapper\Dapper.SqlBuilder\Dapper.SqlBuilder.csproj.
  Restore failed in 1.85 sec for C:\git\Dapper\Dapper.Contrib\Dapper.Contrib.csproj.
  Restoring packages for C:\git\Dapper\Dapper.Tests.Contrib\Dapper.Tests.Contrib.csproj...
  Restoring packages for C:\git\Dapper\Dapper.Tests\Dapper.Tests.csproj...
  Restoring packages for C:\git\Dapper\Dapper.Tests.Performance\Dapper.Tests.Performance.csproj...
  Generating MSBuild file C:\git\Dapper\Dapper.Tests.Performance\obj\Dapper.Tests.Performance.csproj.nuget.g.props.
  Writing lock file to disk. Path: C:\git\Dapper\Dapper.Tests.Performance\obj\project.assets.json
  Restore completed in 235.56 ms for C:\git\Dapper\Dapper.Tests.Performance\Dapper.Tests.Performance.csproj.
  Restoring packages for C:\git\Dapper\Dapper\Dapper.StrongName.csproj...
C:\Program Files\dotnet\sdk\1.0.3\NuGet.targets(97,5): error : Package NuGet.Build.Tasks 4.3.0-xprivate-37 is not compatible with net40 (.NETFramework,Version=v4.0). Package NuGet.Build.Tasks 4.3.0-xprivate-37 supports:\r [C:\git\Dapper\Dapper.sln]
C:\Program Files\dotnet\sdk\1.0.3\NuGet.targets(97,5): error :   - net45 (.NETFramework,Version=v4.5)\r [C:\git\Dapper\Dapper.sln]
C:\Program Files\dotnet\sdk\1.0.3\NuGet.targets(97,5): error :   - netstandard1.3 (.NETStandard,Version=v1.3) [C:\git\Dapper\Dapper.sln]
C:\Program Files\dotnet\sdk\1.0.3\NuGet.targets(97,5): error : One or more packages are incompatible with .NETFramework,Version=v4.0. [C:\git\Dapper\Dapper.sln]
  Writing lock file to disk. Path: C:\git\Dapper\Dapper\obj\project.assets.json
  Restore failed in 378.22 ms for C:\git\Dapper\Dapper\Dapper.StrongName.csproj.
  Restoring packages for C:\git\Dapper\NuGet.FrameworkAssemblyPacker\NuGet.FrameworkAssemblyPacker.csproj...
  Generating MSBuild file C:\git\Dapper\NuGet.FrameworkAssemblyPacker\obj\NuGet.FrameworkAssemblyPacker.csproj.nuget.g.props.
  Writing lock file to disk. Path: C:\git\Dapper\NuGet.FrameworkAssemblyPacker\obj\project.assets.json
  Restore completed in 219.81 ms for C:\git\Dapper\NuGet.FrameworkAssemblyPacker\NuGet.FrameworkAssemblyPacker.csproj.
  Restoring packages for C:\git\Dapper\Dapper.Tests.Contrib\Dapper.Tests.Contrib.csproj...
  Generating MSBuild file C:\git\Dapper\Dapper.Tests.Contrib\obj\Dapper.Tests.Contrib.csproj.nuget.g.props.
  Writing lock file to disk. Path: C:\git\Dapper\Dapper.Tests.Contrib\obj\project.assets.json
  Restore completed in 991.34 ms for C:\git\Dapper\Dapper.Tests.Contrib\Dapper.Tests.Contrib.csproj.
  Restoring packages for C:\git\Dapper\Dapper.EntityFramework\Dapper.EntityFramework.StrongName.csproj...
  Generating MSBuild file C:\git\Dapper\Dapper.Tests\obj\Dapper.Tests.csproj.nuget.g.props.
  Writing lock file to disk. Path: C:\git\Dapper\Dapper.Tests\obj\project.assets.json
  Restore completed in 994.85 ms for C:\git\Dapper\Dapper.Tests\Dapper.Tests.csproj.
  Restore completed in 830.46 ms for C:\git\Dapper\Dapper.Tests.Contrib\Dapper.Tests.Contrib.csproj.
  Restore completed in 795.92 ms for C:\git\Dapper\Dapper.EntityFramework\Dapper.EntityFramework.StrongName.csproj.

  Errors in C:\git\Dapper\Dapper.EntityFramework\Dapper.EntityFramework.StrongName.csproj
      Package NuGet.Build.Tasks 4.3.0-xprivate-37 is not compatible with net40 (.NETFramework,Version=v4.0). Package NuGet.Build.Tasks 4.3.0-xprivate-37 supports:
        - net45 (.NETFramework,Version=v4.5)
        - netstandard1.3 (.NETStandard,Version=v1.3)
      One or more packages are incompatible with .NETFramework,Version=v4.0.

  Errors in C:\git\Dapper\Dapper.Rainbow\Dapper.Rainbow.csproj
      Package NuGet.Build.Tasks 4.3.0-xprivate-37 is not compatible with net40 (.NETFramework,Version=v4.0). Package NuGet.Build.Tasks 4.3.0-xprivate-37 supports:
        - net45 (.NETFramework,Version=v4.5)
        - netstandard1.3 (.NETStandard,Version=v1.3)
      One or more packages are incompatible with .NETFramework,Version=v4.0.

  Errors in C:\git\Dapper\Dapper.Contrib\Dapper.Contrib.csproj
      Package NuGet.Build.Tasks 4.3.0-xprivate-37 is not compatible with net40 (.NETFramework,Version=v4.0). Package NuGet.Build.Tasks 4.3.0-xprivate-37 supports:
        - net45 (.NETFramework,Version=v4.5)
        - netstandard1.3 (.NETStandard,Version=v1.3)
      One or more packages are incompatible with .NETFramework,Version=v4.0.

  Errors in C:\git\Dapper\Dapper.SqlBuilder\Dapper.SqlBuilder.csproj
      Package NuGet.Build.Tasks 4.3.0-xprivate-37 is not compatible with net40 (.NETFramework,Version=v4.0). Package NuGet.Build.Tasks 4.3.0-xprivate-37 supports:
        - net45 (.NETFramework,Version=v4.5)
        - netstandard1.3 (.NETStandard,Version=v1.3)
      One or more packages are incompatible with .NETFramework,Version=v4.0.

  Errors in C:\git\Dapper\Dapper\Dapper.StrongName.csproj
      Package NuGet.Build.Tasks 4.3.0-xprivate-37 is not compatible with net40 (.NETFramework,Version=v4.0). Package NuGet.Build.Tasks 4.3.0-xprivate-37 supports:
        - net45 (.NETFramework,Version=v4.5)
        - netstandard1.3 (.NETStandard,Version=v1.3)
      One or more packages are incompatible with .NETFramework,Version=v4.0.

  NuGet Config files used:
      C:\git\Dapper\NuGet.Config
      C:\Users\ncraver.STACKEXCHANGE\AppData\Roaming\NuGet\NuGet.Config
      C:\Program Files (x86)\NuGet\Config\Microsoft.VisualStudio.Offline.config

  Feeds used:
      C:\git\Dapper\Nugets
      https://www.nuget.org/api/v2/
      C:\NuGet
      C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\

  Installed:
      11 package(s) to C:\git\Dapper\Dapper.EntityFramework\Dapper.EntityFramework.StrongName.csproj
      12 package(s) to C:\git\Dapper\Dapper.Rainbow\Dapper.Rainbow.csproj
      12 package(s) to C:\git\Dapper\Dapper.Contrib\Dapper.Contrib.csproj
      12 package(s) to C:\git\Dapper\Dapper.SqlBuilder\Dapper.SqlBuilder.csproj
      11 package(s) to C:\git\Dapper\Dapper.Tests.Performance\Dapper.Tests.Performance.csproj
      12 package(s) to C:\git\Dapper\Dapper\Dapper.StrongName.csproj
      12 package(s) to C:\git\Dapper\NuGet.FrameworkAssemblyPacker\NuGet.FrameworkAssemblyPacker.csproj
      12 package(s) to C:\git\Dapper\Dapper.Tests.Contrib\Dapper.Tests.Contrib.csproj
      12 package(s) to C:\git\Dapper\Dapper.Tests\Dapper.Tests.csproj
restore failed with exit code 1
At C:\git\Dapper\build.ps1:13 char:5
+     throw "restore failed with exit code $LASTEXITCODE"
+     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (restore failed with exit code 1:String) [], RuntimeException
    + FullyQualifiedErrorId : restore failed with exit code 1

...and here's removing our net40 targets for the sake of testing:

PS C:\git\Dapper> .\build.ps1 -SkipTests
Restoring...
  Restoring packages for C:\git\Dapper\Dapper.EntityFramework\Dapper.EntityFramework.StrongName.csproj...
  Restoring packages for C:\git\Dapper\Dapper.Rainbow\Dapper.Rainbow.csproj...
  Restoring packages for C:\git\Dapper\Dapper.Contrib\Dapper.Contrib.csproj...
  Lock file has not changed. Skipping lock file write. Path: C:\git\Dapper\Dapper.EntityFramework\obj\project.assets.json
  Restore completed in 191.51 ms for C:\git\Dapper\Dapper.EntityFramework\Dapper.EntityFramework.StrongName.csproj.
  Restoring packages for C:\git\Dapper\Dapper.SqlBuilder\Dapper.SqlBuilder.csproj...
  Lock file has not changed. Skipping lock file write. Path: C:\git\Dapper\Dapper.Contrib\obj\project.assets.json
  Restore completed in 553.22 ms for C:\git\Dapper\Dapper.Contrib\Dapper.Contrib.csproj.
  Lock file has not changed. Skipping lock file write. Path: C:\git\Dapper\Dapper.SqlBuilder\obj\project.assets.json
  Restore completed in 337.92 ms for C:\git\Dapper\Dapper.SqlBuilder\Dapper.SqlBuilder.csproj.
  Restoring packages for C:\git\Dapper\Dapper.Tests.Performance\Dapper.Tests.Performance.csproj...
  Lock file has not changed. Skipping lock file write. Path: C:\git\Dapper\Dapper.Rainbow\obj\project.assets.json
  Restore completed in 569.59 ms for C:\git\Dapper\Dapper.Rainbow\Dapper.Rainbow.csproj.
  Restoring packages for C:\git\Dapper\Dapper.Tests.Contrib\Dapper.Tests.Contrib.csproj...
  Restoring packages for C:\git\Dapper\Dapper.Tests\Dapper.Tests.csproj...
  Lock file has not changed. Skipping lock file write. Path: C:\git\Dapper\Dapper.Tests.Performance\obj\project.assets.json
  Restore completed in 207.76 ms for C:\git\Dapper\Dapper.Tests.Performance\Dapper.Tests.Performance.csproj.
  Restoring packages for C:\git\Dapper\Dapper\Dapper.StrongName.csproj...
  Lock file has not changed. Skipping lock file write. Path: C:\git\Dapper\Dapper\obj\project.assets.json
  Restore completed in 354.56 ms for C:\git\Dapper\Dapper\Dapper.StrongName.csproj.
  Restoring packages for C:\git\Dapper\NuGet.FrameworkAssemblyPacker\NuGet.FrameworkAssemblyPacker.csproj...
  Lock file has not changed. Skipping lock file write. Path: C:\git\Dapper\NuGet.FrameworkAssemblyPacker\obj\project.assets.json
  Restore completed in 207.01 ms for C:\git\Dapper\NuGet.FrameworkAssemblyPacker\NuGet.FrameworkAssemblyPacker.csproj.
  Restoring packages for C:\git\Dapper\Dapper\Dapper.StrongName.csproj...
  Lock file has not changed. Skipping lock file write. Path: C:\git\Dapper\Dapper.Tests.Contrib\obj\project.assets.json
  Restore completed in 992.63 ms for C:\git\Dapper\Dapper.Tests.Contrib\Dapper.Tests.Contrib.csproj.
  Restoring packages for C:\git\Dapper\Dapper.Rainbow\Dapper.Rainbow.csproj...
  Lock file has not changed. Skipping lock file write. Path: C:\git\Dapper\Dapper.Tests\obj\project.assets.json
  Restore completed in 1 sec for C:\git\Dapper\Dapper.Tests\Dapper.Tests.csproj.
  Restore completed in 757.63 ms for C:\git\Dapper\Dapper\Dapper.StrongName.csproj.
  Restore completed in 741.95 ms for C:\git\Dapper\Dapper.Rainbow\Dapper.Rainbow.csproj.

  NuGet Config files used:
      C:\git\Dapper\NuGet.Config
      C:\Users\ncraver.STACKEXCHANGE\AppData\Roaming\NuGet\NuGet.Config
      C:\Program Files (x86)\NuGet\Config\Microsoft.VisualStudio.Offline.config

  Feeds used:
      C:\git\Dapper\Nugets
      https://www.nuget.org/api/v2/
      C:\NuGet
      C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\
Microsoft (R) Build Engine version 15.1.1012.6693
Copyright (C) Microsoft Corporation. All rights reserved.

  Dapper -> C:\git\Dapper\Dapper\bin\Release\net45\Dapper.dll
  Dapper.StrongName -> C:\git\Dapper\Dapper\bin\Release\net45\Dapper.StrongName.dll
  Dapper -> C:\git\Dapper\Dapper\bin\Release\net451\Dapper.dll
  Dapper.StrongName -> C:\git\Dapper\Dapper\bin\Release\net451\Dapper.StrongName.dll
C:\Program Files\dotnet\sdk\1.0.3\Microsoft.Common.CurrentVersion.targets(1964,5): warning MSB3277: Found conflicts between different versions of the same dependent assembly that could not be resolved.  These reference conflicts are listed in the build log when log verbosity is set to detailed. [C:\git\Dapper\Dapper\Dapper.csproj]
  Dapper -> C:\git\Dapper\Dapper\bin\Release\netstandard1.3\Dapper.dll
  Dapper.SqlBuilder -> C:\git\Dapper\Dapper.SqlBuilder\bin\Release\net45\Dapper.SqlBuilder.dll
C:\Program Files\dotnet\sdk\1.0.3\Microsoft.Common.CurrentVersion.targets(1964,5): warning MSB3277: Found conflicts between different versions of the same dependent assembly that could not be resolved.  These reference conflicts are listed in the build log when log verbosity is set to detailed. [C:\git\Dapper\Dapper\Dapper.StrongName.csproj]
C:\Program Files\dotnet\sdk\1.0.3\Microsoft.Common.CurrentVersion.targets(1964,5): warning MSB3277: Found conflicts between different versions of the same dependent assembly that could not be resolved.  These reference conflicts are listed in the build log when log verbosity is set to detailed. [C:\git\Dapper\Dapper.SqlBuilder\Dapper.SqlBuilder.csproj]
  Dapper.SqlBuilder -> C:\git\Dapper\Dapper.SqlBuilder\bin\Release\netstandard1.3\Dapper.SqlBuilder.dll
  Dapper.Rainbow -> C:\git\Dapper\Dapper.Rainbow\bin\Release\net45\Dapper.Rainbow.dll
  Dapper.EntityFramework -> C:\git\Dapper\Dapper.EntityFramework\bin\Release\net45\Dapper.EntityFramework.dll
C:\Program Files\dotnet\sdk\1.0.3\Microsoft.Common.CurrentVersion.targets(1964,5): warning MSB3277: Found conflicts between different versions of the same dependent assembly that could not be resolved.  These reference conflicts are listed in the build log when log verbosity is set to detailed. [C:\git\Dapper\Dapper.Rainbow\Dapper.Rainbow.csproj]
  Dapper.Rainbow -> C:\git\Dapper\Dapper.Rainbow\bin\Release\netstandard1.3\Dapper.Rainbow.dll
  Dapper.Contrib -> C:\git\Dapper\Dapper.Contrib\bin\Release\net45\Dapper.Contrib.dll
C:\Program Files\dotnet\sdk\1.0.3\Microsoft.Common.CurrentVersion.targets(1964,5): warning MSB3277: Found conflicts between different versions of the same dependent assembly that could not be resolved.  These reference conflicts are listed in the build log when log verbosity is set to detailed. [C:\git\Dapper\Dapper.Contrib\Dapper.Contrib.csproj]
  Dapper.Contrib -> C:\git\Dapper\Dapper.Contrib\bin\Release\netstandard1.3\Dapper.Contrib.dll
  NuGet.FrameworkAssemblyPacker -> C:\git\Dapper\NuGet.FrameworkAssemblyPacker\bin\Release\netstandard1.3\NuGet.FrameworkAssemblyPacker.dll
  Dapper.StrongName -> C:\git\Dapper\Dapper\bin\Release\netstandard1.3\Dapper.StrongName.dll
  Dapper.EntityFramework.StrongName -> C:\git\Dapper\Dapper.EntityFramework\bin\Release\net45\Dapper.EntityFramework.StrongName.dll
  Dapper.Tests.Contrib -> C:\git\Dapper\Dapper.Tests.Contrib\bin\Release\netcoreapp1.0\Dapper.Tests.Contrib.dll
  Dapper.Tests -> C:\git\Dapper\Dapper.Tests\bin\Release\net452\Dapper.Tests.dll
  Dapper.Tests -> C:\git\Dapper\Dapper.Tests\bin\Release\netcoreapp1.0\Dapper.Tests.dll
  Dapper.Tests.Performance -> C:\git\Dapper\Dapper.Tests.Performance\bin\Release\net462\Dapper.Tests.Performance.exe

Build succeeded.

C:\Program Files\dotnet\sdk\1.0.3\Microsoft.Common.CurrentVersion.targets(1964,5): warning MSB3277: Found conflicts between different versions of the same dependent assembly that could not be resolved.  These reference conflicts are listed in the build log when log verbosity is set to detailed. [C:\git\Dapper\Dapper\Dapper.csproj]
C:\Program Files\dotnet\sdk\1.0.3\Microsoft.Common.CurrentVersion.targets(1964,5): warning MSB3277: Found conflicts between different versions of the same dependent assembly that could not be resolved.  These reference conflicts are listed in the build log when log verbosity is set to detailed. [C:\git\Dapper\Dapper\Dapper.StrongName.csproj]
C:\Program Files\dotnet\sdk\1.0.3\Microsoft.Common.CurrentVersion.targets(1964,5): warning MSB3277: Found conflicts between different versions of the same dependent assembly that could not be resolved.  These reference conflicts are listed in the build log when log verbosity is set to detailed. [C:\git\Dapper\Dapper.SqlBuilder\Dapper.SqlBuilder.csproj]
C:\Program Files\dotnet\sdk\1.0.3\Microsoft.Common.CurrentVersion.targets(1964,5): warning MSB3277: Found conflicts between different versions of the same dependent assembly that could not be resolved.  These reference conflicts are listed in the build log when log verbosity is set to detailed. [C:\git\Dapper\Dapper.Rainbow\Dapper.Rainbow.csproj]
C:\Program Files\dotnet\sdk\1.0.3\Microsoft.Common.CurrentVersion.targets(1964,5): warning MSB3277: Found conflicts between different versions of the same dependent assembly that could not be resolved.  These reference conflicts are listed in the build log when log verbosity is set to detailed. [C:\git\Dapper\Dapper.Contrib\Dapper.Contrib.csproj]
    5 Warning(s)
    0 Error(s)

Time Elapsed 00:00:11.41
Skipping Tests...
Microsoft (R) Build Engine version 15.1.1012.6693
Copyright (C) Microsoft Corporation. All rights reserved.

C:\git\Dapper\Dapper\Dapper.csproj : error MSB4057: The target "pack" does not exist in the project.
C:\git\Dapper\Dapper.Contrib\Dapper.Contrib.csproj : error MSB4057: The target "pack" does not exist in the project.
C:\git\Dapper\Dapper.EntityFramework\Dapper.EntityFramework.csproj : error MSB4057: The target "pack" does not exist in the project.
C:\git\Dapper\Dapper.Tests.Contrib\Dapper.Tests.Contrib.csproj : error MSB4057: The target "pack" does not exist in the project.
C:\git\Dapper\Dapper.SqlBuilder\Dapper.SqlBuilder.csproj : error MSB4057: The target "pack" does not exist in the project.
C:\git\Dapper\Dapper.Rainbow\Dapper.Rainbow.csproj : error MSB4057: The target "pack" does not exist in the project.
C:\git\Dapper\Dapper\Dapper.StrongName.csproj : error MSB4057: The target "pack" does not exist in the project.
C:\git\Dapper\Dapper.EntityFramework\Dapper.EntityFramework.StrongName.csproj : error MSB4057: The target "pack" does not exist in the project.
C:\git\Dapper\Dapper.Tests.Performance\Dapper.Tests.Performance.csproj : error MSB4057: The target "pack" does not exist in the project.
C:\git\Dapper\NuGet.FrameworkAssemblyPacker\NuGet.FrameworkAssemblyPacker.csproj : error MSB4057: The target "pack" does not exist in the project.
C:\git\Dapper\Dapper.Tests\Dapper.Tests.csproj : error MSB4057: The target "pack" does not exist in the project.

[rohit21agrawal]

this is weird, i was able to produce nupkgs from your branch on my machine....investigating

[rohit21agrawal]

i need some caffeine in me, turns out i gave you NuGet.Build.Tasks instead of NuGet.Build.Tasks.Pack : here is the correct nupkg : https://1drv.ms/u/s!AqkZZxvzm4PPg91IsD3bWl1ptv1spQ

[rohit21agrawal]

out.txt

Attached is the output i am getting on your branch. dapper.csproj is still complaining, i will take a look at that later. i have also attached the generated nupkgs.

nupkgs.zip

[NickCraver]

@rohit21agrawal Yay! I am matching your output and errors on Dapper/EntityFramework now, progress!

Looks like the generated .nupkgs have the proper framework assemblies - is all of the new warning output expected behavior? It's weird for that to issue an errors on a PrivateAssests="All", perhaps that should be excluded? (Separate issue for upcoming code, just noting here)

[NickCraver]

@rohit21agrawal I'm being pinged for support on packages we're unable to build, is there a fix incoming for this, or should we roll back our VS 2017 .csproj migration?

We cannot maintain the status quo, it's causing more pains and delays every day we attempt to use this new project system that isn't ready. I love helping out testing this stuff and giving feedback, but at some point it's not worth it and the harm to our users far outweighs my willingness to help the ecosystem. As a responsible author, we'll have to revert soon if there's no fix available.

[rrelyea]

We have scheduled a fix for this in 15.3.

[NickCraver]

@rrelyea What is the current time frame on 15.3?

[rrelyea]

You can look at the 4.3 milestone in NuGet which corresponds to VS 15.3 - I have an approximate date there -- and will keep it up to date.

[NickCraver]

@rrelyea So we have to wait 2 more months to see this critical bug fixed?

I really mean no offense, but are you kidding me?

[kevinchalet]

I have to agree with @NickCraver... 2 months is way too long for such a breaking change :open_mouth:

[vcsjones]

July?

[gpshonik]

Waiting 2 more months for a fix is not really an option for us either. This bug having a big impact on our plans and needs to be prioritized. Is there any way this can be moved up?

[NickCraver]

I will be moving Dapper back to VS 2015 and project.json this week. This is a hard blocker and being 2 months away is completely unacceptable. We can't delay all fixes for 2 months while this remains open. MiniProfiler will be more complicated, so that sucks, but I'll either have to greatly delay a 4.0 release or do the same there.

I need to do releases today, not months from now. The priority on this needs to go up. A lot. It's not only a breaking change and a blocker for any responsible library author. It's a silent breaking change. Most authors likely don't know they're not generating this, they just expect it to work. But their users are impacted. This is the worst kind of break. Please, realize that and fix this ASAP.

For a gauge of impact to us alone: Dapper has 2.9M downloads, StackExchange.Redis has 2M, and MiniProfiler is another 1.8M. We need to revert to be able to release new builds of any these. MiniProfiler is active, but cannot be released until this is fixed. And that sucks more than just a reversion. It means we need to rip out any C#7 work we're doing and hold off until this is fixed. It blocks a lot more than just builds. For example, we can't deploy Dapper ValueTuple support.

[rrelyea]

Just caught up on the earlier thread. If you can still use privates that Rohit discussed, we'll be able to deliver before 4.3 ships. I'll discuss options with him when he gets in.

[NickCraver]

@rrelyea I'm perfectly willing to use private bits, if we can get some that resolve the issue. The current state of the fix doesn't work for net40 or even Dapper itself.

But that's still not good enough. This is silently breaking anyone with a framework reference who upgrade an existing project. They won't find this issue, and their users are harmed with confusion and broken builds when they add their package. This is critical, and it needs to be fixed for everyone. The lack of tons of voting here is not indicative of a non-critical bug. It's indicative of a silent one.

This should be fixed for everyone way before 2 months from now. Its impact grows daily.

[rohit21agrawal]

how about we release a NuGet.Build.Tasks.Pack.nupkg on NuGet.org which you can take a dependency on? You will have to use the small workaround of passing "NuGetBuildTasksPackTargets" from the command line , but that will go away in 15.3 too (since the issue has been fixed https://github.com/dotnet/sdk/issues/888 ) .

[rohit21agrawal]

@NickCraver what do you mean the current state of the fix doesn't work for for net40?

[mattnischan]

Agreed that this timeline is a bit disappointing. I had to move to .Net Standard only with Immutable.Net for now and avoid targeting lower frameworks specifically because I can't reference framework assemblies. I'm enormously tiny potatoes compared to Dapper, but it does illustrate that this hits even small libraries.

[NickCraver]

@rohit21agrawal To get the results earlier in the thread, I had to remove all net40 targets. See the build log here: https://github.com/NuGet/Home/issues/4853#issuecomment-298139576

[rohit21agrawal]

@NickCraver that was because i gave you the nuget.build.tasks nupkg instead of nuget.build.tasks.pack nupkg. you should be able to add net40 without any issues.

[NickCraver]

@rohit21agrawal Agreed - I just reproduced results with the .Pack, but it can't build Dapper itself so I'm unable to verify the core packages yet (it's the root dependency).

My statements above stand: most package developers won't even know this is happening until the first bug report comes in, so the silent nature really need a more widespread fix than a manual uptake on a package for every single library to add and then remove. Surely the fact that almost everyone would need to fix this manually is an indication of the severity?

[kzu]

@rohit21agrawal annotating the references explicitly is unnecessary. You can trivially detect if the resolved reference is a framework reference, just like we do in NuGetizer:

'%(ReferencePath.ResolvedFrom)' == '{TargetFrameworkDirectory}'

And maybe we should also include things with:

'%(ReferencePath.ResolvedFrom)' == 'ImplicitlyExpandDesignTimeFacades' 

FWIW, this scenario works out of the box in NuGetizer with no changes to your projects. Unfortunately, because the NuGetBuildTasksPackTargets aren't overridable until 15.3, you can't have NuGetizer automatically overrride the /Pack target :(

[rohit21agrawal]

@kzu I did not know that was possible. going to give it a shot. would it still filter out the assemblies which are not part of the framework but are gac'd manually (or by some other software like visual studio?)

[kzu]

GAC? what's that? :P Not even VS GACs anything anymore. Pointless to invest in that, I think.

On the other hand, it may be useful to honor a %(ReferencePath.Pack) == false metadata, now that I think about that...

[mhutch]

Assemblies resolved from the GAC will have '%(ReferencePath.ResolvedFrom)' == '{GAC}', IIRC.

[mhutch]

Also, I think it's worth pointing out that you can use NuGetizer with Sdk style projects, you just need to pass NuGetBuildTasksPackTargets on the commandline until 15.3.

[rohit21agrawal]

To provide an update on this particular issue, we have a pull requested created, once that is code-reviewed we will check it into our dev branch and try to get it merged into the dotnet sdk and VS as early as possible. I will keep this issue updated with VS build availability dates.

In the meanwhile, if you are blocked and want to use the solution in production sooner, please reach out to me at [email protected] . I will be happy to give you access to the official nupkg which you can add as a build time dependency into your project. The only difference between using the nupkg as a build time dependency versus using it in the dotnet cli (or in VS) as part of the VS updates would be the fact that you won't have to download the nupkg manually.

[NickCraver]

@rohit21agrawal Can we post this .nupkg as an unlisted version to NuGet (pre-release or whatever would be fine for us), so all of the usual build tooling works? That makes it very easy for people to workaround the issue without pulling binaries into their git history, re-defining nuget.config, etc.

[rohit21agrawal]

yes, we will be able to do that. Oh, and i forgot, you will have to use the workaround of passing a junk value to your pack command/p:NuGetBuildTasksPackTargets="asasda"

[NickCraver]

@rohit21agrawal While I still think it's imperative this gets out to all library authors as soon as possible via regular update channels (due to the silent nature of the thing), having a workaround in place (that's also easy to consume, so thanks for that) is a good immediate relief and much appreciated.

We'll try and verify results across all of our libraries as soon as we have new bits to test. Happy to test a private .nupkg directly before publishing to the feed to help out. I'm craver @ stackoverflow if email's the best way to drop it.

[rohit21agrawal]

@NickCraver i have sent you a couple emails regarding this fix (and some issues in the Dapper Vs2017 branch).

[NickCraver]

@rohit21agrawal I'm testing locally, still working through issues - and the output is very different than previous tooling, so trying to evaluate whether it's all valid or not. Hopefully I can get Dapper building tonight and provide more feedback. The very different output will take some time to analyze, because I'm not sure what's correct or valid here.

Once I get the build working - I'll provide an old/new tooling comparison generated .nuspec here. See email for issues I'm hitting on AssemblyInfo.cs currently.

[NickCraver]

I think we're still having some issues here. Repro:

1. Download Dapper from the vs2017-test branch here
2. cd Dapper
3. dotnet restore Dapper.csproj
4. dotnet pack Dapper.csproj -c Release -o ..\.nupkgs /p:NuGetBuildTasksPackTargets="000"

This is the resulting Dapper.nuspec in the generated .nupkg:

<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2013/05/nuspec.xsd">
  <metadata>
    <id>Dapper</id>
    <version>1.50.2</version>
    <title>Dapper</title>
    <authors>Sam Saffron,Marc Gravell,Nick Craver</authors>
    <owners>Sam Saffron,Marc Gravell,Nick Craver</owners>
    <requireLicenseAcceptance>false</requireLicenseAcceptance>
    <licenseUrl>http://www.apache.org/licenses/LICENSE-2.0</licenseUrl>
    <projectUrl>https://github.com/StackExchange/Dapper</projectUrl>
    <description>A high performance Micro-ORM supporting SQL Server, MySQL, Sqlite, SqlCE, Firebird etc..</description>
    <releaseNotes>https://stackexchange.github.io/Dapper/</releaseNotes>
    <copyright>2017 Stack Exchange, Inc.</copyright>
    <tags>orm sql micro-orm</tags>
    <repository type="git" url="https://github.com/StackExchange/Dapper" />
    <dependencies>
      <group targetFramework=".NETFramework4.0" />
      <group targetFramework=".NETFramework4.5" />
      <group targetFramework=".NETFramework4.5.1" />
      <group targetFramework=".NETStandard1.3">
        <dependency id="NETStandard.Library" version="1.6.1" exclude="Build,Analyzers" />
        <dependency id="System.Collections.Concurrent" version="4.3.0" exclude="Build,Analyzers" />
        <dependency id="System.Collections.NonGeneric" version="4.3.0" exclude="Build,Analyzers" />
        <dependency id="System.Data.SqlClient" version="4.3.0" exclude="Build,Analyzers" />
        <dependency id="System.Dynamic.Runtime" version="4.3.0" exclude="Build,Analyzers" />
        <dependency id="System.Reflection.Emit" version="4.3.0" exclude="Build,Analyzers" />
        <dependency id="System.Reflection.Emit.Lightweight" version="4.3.0" exclude="Build,Analyzers" />
        <dependency id="System.Reflection.TypeExtensions" version="4.3.0" exclude="Build,Analyzers" />
        <dependency id="System.Runtime.InteropServices" version="4.3.0" exclude="Build,Analyzers" />
        <dependency id="System.Xml.XmlDocument" version="4.3.0" exclude="Build,Analyzers" />
      </group>
    </dependencies>
    <frameworkAssemblies>
      <frameworkAssembly assemblyName="Microsoft.CSharp" targetFramework=".NETFramework4.0, .NETFramework4.5, .NETFramework4.5.1" />
      <frameworkAssembly assemblyName="System.Core" targetFramework=".NETFramework4.0, .NETFramework4.5, .NETFramework4.5.1" />
      <frameworkAssembly assemblyName="System.Data" targetFramework=".NETFramework4.0, .NETFramework4.5, .NETFramework4.5.1" />
      <frameworkAssembly assemblyName="System" targetFramework=".NETFramework4.0, .NETFramework4.5, .NETFramework4.5.1" />
      <frameworkAssembly assemblyName="System.Drawing" targetFramework=".NETFramework4.0, .NETFramework4.5, .NETFramework4.5.1" />
      <frameworkAssembly assemblyName="System.Numerics" targetFramework=".NETFramework4.0, .NETFramework4.5, .NETFramework4.5.1" />
      <frameworkAssembly assemblyName="System.Runtime.Serialization" targetFramework=".NETFramework4.0, .NETFramework4.5, .NETFramework4.5.1" />
      <frameworkAssembly assemblyName="System.Xml" targetFramework=".NETFramework4.0, .NETFramework4.5, .NETFramework4.5.1" />
      <frameworkAssembly assemblyName="System.Xml.Linq" targetFramework=".NETFramework4.0, .NETFramework4.5, .NETFramework4.5.1" />
      <frameworkAssembly assemblyName="System.IO.Compression.FileSystem" targetFramework=".NETFramework4.5, .NETFramework4.5.1" />
    </frameworkAssemblies>
  </metadata>
</package>

This is the reference list:

<Reference Include="System.Data" />
<Reference Include="System.Xml" />
<Reference Include="System.Xml.Linq" />
<Reference Include="System" />
<Reference Include="Microsoft.CSharp" />

...where did System.Drawing come from? and System.Numerics, etc.? I'm not sure why these are suddenly coming up as dependencies. I'm using the 4.3.0-preview1-4045 version of NuGet.Build.Tasks.Pack as directed.

IMO this issue should not be closed, it doesn't seem like we're quite there yet.

[rohit21agrawal]

As i said in the linked PR description (and in the email I sent) :

All implicit framework references will also be added by default. For a list of implicit references, see : https://github.com/dotnet/sdk/blob/release/2.0.0/src/Tasks/Microsoft.NET.Build.Tasks/build/Microsoft.NET.Sdk.BeforeCommon.targets#L84-L109

If you don't want to include implicity framework assembly references, you can set DisableImplicitFrameworkReferences to true. Doing this will remove all implicit framework assembly references, except System.Core which is special and added via a different property called AdditionalExplicitAssemblyReferences. You can skip the addition of System.Core by specifying AddAdditionalExplicityAssemblyReferences to false.

[rohit21agrawal]

Also, we have filed an issue on SDK to fix the implicit references: https://github.com/dotnet/sdk/issues/1179

[NickCraver]

@rohit21agrawal Gotcha - those make sense, though the default behavior doesn't (agree with the SDK issue).

Follow-up question: can you please explain the new exclude attribute on <dependency>? It's not documented currently: https://docs.microsoft.com/en-us/nuget/schema/nuspec#dependencies and is a diff vs. the previous .nuspec.

[rohit21agrawal]

here is the context of the exclude attribute : https://github.com/NuGet/Home/issues/3697

[NickCraver]

@rohit21agrawal okay that helps, next steps:

1. Can we get a NuGet.Build.Tasks.Pack with the fix uploaded to NuGet.org? (even if unlisted)
2. Can we get exclude added to the documentation?

On 2 I realize we can edit the documentation now, but while I get the intent, it's probably better documented by those who know further implications.

[rohit21agrawal]

package is available on nuget.org now. will work on getting 2 done.

[NickCraver]

@rohit21agrawal Thank you very much for all the work here - with quite a few other changes not related to this (two .csproj in a single folder is a deep rabbit hole I gave up on), I've now got a working build of Dapper with packages that seem correct. I'll do more validation in the morning, but so far so good - current code is in a PR here: https://github.com/StackExchange/Dapper/pull/766

[stakx]

@rohit21agrawal: Thanks for making NuGet.Build.Tasks.Pack.nupkg available. Unfortunately however, there is another issue with it (version 4.3.0-preview1-4045): It won't work with projects that target the .NET Framework 2.0, e.g. a .csproj file with <TargetFrameworks>net20;net40</TargetFrameworks>.

This is apparently caused by NuGet.Build.Tasks.Pack introducing a build-time dependency on the System.IO.Compression package, which does not support the net20 target. Is there any chance you could fix this, please?

(Just for the record, I realise that the .NET Framework 2.0 is ancient, and that MSFT doesn't really want to support it anymore. Nevertheless, it is a valid target framework, and msbuild /t:Restore;Build;Pack would handle it just fine.)

[AArnott]

@stakx The issue with System.IO.Compression has nothing to do with your target framework. It has everything to do with the fact that the Pack task doesn't work on any version of the .NET Framework unless another MSBuild Task just happens to have loaded that assembly from CoreCLR first. See https://github.com/NuGet/Home/issues/4290

[stakx]

@AArnott: Thank you for the explanation and for following up on this issue. 👍

Since the package I'm building isn't critical, I've decided to sit this out and wait for an official version of MSBuild / NuGet that actually works out of the box. Hopefully that won't be much longer.

[AArnott]

I just tried this out on 15.3 Preview. The framework assemblies added to the nuspec are:

    <frameworkAssemblies>
      <frameworkAssembly assemblyName="System.ComponentModel.Composition" targetFramework=".NETFramework4.0, .NETFramework4.5" />
      <frameworkAssembly assemblyName="System.Core" targetFramework=".NETFramework4.0, .NETFramework4.5" />
      <frameworkAssembly assemblyName="System.Data" targetFramework=".NETFramework4.0, .NETFramework4.5" />
      <frameworkAssembly assemblyName="System" targetFramework=".NETFramework4.0, .NETFramework4.5" />
      <frameworkAssembly assemblyName="System.Drawing" targetFramework=".NETFramework4.0, .NETFramework4.5" />
      <frameworkAssembly assemblyName="System.Numerics" targetFramework=".NETFramework4.0, .NETFramework4.5" />
      <frameworkAssembly assemblyName="System.Runtime.Serialization" targetFramework=".NETFramework4.0, .NETFramework4.5" />
      <frameworkAssembly assemblyName="System.Xml" targetFramework=".NETFramework4.0, .NETFramework4.5" />
      <frameworkAssembly assemblyName="System.Xml.Linq" targetFramework=".NETFramework4.0, .NETFramework4.5" />
      <frameworkAssembly assemblyName="System.IO.Compression.FileSystem" targetFramework=".NETFramework4.5" />
    </frameworkAssemblies>

Yet the only reference I have explicitly in my csproj is:

  <ItemGroup>
    <Reference Include="System.ComponentModel.Composition" Condition=" '$(TargetFramework)' == 'net40' or '$(TargetFramework)' == 'net45' " />
  </ItemGroup>

Now I realize that the new .NET SDK project type adds a bunch of framework references implicitly, and that's probably where the longer list in the nuspec is coming from. But it seems a shame that I'm forcing all my users to require all these framework assemblies to be referenced when they have nothing to do with the package. It seems it might be better if any unused framework reference were dropped automatically from the nuspec. Is that a possibility?

[bording]

@AArnott Which version of the 15.3 preview are you using? I'm using the publicly released 15.3.0 Preview 2.0 version, and I'm still not seeing framework references show up at all.

[AArnott]

@bording I'm using an internal build of 15.3 preview. Build "d15rel 26612.0", specifically.

[scalablecory]

@AArnott The workaround for this is unfortunately a bit involved:

<DisableImplicitFrameworkReferences>true</DisableImplicitFrameworkReferences>

And explicitly reference the "freebies" like System/System.Core.

@NickCraver does this in his Dapper PR.

I agree it'd be nice if there was a way to scrub this a little better.

[nguerrera]

https://github.com/dotnet/sdk/issues/1179 tracks preventing implicit references from impacting nuspec. A fix was made for it, but recent discussion on it suggests there may still be an issue.

[bording]

Is this still not working in a publicly released version? I'm using 15.3 preview 3.0 now, and I'm still not seeing assembly references being added to the packages I'm creating.

[rohit21agrawal]

@bording what are you using to pack (msbuild or dotnet)? can you tell me the file version of "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Sdks\NuGet.Build.Tasks.Pack\CoreCLR\NuGet.Build.Tasks.Pack.dll"

[clairernovotny]

@rohit21agrawal is it in there with VS or in the version that's part of the Preview2+ .NET Core SDK tools? I saw it working once I installed the .NET Core 2 Preview 2 build because it picked up the version from that SDK. The one that's alongside VS is 1.0.4 AFAIK.

[rohit21agrawal]

as of now it ships as part of both VS and .NET Core.

[bording]

@rohit21agrawal I've tried packing with Visual Studio, and also using msbuild.exe /t:pack from the command line. I can't currently use dotnet pack on this project because it uses GitVersion, which doesn't yet have build targets compatible with .NET Core.

The file version of "C:\Program Files (x86)\Microsoft Visual Studio\Preview\Professional\MSBuild\Sdks\NuGet.Build.Tasks.Pack\Desktop\NuGet.Build.Tasks.Pack.dll" is 4.3.0.4087.

[rohit21agrawal]

@bording that version definitely has the fix. can you provide me a sample of the project that repros this for you?

[bording]

@rohit21agrawal I've been seeing this while working on https://github.com/Particular/NServiceBus, and the develop branch now has netcoreapp2.0 targets.

As an example, this project file has framework assembly references that are not included by default in the new project system, but the package produced does not reference them.

[rohit21agrawal]

I just tried packing the project file you provided with the version of msbuild that shipped with 15.3 Preview 3 and i got the following assembly references in my output nuspec:

I did have to remove netcoreapp2.0 as target framework because restore wasn't able to resolve some package required for that particular TFM.

<frameworkAssemblies>
      <frameworkAssembly assemblyName="Microsoft.CSharp" targetFramework=".NETFramework4.5.2" />
      <frameworkAssembly assemblyName="System.Configuration" targetFramework=".NETFramework4.5.2" />
      <frameworkAssembly assemblyName="System.Core" targetFramework=".NETFramework4.5.2" />
      <frameworkAssembly assemblyName="System.Data" targetFramework=".NETFramework4.5.2" />
      <frameworkAssembly assemblyName="System" targetFramework=".NETFramework4.5.2" />
      <frameworkAssembly assemblyName="System.Drawing" targetFramework=".NETFramework4.5.2" />
      <frameworkAssembly assemblyName="System.IO.Compression.FileSystem" targetFramework=".NETFramework4.5.2" />
      <frameworkAssembly assemblyName="System.Numerics" targetFramework=".NETFramework4.5.2" />
      <frameworkAssembly assemblyName="System.Runtime.Serialization" targetFramework=".NETFramework4.5.2" />
      <frameworkAssembly assemblyName="System.Transactions" targetFramework=".NETFramework4.5.2" />
      <frameworkAssembly assemblyName="System.Xml" targetFramework=".NETFramework4.5.2" />
      <frameworkAssembly assemblyName="System.Xml.Linq" targetFramework=".NETFramework4.5.2" />
    </frameworkAssemblies>

[bording]

@rohit21agrawal I'm definitely not seeing that when I build it. What package could you not resolve for netcoreapp2.0? They should all be publicly available.

[bording]

When I pack that project here is the nuspec that gets generated in the obj folder:

<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2012/06/nuspec.xsd">
  <metadata>
    <id>NServiceBus.AcceptanceTesting</id>
    <version>7.0.0-alpha0030</version>
    <authors>NServiceBus Ltd</authors>
    <owners>NServiceBus Ltd</owners>
    <requireLicenseAcceptance>true</requireLicenseAcceptance>
    <licenseUrl>http://particular.net/LicenseAgreement</licenseUrl>
    <projectUrl>http://particular.net/</projectUrl>
    <iconUrl>http://s3.amazonaws.com/nuget.images/NServiceBus_32.png</iconUrl>
    <description>Acceptance testing framework for NServiceBus endpoints. This is an unsupported package.</description>
    <copyright>Copyright 2010-2017 NServiceBus. All rights reserved</copyright>
    <tags>nservicebus servicebus msmq cqrs publish subscribe</tags>
    <dependencies>
      <group targetFramework=".NETFramework4.5.2">
        <dependency id="NServiceBus" version="1.0.0" exclude="Build,Analyzers" />
      </group>
      <group targetFramework=".NETCoreApp2.0">
        <dependency id="NServiceBus" version="1.0.0" exclude="Build,Analyzers" />
      </group>
    </dependencies>
  </metadata>
  <files>
    <file src="C:\Code\NServiceBus\binaries\net452\NServiceBus.AcceptanceTesting.dll" target="lib\net452\NServiceBus.AcceptanceTesting.dll" />
    <file src="C:\Code\NServiceBus\binaries\netcoreapp2.0\NServiceBus.AcceptanceTesting.dll" target="lib\netcoreapp2.0\NServiceBus.AcceptanceTesting.dll" />
    <file src="C:\Code\NServiceBus\binaries\net452\NServiceBus.AcceptanceTesting.pdb" target="lib\net452\NServiceBus.AcceptanceTesting.pdb" />
    <file src="C:\Code\NServiceBus\binaries\netcoreapp2.0\NServiceBus.AcceptanceTesting.pdb" target="lib\netcoreapp2.0\NServiceBus.AcceptanceTesting.pdb" />
  </files>
</package>

[clairernovotny]

@bording silly question, but how are you invoking your build when you're trying this? Are you sure you're using the msbuild from the VS Preview directory and not the main VS 2017 stable directory? (just verifying) :)

[bording]

@onovotny I'm running it from a VM that has only ever had the preview VS installed, so there isn't another MSBuild to conflict.

To double check, here's the output from which msbuild:

C:\Program Files (x86)\Microsoft Visual Studio\Preview\Professional\MSBuild\15.0\Bin\MSBuild.exe

[bording]

I just double checked to make sure I'm running the latest Preview release, and the Installer thinks I'm updated. Here's what I'm seeing in the About box:

I've also have 15.3 Preview 3 installed on our CI build agent, and it is not producing packages with framework assembly references either.

[bording]

@rohit21agrawal I also just tried removing the netcoreapp2.0 target from the AcceptanceTesting project to see if that was somehow causing the problem, but it just produces the following:

<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2012/06/nuspec.xsd">
  <metadata>
    <id>NServiceBus.AcceptanceTesting</id>
    <version>7.0.0-fix-source-packa0001</version>
    <authors>NServiceBus Ltd</authors>
    <owners>NServiceBus Ltd</owners>
    <requireLicenseAcceptance>true</requireLicenseAcceptance>
    <licenseUrl>http://particular.net/LicenseAgreement</licenseUrl>
    <projectUrl>http://particular.net/</projectUrl>
    <iconUrl>http://s3.amazonaws.com/nuget.images/NServiceBus_32.png</iconUrl>
    <description>Acceptance testing framework for NServiceBus endpoints. This is an unsupported package.</description>
    <copyright>Copyright 2010-2017 NServiceBus. All rights reserved</copyright>
    <tags>nservicebus servicebus msmq cqrs publish subscribe</tags>
    <dependencies>
      <group targetFramework=".NETFramework4.5.2">
        <dependency id="NServiceBus" version="7.0.0-fix-source-packa0001" exclude="Build,Analyzers" />
      </group>
    </dependencies>
  </metadata>
  <files>
    <file src="C:\Code\NServiceBus\binaries\net452\NServiceBus.AcceptanceTesting.dll" target="lib\net452\NServiceBus.AcceptanceTesting.dll" />
    <file src="C:\Code\NServiceBus\binaries\net452\NServiceBus.AcceptanceTesting.pdb" target="lib\NServiceBus.AcceptanceTesting.pdb" />
  </files>
</package>

[rohit21agrawal]

can you do a diag build+pack and attach the log file?

[bording]

@rohit21agrawal What would be the specific command you'd like me to invoke? Just enable diagnostics level logging?

[rohit21agrawal]

Msbuild /t:pack /v:diag

[bording]

@rohit21agrawal Here you go:
log.zip

[rohit21agrawal]

Using "PackTask" task from assembly "C:\Program Files\dotnet\sdk\2.0.0-preview1-005977\Sdks\NuGet.Build.Tasks.Pack\buildCrossTargeting\..\Desktop\NuGet.Build.Tasks.Pack.dll".

This is what i see in the log file. So the msbuild you are using is resolving the dotnet core sdk to 2.0.0-preview1-005977 which does not have the fix.

[bording]

@rohit21agrawal Is it supposed to do that? Is there a way for me to prevent that from happening?

[rohit21agrawal]

@bording I actually don't know that for sure. Tagging @nguerrera since he might be the best person to answer this.

[rohit21agrawal]

but for now, you can always install the latest CLI from https://github.com/dotnet/cli/tree/release/2.0.0-preview2 and that should fix your problem.

[bording]

I had been wanting to wait for the official preview 2 bits before installing them, but if that's the only way to work around the issue, I guess I should give them a try now.

[clairernovotny]

The way to stop it is to use a global.json and pin the SDK version to 1.0.4. That's the one VS 2017 ships "in box".

[bording]

@onovotny Will that still work if I'm actually targeting netcoreapp2.0, though?

[clairernovotny]

@bording nope. If you need netcoreapp2.0, then you'll need the latest SDK from the preview2 branch then. FWIW, I have that working on AppVeyor w/o issues:

https://github.com/paulcbetts/refit/blob/master/appveyor.yml#L7-L9

[bording]

Sounds like I'll be grabbing some preview2 bits then!

It does seem odd to me that MSBuild would ship with a version of the PackTask assembly that won't actually be used though, even when targeting just net452.

[dasMulli]

Another workaround would be to use the NuGet.Build.Tasks.Pack nuget package that was published to nuget.org yesterday:

<Project>
  <PropertyGroup>
    <NuGetBuildTasksPackTargets>junk-value-to-avoid-conflicts</NuGetBuildTasksPackTargets>
  </PropertyGroup>
  <Import Project="Sdk.props" Sdk="Microsoft.NET.Sdk" />

  <!-- All your project's other content here -->

  <ItemGroup>
    <PackageReference Include="NuGet.Build.Tasks.Pack" Version="4.3.0-preview3-4168" PrivateAssets="All" />
  </ItemGroup>
  <Import Project="Sdk.targets" Sdk="Microsoft.NET.Sdk" />
</Project>

VS' MSBuild now carries an SDK resolver that uses the installed CLI. AFAIK mono's msbuild will do the same.