-
Notifications
You must be signed in to change notification settings - Fork 250
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PackageReference is missing copy files to output feature #4837
Comments
NuGET is reading the csproj file when I run Let me clarify, when I run I think NuGet is not in that process. |
The MSBuild engine runs logic from a variety of sources when you run |
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. |
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 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. |
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.
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?
|
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! |
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 |
The targets/props for modifying build items coming from packages should be added to the samples and documented. |
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. |
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. |
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. |
@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. |
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 I think this is related to #4488 🤔 |
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. |
I've just found this property that is working for me:
And it seems it copies everything, including framework references: dotnet/sdk#933 |
Any ideas how to work with tools dir inside of PackageReference? Tried to use |
How is this supposed to work for projects using PackageReference for NuGet packages that contain a dependency on another NuGet package that has "contentFiles"? 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. |
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. |
Observing the exact same thing as @pyrostew and @Patrico12345. 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 ! |
Is there any movement on this? In VS2019 unless I add an Assembly Reference to the .dll file in the .nuget folder, I get
|
I ended up solving this problem using the GeneratePathProperty so that I could provide the hint path with |
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! |
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 |
@rrelyea (or anyone @msft, really) any ETA on this? it's open since 2017. using I need my 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. |
Has there been any kind of update on this issue? Project X depends upon Package A --> The automatically generated nuspec of Package A lists depedency on Package B with I can add a direct dependency but this becomes an issue when updating packages, as other people already pointed out. |
Well 7 years after this issue was created, it is still a problem. 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 ... |
look into 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 |
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.
|
Can you please specify explicitly what you want to happen and what is not happening as you expect. |
LibGit2Sharp.dll should be copied to the output directory and it is not in the case of a class library. |
If you want libigt2sharp.dll and other dependencies to get copied to output for a library you need to set To copy just that one exact dll you can add the following:
|
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. |
@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. |
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. 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). |
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): |
It does not make sense as it is not consistent from one library to another, sometimes it does copy, sometimes it does not. |
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 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:
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. |
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. |
@KirillOsenkov I agree, indeed with your way of saying it "MSBuild cannot get the job done simply". |
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
: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
Note that the PhantomJS has folder called "tools" inside, that needs to be copied to output directory to make it usable in the app.
The text was updated successfully, but these errors were encountered: