PackageReference is missing copy files to output feature

Question

PackageReference is missing copy files to output feature

rainersigwald opened this issue 8 years ago · 51 comments

Moved from dotnet/msbuild#1880 on behalf of original poster @Ciantic.

I'm trying to use PhantomJS NuGET package, but it's not possible with PackageReference:

<PackageReference Include="PhantomJS" Version="2.1.1">
      <IncludeAssets>all</IncludeAssets>
</PackageReference>

It does not do anything. I'd expect it to copy the files inside PhantomJS package to the output directory so I could use the binary file inside the package.

I think PackageReference does not have support using packages such as PhantomJS which have no .NET code in it, just random files.

I suggest a feature to be able to copy files from a NuGET package to output directory

<PackageReference Include="PhantomJS" Version="2.1.1">
      <CopyToOutputDirectory>tools/*</CopyToOutputDirectory> <!-- new feature here -->
</PackageReference>

Note that the PhantomJS has folder called "tools" inside, that needs to be copied to output directory to make it usable in the app.

Answer 1 · 2017-03-17T15:52:30.000Z

NuGET is reading the csproj file when I run dotnet build?

Let me clarify, when I run dotnet build I want it to copy the tools/* from PhantomJS referenced package to output directory so I can use it in the dotnet app.

I think NuGet is not in that process.

Answer 2 · 2017-03-17T15:55:29.000Z

The MSBuild engine runs logic from a variety of sources when you run dotnet build. The targets and tasks that handle the Restore target and extracting information from NuGet packages for consumption in the build are owned by the NuGet team, so this is the best place for reporting problems/asking for features related to the handling of NuGet packages.

Answer 3 · 2017-03-20T14:56:13.000Z

NuGet packages that work with Packages.config, don't always work in transitive NuGet environments (projects using Project.json or PackageReferences).

In this case, it looks like Phantom.js has "content" and tools\install.ps1.

Packages that work in transitive NuGet environments must use "contentFiles" instead of "content" -- you can have both, if a package would like to work in both environments.
Also, install.ps1/uninstall.ps1 doesn't execute in transitive NuGet environments -- however, init.ps1 will work in both Packages.config and transitive environments.

Answer 4 · 2017-03-21T19:40:14.000Z

I've opened also a StackOverflow question. I'd hate to put a 18MB phantomjs.exe to the repository of the app, but that seems like the only way right now with .NET Core.

I gather you are not opposed to adding a feature to PackageReference since this is not closed. I think it's not reasonable to assume that these old NuGet packages are going to get a change just for .NET core. I don't even want to run a install.ps1 (what ever it does) just copy the tools/phantomjs/phantomjs.exe to the output directory during build.

P.S. I've now tried to contact the PhantomJS NuGet Package author (@whyleee) and gave the suggestion to look at this thread how to fix the package.

Answer 5 · 2017-03-31T14:24:44.000Z

Is there a work around to get the new style csproj PackageReference to work with content files in a nuget package?

example nuspec that worked before package reference.


<package >
  <metadata>
 ...
  </metadata>
  <files>
	<file src="..\bin\any\*" target="Content/tools"/>
  </files>
</package>

In old csproj projects, when installing this nuget file all the files would show up in a tools folder in the project root. Now nothing happens.

The StackOverflow discussion on this issue mentions the work around is contentFiles. Using contentFiles will copy the files to the bin folder when using "dotnet build" but nothing like how it use to work. Is that the best I can do at this point?

<package >
  <metadata>
   ...
      <contentFiles>
      <files include="**" buildAction="None" copyToOutput="true" flatten="false" />
    </contentFiles>
  </metadata>
  <files>
	<file src="..\bin\{{config}}\*" target="contentFiles\any\any\tools\some_exe_and_stuff"/>
	<file src="..\bin\{{config}}\*" target="content\tools\some_exe_and_stuff"/>
  </files>
</package>

Answer 6 · 2017-08-17T04:52:13.000Z

I was linked here from https://developercommunity.visualstudio.com/content/problem/89472/nuget-packages-with-ps1-content-files-are-not-bein.html as this issue is supposedly "identical". I would question that claim but the original got closed and there seems nothing I can do about it, so I will add my issue description here.

I have a NuGet package that delivers a set of PowerShell scripts (.ps1 files).

The intended usage is to deliver these files into the target project as a folder in the filesystem directly under the project the package is installed into (e.g. installing into C:\Foo\Foo.csproj should create C:\Foo\xxx\yyy.ps1).

When I use VS2017 in packages.config mode, it works fine.

When I use VS2017 in PackageReference mode, none of the files show up in either the filesystem or Solution Explorer.

I tried both using just "/content" paths and the new contentFiles feature. Neither option made anything show up in my project. I cannot distribute my scripts anymore. I am currently looking at using Paket, which is a 3rd party NuGet alternative that appears to be far more flexible and easily usable. It is a shame to see NuGet un-fixing the problems that NuGet once fixed!

Answer 7 · 2017-08-24T09:56:32.000Z

I'd be interested for a solution where content files would be copied in the project cause i got less files that I want to compile from a package with gulp, but gulp does not see the less files in the projects, so I don't have any css files generated

Answer 8 · 2017-10-17T23:11:24.000Z

The targets/props for modifying build items coming from packages should be added to the samples and documented.

Answer 9 · 2017-10-26T00:26:48.000Z

It would be awesome to reference a NuGet package using PackageReference and specify which files from the package should be copied to output.

My problem currently: referencing https://www.nuget.org/packages/Microsoft.DiaSymReader.Native and none of the native .dlls get copied to output.

Answer 10 · 2017-11-08T17:47:04.000Z

This issue is also affecting Microsoft.AspNet.SignalR.JS (a Microsoft.AspNet.SignalR dependency), causing the required Javascript to fail to get copied into the project's ~/Scripts folder, rendering SignalR unusable. I'm surprised Microsoft isn't at least addressing this problem in its own packages.

Answer 11 · 2017-11-22T19:53:33.000Z

Any ETA on this? My company is very interested in moving to VS2017 to get the benefits of PackageReference but this is a deal breaker.

Answer 12 · 2017-11-22T21:08:29.000Z

@pm64 this issue is for copying referenced assemblies to the output folder. You are describing copying content files to the project itself, which is a different issue.

Answer 13 · 2017-12-06T20:18:51.000Z

Almost every old wrapper Nuget package has some file inside of it and it is really hard for them to update this packages. In my company we're stuck in this migration because we have an old depency that have a native dll inside of the libs folder, I've tried a lot of things but didn't get any success.
When will Nuget have the ability to let me chose which file should be copied to the output folder?

I think this is related to #4488 🤔

Answer 14 · 2017-12-23T15:27:18.000Z

I have a similar problem here. I try to host my ASP.NET Core MVC applications in IIS, and the problem is that when I add a package reference to some packages, their assemblies are not copied to output directory, and also it seems that runtime is not able to find their places. So I get can't load assembly, file not found error.

To make things work, I need to manually go and copy files to the output directory, which is soooooooo stupid and inefficient. Also including referenced assemblies directly and setting their copy local to true doesn't work.

dotnet/core#1183

Answer 15 · 2017-12-30T09:28:17.000Z

I've just found this property that is working for me: CopyLocalLockFileAssemblies

<PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
    <CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
  </PropertyGroup>

And it seems it copies everything, including framework references: dotnet/sdk#933

Answer 16 · 2018-08-27T10:32:01.000Z

Any ideas how to work with tools dir inside of PackageReference?

Tried to use <CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies> for NET461 - no luck

Answer 17 · 2018-09-11T17:44:19.000Z

I have a similar problem here. I try to host my ASP.NET Core MVC applications in IIS, and the problem is that when I add a package reference to some packages, their assemblies are not copied to output directory, and also it seems that runtime is not able to find their places. So I get can't load assembly, file not found error.

To make things work, I need to manually go and copy files to the output directory, which is soooooooo stupid and inefficient. Also including referenced assemblies directly and setting their copy local to true doesn't work.

dotnet/core#1183

I have the exact same problem.. any solution for this by now?

Answer 18 · 2018-09-24T05:42:15.000Z

I've found a hacky way of doing this. We extract the package version from the PackageReference we want to copy files from and then use that to build a path to the package file:

  <Target Name="CopyPackages" AfterTargets="Build">
    <PropertyGroup>
      <OctopusPackageVersion Condition="%(PackageReference.FileName) == 'OctopusTools'">%(PackageReference.Version)</OctopusPackageVersion>
    </PropertyGroup>
    <ItemGroup>
      <OctoTools Include="$(NuGetPackageRoot)\OctopusTools\$(OctopusPackageVersion)\tools\*" />
    </ItemGroup>
    <Copy 
      SourceFiles="@(OctoTools)"
      DestinationFolder="$(OutDir)"
    />
  </Target>

Answer 19 · 2018-09-24T05:56:21.000Z

After thinking about this a bit more, I released it's possible to create a target that will perform the expected operation requested by @rainersigwald :

  <ItemGroup>
    <PackageReference Include="OctopusTools" Version="4.41.2">
      <CopyToOutputDirectory>tools/*</CopyToOutputDirectory>
    </PackageReference>
  </ItemGroup>

  <Target Name="CopyPackages">
    <ItemGroup>
      <PackageReferenceFiles 
        Condition="%(PackageReference.CopyToOutputDirectory) != ''" 
        Include="$(NugetPackageRoot)\%(PackageReference.FileName)\%(PackageReference.Version)\%(PackageReference.CopyToOutputDirectory)" />
    </ItemGroup>
    <Copy
      SourceFiles="@(PackageReferenceFiles)"
      DestinationFolder="$(OutDir)"
    />
  </Target>

This will copy the files from any PackageReference which has a CopyToOutputDirectory element underneath it.

Answer 20 · 2018-09-24T14:01:08.000Z

@unickq

Any ideas how to work with tools dir inside of PackageReference?

Tried to use <CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies> for NET461 - no luck

The package itself is expected to set an MSBuild property to the path to its tools directory. For example, see how the Microsoft.CodeDom.Providers.DotNetCompilerPlatform package sets RoslynToolPath: https://github.com/aspnet/RoslynCodeDomProvider/blob/1f4a542d407c4fb6ce504aaa63418044d52c6717/src/Packages/Microsoft.CodeDom.Providers.DotNetCompilerPlatform/build/net46/Microsoft.CodeDom.Providers.DotNetCompilerPlatform.Extensions.props . Or how Selenium.WebDriver.ChromeDriver sets ChromeDriverSrcPath: https://github.com/jsakamoto/nupkg-selenium-webdriver-chromedriver/blob/c9dae061ff521328430cd855cad314cf6aa33aed/src/Selenium.WebDriver.ChromeDriver.targets#L13

This is cleaner because it allows the package to enforce encapsulation and have a public API. It also allows you to avoid copying build-time tools all over the place—you just have one copy for each version in ~/.nuget/packages. However, there are a lot of old packages out there written for the old style nuget which do not properly expose the paths to tools even though their tools are intended for the package users’ direct consumption.

Answer 21 · 2018-09-25T05:13:16.000Z

Thanks @binki, sounds like the clean solution - although the package maintainer has to realize it. I understood that

the nuget package should include a foo.targets file that is picked up by MSBuild
the targets file can define new properties or a <Copy ... /> task

But how does the MSBuild property avoid copying some required content into every output directory? That's what the Copy task would do. Put differently: how can I copy my content "transitively" only into the output of the final consumer app's bin folder? Would be great, if we can clarify this - eventually I'm able to explain it to some package maintainers. Many are struggling right now.

Answer 22 · 2018-10-07T21:00:51.000Z

This will copy the files from any PackageReference which has a CopyToOutputDirectory element underneath it.

@samk1 The problem is a bit more complex than your solution as it requires proper handling of TFMs for package and project. Your solution will not work with many recent packages i.e. xunit.runner.console.

Answer 23 · 2019-02-04T23:26:28.000Z

any further update when to expect a fix to this issue?

Answer 24 · 2019-03-19T03:29:44.000Z

Looks like a solution was added and merged here.
NuGet/NuGet.Client#2271

The GeneratePathProperty attribute was added to PackageReference

<PackageReference Include="EO.Pdf" GeneratePathProperty="true">
    <Version>19.0.83</Version>
</PackageReference>

<Target Name="CopyEoPdfExe" AfterTargets="Build">
    <Copy SourceFiles="$(PkgEO_Pdf)\lib\eowp.exe" DestinationFolder="$(OutDir)" />
</Target>

Check your <project>\obj\<project>.csproj.nuget.g.props to verify the variables are generated

Variables are prefixed with Pkg. It sounds like they are automatically generated for all nuget packages with a tools folder.

Answer 25 · 2019-07-30T18:27:17.000Z

@nsmi

Check your <project>\obj\<project>.csproj.nuget.g.props to verify the variables are generated

Variables are prefixed with Pkg. It sounds like they are automatically generated for all nuget packages with a tools folder.

Your solution works great, but do you have any idea, how to handle it, when the /tools folder does not exist? It's a package build with Nuget.Output and contains only an /output folder. So finally it does not get listed in this .nuget.g.props file.

EDIT: Answer: Use GeneratePathProperty within the .csproj Package reference.
e.g. <PackageReference Include="MyPackage" GeneratePathProperty="true">
This generates now the variable within the nuget.g.props file.

Answer 26 · 2020-02-21T11:12:42.000Z

We noticed, that the GeneratePathProperty is not kept during an update of a file via the GUI. It would be fantastic if someone could extend this to keep the setting. The legacy package we linked with this mechanism is referenced about 20-30 times and is a pain to fix, when you don't just replace the RegEx.

Answer 27 · 2020-02-21T18:42:36.000Z

Which GUI are you talking about? the NuGet UI? or the project properties?

Answer 28 · 2020-02-21T18:43:44.000Z

@StarWars999123 would you mind filing a separate issue for this? It's a good observation, the UI should not stomp over users changes in the .csproj and it should be careful to preserve the existing text and formatting as much as possible.

Answer 29 · 2020-08-13T01:23:50.000Z

How is this supposed to work for projects using PackageReference for NuGet packages that contain a dependency on another NuGet package that has "contentFiles"?
i.e.
Project Z depends upon Package X
Package X has a dependency on Package Y
Package Y is a simple package that only has a "contentFiles", specifically "contentFiles/Any/Any/*"

If I make a direct PackageReference from Project Z to Package Y, I see the appropriate contentFiles in my project's output directory. However, when I only have the PackageReference from Project Z to Package X, I'm not getting the dependent contentFiles from Package Y in the output directory.

Answer 30 · 2021-01-07T10:15:01.000Z

I am seeing the same thing as @Patrico12345 with a large internal dependency tree, where some of the sub dependencies have "contentFiles" that don't seem to be processed, I.e. the files under referenced by the "contentFiles" elements are not processed according to the attributes on the element.

It can be worked around by adding the packages as direct dependencies of the project, but clearly this isn't how we want to be doing things.

Answer 31 · 2021-01-19T13:28:19.000Z

Observing the exact same thing as @pyrostew and @Patrico12345.
It completely defeats the very purpose of Nuget (handling dependencies !).

I really don't understand how this bug has been lingering for so long : the problem seems pretty straightforward once you put the finger on it.

Let's hope it will be resolved soon.

The workaround (direct dependency) might seem fine at first glance, but it's a nightmare when one of the nugets gets an update !

Answer 32 · 2021-06-27T15:36:58.000Z

Is there any movement on this?

In VS2019 unless I add an Assembly Reference to the .dll file in the .nuget folder, I get

Error	CS0234	The type or namespace name 'WSMan' does not exist in the namespace 'Microsoft' (are you missing an assembly reference?)

Answer 33 · 2021-06-27T16:30:07.000Z

Is there any movement on this?

In VS2019 unless I add an Assembly Reference to the .dll file in the .nuget folder, I get
Error	CS0234	The type or namespace name 'WSMan' does not exist in the namespace 'Microsoft' (are you missing an assembly reference?)

I ended up solving this problem using the GeneratePathProperty so that I could provide the hint path with $(PkgMicrosoft_WSMan_Management)

Answer 34 · 2021-07-04T08:34:17.000Z

vue package has the same issue, it's an old nuget package and the package author is unreachable. What do we do now? Please add this!

Answer 35 · 2021-07-12T16:09:40.000Z

Please fix this problem. Implicit nuget dependencies totally loose their main idea... When project depends on one package and it depends on another - this another is somehow added to the project but not processed properly

Answer 36 · 2021-08-04T17:21:56.000Z

@rrelyea (or anyone @msft, really) any ETA on this? it's open since 2017.

using GeneratePackagePath and copying the package files via a Target does not properly deal with transitive dependencies.

I need my \bin folder to look exactly like the \publish folder, without having to deal with dotnet publish and waiting for it to finish.

This goes in line with dotnet/core#5510, because waiting for publish to finish after each compilation would do great harm to the inner loop performance for developers on my platform.

Answer 37 · 2022-12-02T13:57:24.000Z

Has there been any kind of update on this issue?
This issue has been marked as open for 5+ years. I've the same problem as @Patrico12345.

Project X depends upon Package A --> The automatically generated nuspec of Package A lists depedency on Package B with exclude="Runtime,Compile,Build,Native,Analyzers,BuildTransitive", but no trace of contentFiles;
Package A has a dependency on Package B --> I added <IncludeAssets>contentFiles</IncludeAssets> to the PackageReference;
Package B is a simple package that only has contentFiles, specifically contentFiles/Any/Any/*

I can add a direct dependency but this becomes an issue when updating packages, as other people already pointed out.

Answer 38 · 2024-07-16T01:04:06.000Z

Well 7 years after this issue was created, it is still a problem.
I just have one project with one Nuget package and, as of July 2024, it is still not working at all.
The CopyLocalLockFileAssemblies is a "no go" as it copies everything it finds on the computer (or so), and IncludeAssets doesn't do anything.
Any news about which kind of gymnastic we must do to make it work ?
On another project (AspNet) I add problem with the wwwroot that was not copied.
Any alternative to MSBuild when building dotnet libraries ?
I totally lost confidence in it.

For those who can use this kind of solution, I copied the the nuget content into a Reference folder and have the following:

    <!-- Does not work anyway
    <PackageReference Include="LibGit2Sharp" Version="0.30.0" />
      <IncludeAssets>all</IncludeAssets>
      <PrivateAssets>all</PrivateAssets>
    </PackageReference> -->
    <Reference Include="LibGit2Sharp">
      <HintPath>..\Reference\Nuget\LibGit2Sharp.dll</HintPath>
      <Private>True</Private>
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </Reference>

I know it's uggly and pollutes the csproj, but ...

Answer 39 · 2024-07-16T02:55:18.000Z

look into <PackageReference Include="LibGit2Sharp" ExcludeAssets="all" PrivateAssets="all" GeneratePathProperty="true" /> and then <Reference Include="$(PkgLibGit2Sharp)\my.dll" />

If you can make a small standalkne sample project and describe exactly what behavior you want, I can make it work for you.

Look into https://msbuildlog.com and searchthe binlog viewer for $copy my.dll

Answer 40 · 2024-07-16T11:42:07.000Z

Here are the steps to reproduce:

dotnet new classlib
dotnet add package libGit2Sharp
dotnet build

To be sure the library is used I change class1 as:

public class Class1
{
    public static void Test()
    {
        Console.WriteLine("Valid {0}", LibGit2Sharp.Repository.IsValid(@"C:\"));
    }
}

The build does not complain but the debug directory only contains

GitLib.deps.json
GitLib.dll
GitLib.pdb

The project looks as it should (simple)

  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="libGit2Sharp" Version="0.30.0" />
  </ItemGroup>

The dotnet version is 8.0.301, MSBuild seems to be 4.8.9037.0.
Note:

If I add Exe and rename Test method as Main, libGit2Sharp is copied in the output directory.
If I restart from scratch and ask to create console instead of a classlib, libGit2Sharp is copied in the output directory.

Answer 41 · 2024-07-16T11:44:36.000Z

Can you please specify explicitly what you want to happen and what is not happening as you expect.

Answer 42 · 2024-07-16T11:50:57.000Z

LibGit2Sharp.dll should be copied to the output directory and it is not in the case of a class library.

Answer 43 · 2024-07-16T14:27:19.000Z

If you want libigt2sharp.dll and other dependencies to get copied to output for a library you need to set CopyLocalLockFileAssemblies. However, as you say, it will copy more than what you probably want.

To copy just that one exact dll you can add the following:

  <ItemGroup>
    <PackageReference Include="libgit2sharp" Version="0.30.0" GeneratePathProperty="true" />
    <None Include="$(Pkglibgit2sharp)\lib\net6.0\libgit2sharp.dll" CopyToOutputDirectory="PreserveNewest" />
  </ItemGroup>

Answer 44 · 2024-07-16T14:28:32.000Z

This is probably by design and it stems from libgit2sharp being a native wrapper. libgit2sharp is trying to avoid copying in native assets since a class library project’s output should never be executed/loaded directly. It wants to copy in its native assets when it is referenced from an executable project and to use that executable project’s target platforms to decide which platform binaries (e.g., x86, x64, arm64, etc.) should be copied in. The dependencies of your project will be copied when your project is referenced by another project which does have an executable output.

For your case, you might be able to simply say your project is a console application instead of a class library. Perhaps you could even indicate that your project is a test project which forces you to select the platform you are running on and should trigger copying of native assets. But then you have the penalty of either having to specify a concrete target platform or list of native platforms on your project which itself is pure .net and shouldn’t be limited to which platforms it supports.

Answer 45 · 2024-07-16T14:58:15.000Z

@binki from MSBuild's point of view libgit2sharp.dll is just a regular .dll, it doesn't have anything to do with it being a native wrapper. Class libraries don't set CopyLocalLockFileAssemblies, and that's why dlls from NuGet packages don't get copied to output.

Answer 46 · 2024-07-17T05:51:03.000Z

Even if it is by design, it is not consistent as it copies the package when building an exe, but not when building a library.
There is a problem in one case or the other and is not consistent from one project to another : in another library I use the markdig package (Markdown) and it is copied in the output without any specific configuration.
If it is by design, what are the Nuget packages for if they are not included in the output or if we need to specify what to copy for some of them ?
And then why the package is copied when requesting a exe without the CopyLocalLockFileAssemblies ?

IMHO one of the beauty versus the old project files of 10 or 20 years ago is the small size of today's csproj.

FI: Instead of what I explain above (Reference folder) I ended up 1) using the CopyLocalLockFileAssemblies, 2) specify a platform name and a target, and 3) add a step after the build to clean-up the output based on what the csproj contains (removing unwanted libraries).

Answer 47 · 2024-07-17T14:17:34.000Z

The design makes sense because you need the dependencies to run .exe files, but you never run dll files. This makes builds faster and saves disk space because you're not copying files to library output unnecessarily.

I personally don't like the solution of copying files and then deleting them (because it is slower and makes the build output mutable and imperative vs functional). However you're free to choose what works for you.

I'd also look into Chisel to carve out dependencies, it does it the right way (by not copying files in the first place):
https://github.com/0xced/Chisel

Answer 48 · 2024-07-17T16:54:57.000Z

It does not make sense as it is not consistent from one library to another, sometimes it does copy, sometimes it does not.
I will have a look at Chisel, but if it must be added to every project/library, it is overkill and it is the display that MSBuild simply cannot get the job done.

Answer 49 · 2024-07-17T19:12:41.000Z

If you make another standalone example of a library which copies a file against your expectations I'd be happy to take a look to understand why that happens.

Also I forgot to mention that once you have enabled CopyLocalLockFileAssemblies, you can then add ExcludeAssets="runtime" on any PackageReference to avoid copying files from that package to output.

Packages are not only needed to copy to output, another important role is passing references to the C# compiler so you can use types from that package in your code. So ExcludeAssets="runtime" will still pass the references to the compiler, but won't copy them to output. But ExcludeAssets="compile" will do the opposite.

I agree MSBuild and NuGet are confusing and complicated, however they've evolved into a system that you can reason about and learn how to work with, and there are tools (such as the binlog viewer) to understand how the system works and get the behavior that you need.

I gave you three options which give you full control:

manually copy the file(s) you need using the mechanism I described
if that's not good, you can enable CopyLocal to have the entire transitive closure copied
if that's not good you can exclude some dlls from CopyLocal using Chisel or a custom target that removes items from a certain item group. It is hacky but it gets the job done.

When you say "MSBuild simply cannot get the job done" I disagree. I would rather phrase it as "MSBuild cannot get the job done simply", and that is only true sometimes. But if you invest enough time in learning, you will be able to express what you want, and I'm here to help.

Answer 50 · 2024-07-17T21:14:23.000Z

It does not make sense as it is not consistent from one library to another, sometimes it does copy, sometimes it does not.

Also keep in mind that some packages ship MSBuild props/targets which do their own custom things, and do not follow NuGet & MSBuild/.NET SDK's conventions. Especially packages that want to support packages.config projects, since most of NuGet's conventions only started with PackageReference in 2016.

Answer 51 · 2024-08-06T20:35:21.000Z

@KirillOsenkov I agree, indeed with your way of saying it "MSBuild cannot get the job done simply".
The frustration came from the fact that the same day I had two cases were MSBuild reacted in opposite way and when I was able to copy the dependencies (giving setup I otherwise do not need), all runtimes were copied (osx ...) without respect of what I asked (Linux and Windows).