{{ message }}

# Feature : Allow project reference DLLs to be added to the parent nupkg for pack target like IncludeReferencedProjects in nuget.exe #3891

Open
opened this issue Nov 8, 2016 · 242 comments
Open

# Feature : Allow project reference DLLs to be added to the parent nupkg for pack target like IncludeReferencedProjects in nuget.exe#3891

opened this issue Nov 8, 2016 · 242 comments
Assignees
Labels

## Steps

1. dotnet new --type lib two .csproj class libraries: projectA and projectB.
2. Change <TargetFramework> to <TargetFrameworks> if you don't have #3865.
3. Make projectA have a ProjectReference to projectB.
4. Add <Type>project</Type> to the <ProjectReference>.
5. dotnet pack projectA
6. Open the resulting .nupkg's lib folder

## Expected

projectB.dll should be in the .nupkg along with projectA.dll

## Actual

projectB is still a package reference, not a DLL included in the package.

## Environment

Tried latest dev's pack target.

dotnet --info

.NET Command Line Tools (1.0.0-preview3-004056)

Product Information:
Version:            1.0.0-preview3-004056
Commit SHA-1 hash:  ccc4968bc3

Runtime Environment:
OS Name:     Windows
OS Version:  10.0.14393
OS Platform: Windows
RID:         win10-x64

UPDATE: Please see workaround posted as comment to see how to add ProjectReferences as DLLs in the package dynamically.

added this to the 4.0 RC2 milestone Nov 8, 2016

### rrelyea commented Nov 8, 2016

 Please check spec on wiki for planned behavior

### joelverhagen commented Nov 8, 2016

 This doesn't work: false The output .nuspec still has projectB as a package reference and only one file: projectA.dll under lib.

### emgarten commented Nov 8, 2016

 This is a non-trivial feature that hasn't been implemented for RC yet. Supporting this will require potentially walking the entire project closure to determine all projects that need to be merged into the package, or reading the assets file and matching the project closure with both the project reference flags and the pack flags found in the project (since it can be set either way). This is also impacted by build outputs not flowing transitively to parent projects yet.

### joelverhagen commented Nov 10, 2016 • edited

 Plan of action: Build out some automated tests for pack task to cover basic scenarios and detect regression. Add the original PackageSpec to the lock/assets file. Add any missing properties to the assets file pack needs (e.g. path to child project output assemblies). Update restore (no, not pack) to collapse project references when is true. Move the PackTask away from looking at child projects. Look at restore's assets file instead. This has repercussions on: Restore: basically all of the data pack needs should be collected by restore an put in the assets file. Restore should be the only guy doing a walk. Project/Package duality: what if a child project .csproj has a . How is this collapsed? What collapsing occurs? Certainly build artifacts and ... what about ?
self-assigned this Nov 14, 2016
added the label Nov 14, 2016
mentioned this issue Nov 16, 2016
modified the milestones: 4.0 RC2, 4.0 RC3 Nov 29, 2016
removed their assignment Dec 7, 2016

### joelverhagen commented Dec 7, 2016

 @rohit21agrawal, I partially got through consuming the assets file from in the pack task: https://github.com/joelverhagen/NuGet.Client/tree/jver/3891 This also has some progress on getting the output DLLs of child projects (using @(ReferenceCopyLocalPaths) MSBuild items). This branch is pretty rough so let me know if I can clarify.
mentioned this issue Dec 9, 2016

### rohit21agrawal commented Dec 9, 2016

 As per @rrelyea : #3893 (comment) "We don't plan to enable this in dotnet pack / msbuild /t:pack in 4.0 timeframe. We'll listen to customer feedback and consider in the future."
mentioned this issue Dec 15, 2016

### rohit21agrawal commented Dec 15, 2016

 moving to future as this is post-rtm work.
modified the milestones: 4.0 RTM, 4.0 RC3 Dec 15, 2016

### gulbanana commented Dec 15, 2016

 building a nupkg from multiple projects seems like a major feature to be missing :/

### rohit21agrawal commented Dec 15, 2016

 @gulbanana thanks for the feedback. this is something that is not planned for the 4.0 RTM release, but this is something we will definitely address in a future release.

### bbowman commented Dec 15, 2016

 @kzu 's nugetizer 3000 does this?
modified the milestones: Future-1, 4.0 RTM Dec 30, 2016
modified the milestones: 4.0.1, Future-1 Feb 10, 2017
mentioned this issue Jun 8, 2017

### StingyJack commented Jan 7, 2021

 Everyone is coming up with elaborate ways to avoid having to create a 15-20 line XML file (nuspec) that will do exactly as you instruct it to do.

### matthewjones555 commented Jan 7, 2021

 What everyone wants is a tidy solution where they only have to specify things in one place. The problem with going back to nuspec files is they're a second source of truth, and can diverge from how things are set up in your projects. It's not a case of avoiding having an extra 20 line file, it's a case of avoiding having a file that can become stale with no easy way of automatically detecting the problem. The nuget integration into msbuild is great, but it has some rather large holes, for what seems to be fundamental functionality. When you run into these problems, it makes the integration seem incomplete.

### roofiq commented Jan 7, 2021

 @StingyJack true that. I was also searching a lot and I find creating nuspec the easiest way. Just maybe one question. Let's say we have project with quite a lot dependencies. After build, all the DLLs and files are being created in obj and bin files. What I have found, that the easiest solution to create nuget is to just add this element, that would simply copy folder, that is normally being published as artifact. With this one, we can replace using build artifacts with nugets (in example of azure devops). Any comments on doing it this way? What can go wrong? :)

### StingyJack commented Jan 7, 2021

 @roofiq - the obj folder is for temporary compilation and other transient stuffs, so its a bad idea to try to use anything from an obj folder. The bin\Release folder is where you want to get the files if you are making a normal nuget. Yer also missing a target value and are probably pulling in way too many files. I'll usually use file elements like this so I can get the MyProject.DLL, MyProject.PDB, and MyProject.XML all packed up to support some debugging of the package and intellisense for VS. (make sure to set either "Full" or "Embedded" PDB for the Release configuration.) With this one, we can replace using build artifacts with nugets (in example of azure devops). Any comments on doing it this way? What can go wrong? :) You are making it hard for yourself in a few ways. You cant deploy a nuget package from a release pipeline with the easy to use, built in tooling. Also programs are not packages. Except if you are actually making Chocolatey packages (that use the nupkg format but are still not nuget packages) and using chocolatey to install apps. I dont get the appeal of using a nuget package format and all the rules around packing it instead of an artifact (a plain zip of the published projects from the build). You probably also lose all of the artifact retention stuff that happens with a release pipeline by not using artifacts.

### roofiq commented Jan 7, 2021

 @StingyJack - thanks for the long answer 👍 I know, that the final compiled files are in /bin folder. But I have investigated the actual SiteRoot folder and it was 1:1 as the one in /obj (.net framework 4.8 app). So I have decided to use this one. It actually worked. You are making it hard for yourself in a few ways. You cant deploy a nuget package from a release pipeline with the easy to use, built in tooling. Basically the point of my answer, was that we want to switch from using build artifacts to artifact feeds. So my task was to come up how we can easily pack project, that has mutliple dependencies. So to sum up, if we would simply point bin/Release to be copied to Target directory specified in Nuspec file, it will be done in good practise?

### StingyJack commented Jan 9, 2021

 So to sum up, if we would simply point bin/Release to be copied to Target directory specified in Nuspec file, it will be done in good practise? @roofiq - Yes, but it is going to depend on if you are packaging assemblies or programs in this way. When you refer to build artifacts, those are usually going to be programs (Web Apps, Windows desktop apps, Web Sites, WPF, AWS Lambda, Azure Function/webjob, etc.) and sometimes other things like config files. Making these into nuget packages adds complexity because you go from a simple zipped build artifact that can be unzipped and xcopied for deploying to a nupkg (also zipped, but a container with a very specific format that you need to try to make your application fit into and then extract back out of). I'm thinking you may mean programs because the path that you were getting the files from looks like where Published apps go when you dont specify a publish path. If you had been putting your dll's by themselves into build artifacts than the answer to your question is definitely Yes, point to the bin\Release and pack/push. Just dont forget to generate and pack PDB's and XML comment files in there too (these are not required but this is far easier to do than to setup and configure symbol servers, add symbol publishing to a pipeline, then update every dev;'s visual studio instance to use the symbol server). this being named your own Sdk @AraHaan - I'm actually at a loss for understanding what you mean by "SDK", an example may help, but please open a different issue for what you need cos it doesnt seem aligned with this topic. Feel free to tag me. The large packages you see are actually metapackages and dont contain files.

### rtaylor72 commented Jan 14, 2021

 Sad we are now on .Net 5 and this is still an issue... I do not see any progress on this...

### AraHaan commented Jan 15, 2021

 I found something that works however it would need some edits to work for satellite assemblies too. https://github.com/Elskom/Sdk/ Take a look at the dummy nuspec with an csproj just to make it all work with dotnet build / dotnet pack.

### StingyJack commented Jan 17, 2021

 @AraHaan - those nuspec files are really, really over-worded. Rather than tangent this thread further I'm going to open an issue on the repo you linked to share some ideas with you that may reduce your maintenance pains. I'll link it here for anyone who wants to follow.
mentioned this issue Jan 17, 2021