search

dotnet / msbuild

The Microsoft Build Engine (MSBuild) is the build platform for .NET and Visual Studio.
https://docs.microsoft.com/visualstudio/msbuild/msbuild
MIT License
5.22k stars 1.35k forks source link

Runtime/Platform-specific package build artifact import #2807

Open A-And opened 6 years ago

A-And commented 6 years ago

This seems to be a

Steps to reproduce

  1. Following the instructions in the CoreFX repo to create a platform-specific library with an associated metapackage. (e.g. Microsoft.DotNet.FooPackage and runtime.win-x64.Microsoft.DotNet.FooPackage).
  2. In the platform-specific package add a .targets file with the name of the package under a build folder.
  3. Push the created packages to a package feed (local or remote).
  4. Create any simple .NET Core app template and add a reference to the created package. If not already added, also add the package feed as a package source.
  5. Specify a property in the .csproj file of the app with its target runtime. ( e.g. <RuntimeIdentifiers>win-x64</RuntimeIdentifiers>)
  6. Run dotnet restore

Expected behavior

The build artifact in the runtime-specific package is added to the app's nuget.g.targets/props files. This seems to be the case for MSBuild outside of .NET Core.

Actual behavior

The build artifact in the runtime-specific package is not added to the app's nuget.g.targets/props files.

Environment data

msbuild /version output: 15.5.180.51428

OS info: Microsoft Windows 10 Enterprise Version 10.0.16299 Build 16299

If applicable, version of the tool that invokes MSBuild (Visual Studio, dotnet CLI, etc): dotnet cli 2.1.4-preview-007237

rainersigwald commented 6 years ago

@A-And Any chance you can zip up an example platform-specific package? I looked at the corefx instructions briefly and got intimidated.

And to be clear, you're seeing it fail with dotnet build but succeed with msbuild.exe?

A-And commented 6 years ago

@rainersigwald Sure thing! We built a workaround for this in CoreRT, so I'll remove the workarounds and send you an example package.

For some more clarity - .NET Native uses a similar package setup - one platform-agnostic identity package, which imports platform-specific packages at build-time. These specific packages have build artifacts, which get successfully added as build targets/props.

The same package layout doesn't seem to behave in the same way when using dotnet restore/build/publish.