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
"donet pack" is not including project references #6688
Comments
@ivanz you need to |
@blackdwarf Are you saying that I need to publish a nuget package of my dependency and have a dependency on it? (in my case that's exactly what I am trying to avoid when porting a library in order to retain the distribution as is prior to dotnet/.NET Standard/.Net Core) |
@ivanz you keep the dependency as a P2P reference, but you produce a nupkg of both your library and its consumer. |
@blackdwarf That doesn't work. I end up with a |
I am having the same issue. I am porting a common library to .net core and it consists of the main DLL class library and 2 supporting DLLs. I build the package with nuget and the nupkg file contained all 3 DLLs. The same behavior is not happening with dotnet pack. According to the documentation if you specify the dependencies as project references they will be included. This is not happening. Can you reopen the issue and investigate? |
The same for me. Documentation says that it is possible. So why closing this issue? |
In case anyone else is having the same issue, you must also specify "type": "build" on each dependency. It is stated in the docs, for some reason though I thought "default" means "build" (it clearly wasn't "platform" - hence I thought "default" is a placeholder) {
"version": "1.0.0-*",
"dependencies": {
"ProjectA": {
"target": "project",
"type": "build"
}
}
} |
I'm also running into this same problem, and following the docs that @UizzUW linked to still don't bundle the dependency DLLs into the nupkg |
@UizzUW, I did it and still without success. |
I had read the docs as well and setup the project target and type as shown above. Doesn't work... |
Without the ability to package and publish libraries, it is hard to move into production with dot net core |
.NET Standard linking seems to be a bit different than old style .NET Framework linking. From what I've gathered, this is in order to make stripping more modular and only include the bits that you actually need in the final build (and not the full framework). Here's the scenario I'm currently struggling with and what I figured out so far :
The tricky thing here is that if I package A and publish to NuGet, What's even more, in both cases ( You can find the actual project I am working on here - look through the project.jsons and see if you can find anything that would be of help. Choose either Common + Core + Core.Sample or Common + Client + Client.Sample in order to get the same dependency tree I am talking about (.Sample projects are supposed to be projects that would consume the actual NuGet library) I think this area needs lots more in-depth documentation, then again they might just be waiting for the right moment since they're going to get rid of project.json and go back to .csproj configs soon anyway. |
I have a work around
The resulting nupkg file contains the main dll, the 3 supporting libraries and the pdbs. I tried to replace "Release" with |
The same for me here! Specifying "type": "build" results in all the needed DLLs being written out to the /bin/Release// folder, but they are not included in the resulting .nupkg. @blackdwarf |
@christianhuening the documentation linked states that issuing |
I have an issue tracking the documentation update and I should have a PR out in a moment: dotnet/docs#1070 |
How about How do I also include the dependency in a msbuild environment? Thanks! |
@radu-matei that is a whole different beast of an issue. There are (or were) essentially two different build systems after the release of .NET Core and .NET Standard. The old one, MSBuild, still used for .NET Framework projects (.csproj files), and the new one exposed by the "dotnet" CLI, which knows how to handle project.json files. The problem is the dotnet CLI does not know how to handle .csproj files, so you cannot reference a .csproj from a project.json or .xproj. The solution, while I haven't tested it myself, should be to install VS2017 and open your project.json-based projects with it. The dotnet team gave up on project.json and have switched back to .csproj files even for .NET Core / Standard in order to support the very issue you have right now. This is why VS2017 comes with new tooling which should be able to convert all your project.json based projects to the new, msbuild based projects. You should be able to reference other .csproj files after that. |
@UizzUW - my project is VS17 based with I built a nuget package using The concrete questions (which I should have made clear in the first place) are:
Thanks, |
I feel I have the same issue. I have a Command line executable project. When I use either However, when I use VS 2017 and right-click on my project and select Publish, then selecting the default FolderProfile, all contents (including my config file) and all dependencies required to run the project are put in a folder. I need the complete outputs of this publish folder in a nuget package to be able to deploy a runnable version of my tool. As a workaround I could create a .nuspec and point to that folder to create a Octo-deployable runnable version of my tool, however on my build server I have no VS installed (just the .net core sdk, the VS 2017 build tools and some target packs), and I see no way how to trigger the pubxml publish process on the build server. So the questions boil down to these:
|
@gingters maybe this will work? <ItemGroup>
<None Include="config.json" Pack="true" PackagePath="config.json">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</None>
</ItemGroup> |
Currently we are having the same problem when migrating projects from old .csproj and .nuspec to new .csproj format. How to reproduce (using VS 2017):
Expected result:
Actual result:
Side note: I have created a new ticket for this, to make it clear that it is strictly related to new .csproj based workflow. |
I'm having the same issue with new csproj file format |
So I see this is successfully being ignored. Good job... |
For anyone that's interested, I have a sample up at https://github.com/dasMulli/nuget-include-p2p-example to show how to include project-to-project references in NuGet packages that work with A csproj-integrated workaround would be to use a custom target to create |
@dasMulli So if understand this correctly, the only "magic" is happening in LibA.csproj where you specify nuspec file and properties so that dotnet pack can pick those up and use them. Am I correct? Otherwise a nice workaround. Been thinking about using manual nuspec file either way. Thank you. |
Why I can't decide myself, if I need to publish each project of a solution as separate nuget package or not? Projects might be used to enforce clear design for big solutions, although, they might not make sense as separate packages. .NET Core, it becomes a mess, instead of a progress... |
I'm having to work around this it by using oldschool |
There actually is a ""simpler"" solution at the moment, involving adding and hooking up a custom target (tested on latest released bits): <Project>
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
<TargetsForTfmSpecificBuildOutput>$(TargetsForTfmSpecificBuildOutput);IncludeP2PAssets</TargetsForTfmSpecificBuildOutput>
</PropertyGroup>
<ItemGroup>
<ProjectReference Include="..\testprivatelib\testprivatelib.csproj" PrivateAssets="All" />
</ItemGroup>
<Target Name="IncludeP2PAssets">
<ItemGroup>
<BuildOutputInPackage Include="$(OutputPath)\testprivatelib.dll" />
</ItemGroup>
</Target>
</Project> |
i'll let @rrelyea comment on the timeline of this fix. Until then, we recommend the following workaround as suggested by @dasMulli : https://github.com/dotnet/cli/issues/3959#issuecomment-333318028 Currently we are tracking this issue on our side here: NuGet/Home#3891 . |
@rohit21agrawal while that does indeed work, in terms of packaging - it still leaves the dependency listed so you cannot install the package elsewhere. A proper fix is still desperately needed |
You can add PrivateAssets=all on your project reference which will not have any other functional impact except suppressing the dependency in the generated package |
and please don’t get me wrong, I am not denying that a fix is needed, but I just want to make sure that the workaround works as expected |
why is this closed? this is a blocking issue for large projects, it gets very confusing to manage dependencies. |
I've written an alternative solution. It will automatically grab project outputs and dependencies (so you don't have to declare them in the packaging project). It also includes an option to exclude the packaging project's output. Usage
NotesI haven't tested if this includes content and framework assembly references correctly. Include sources doesn't appear to be working correctly (source files are packed with incorrect-looking paths) but as I don't use the feature myself, I didn't verify if it has an actual impact. |
We were surprised by this behavior. Can this issue be reopened and fixed? |
What a mess... |
This is closed here because the fix is being tracked by NuGet here: NuGet/Home#3891. |
This is a huge mess - why is this not fixed? |
Probably because the NuGet team are a bunch of drunken monkeys. |
bump |
why is this issue closed? is there an easy way to pack with multiple project references (which might have other project references). Something |
3.5 years later, still not sorted. What a mess. |
It isn't closed. It is just tracked elsewhere: NuGet/Home#3891 |
So it is closed... |
Theoretically, you are correct :) But i just wanted to point out that the issue is still being tracked on another issue. |
It is simple to solve. You just add your project as Since during Hope it helps. |
This doesn't include the referenced projects as dlls in the project being packed. |
You don't have to include it since you can publish your packages separately. But if you needed you can pack dependencies into a single Nuget package as well. I have answered this here. |
All we want is a simple pack command that adds all dlls to the package when used. See NuGet/Home#3891. |
Follow the link to stackowerflow where I explained how to do it... |
For anyone else struggling with this, I found a nuget package that is very similar to the solution mentioned by @dasMulli, but takes care of copying and resolving the dll paths for you with any reference marked as https://www.nuget.org/packages/Teronis.MSBuild.Packaging.ProjectBuildInPackage/ |
So I need a nuget package to pack my nuget package? What a mess. |
Steps to reproduce
Expected behavior
DependencyProject.dll
should be included in the.nupkg
for thenet46
framework:Actual behavior
DependencyProject.dll
is not included at all in the.nupkg
Environment data
dotnet --info
output:The text was updated successfully, but these errors were encountered: