Should dependent assemblies less than or equal to projet's target be added when package is installed?

[sam-wheat]

PM> $host

Name : Package Manager Host
Version : 4.9.3.5777
InstanceId : d190a8ae-335c-4f75-9f14-09ac364bee12
UI : System.Management.Automation.Internal.Host.InternalHostUserInterface
CurrentCulture : en-US
CurrentUICulture : en-US

NuGet Version: 4.9.2.5706
usage: NuGet [args] [options]
Type 'NuGet help ' for help on a specific command.

This document says:

If a match is not found, NuGet copies the assembly for the highest version that is less than or equal to the project's target framework, if available.

Question: If a match is not found will NuGet also copy dependent assemblies for less-than-or-equal versions of project's target framework?

Example Project configuration:
MyApp.exe - net472
depends on
MyDll.dll - net472
depends on
OtherDll.dll - net47 or greater

nuspec:

<files>
	<file src="bin\$configuration$\*.dll" target="lib\net47" /> 
</files>

Build command:
NuGet.exe pack MyDll.csproj -Outputdirectory bin\release -properties Configuration=Release

This is what is created in the .nupkg:

\lib\net47
	OtherDll.dll
\lib\net472
	MyDll.dll

When I add the .nupkg via Visual Studio to MyApp.exe project only MyDll.dll is added - OtherDll.dll is not added.
My question stated differently is: Should nuget install BOTH .dll files? Each one has an assembly that is less than or equal to the project's target framework.

See also

#7316

[heng-liu]

Thank you for your feedback!
Can you please provide more details so that we can repro? Thanks!

[sam-wheat]

What info do you need?

[heng-liu]

Hi, if what you want is to add OtherDll.dll in MyApp.exe project(targeting net472), you may add "-IncludeReferencedProjects" at the end of original nuget pack command. You don't have to edit the .nuspec file.

[sam-wheat]

@heng-liu

Hi, OtherDll is included in the nuget package as described in the post above.

It is not added as a reference to MyApp.exe which of course causes it to break. Is that the expected behavior?

[heng-liu]

Thank you for your reply!
Yes, it's the expected behavior as you can also pack MyDll.dll and OtherDll.dll into separate packages if you don't specify "-IncludeReferencedProjects".

[leaderanalytics]

@heng-liu I'm sorry you closed this ticket as I don't think the issue is resolved.

Please understand that my question is not related to "-IncludeReferencedProjects". In my case OtherDll.dll is not a project - it is a third party binary that is reference by my project.

What I understand your reply to mean is that:

After I specify explicitly that dependencies that are to be included in my nuget:

<files>
<file src="bin\$configuration$\*.dll" target="lib\net47" /> 
</files>

and after I confirm that the dependencies are in fact added to my .nupkg:

\lib\net47
    OtherDll.dll
\lib\net472
    MyDll.dll

Than, at the time I install my nuget on the consuming application, the files I have explicitly specified as dependencies may be ignored by the installer for no reason?

I do not understand under what circumstances nuget SHOULD ignore a dependency and knowingly cause a nuget installation to fail. Why would I include a .dll in my .nupkg if I did not intended for that .dll to be referenced as part of the installation?

In this specific case being discussed in this ticket where the .dll is actually included in the .nupkg, what is the reason that that the installer failed to add it to the consuming application?

Thank you!

[heng-liu]

Thank you for your feedback!
In this case, editing nuspec file is an unnecessary step. So you only need to build then run the pack command. If you would like to pack the two dlls into separate packages, then don't specify the "-IncludeReferencedProjects". If you would like to pack into one package, then specify the "-IncludeReferencedProjects".
Sorry for closing the issue when you think it's unresolved. If I misunderstand your meaning and you would like to discuss about it more, we can reopen it anytime. Thanks!

[leaderanalytics]

@heng-liu Hi heng-lu, please reopen this ticket because I do not think this topic is resolved. Perhaps I'm not doing a good job of stating my questions or perhaps I don't understand your reply.

Here again are my questions:

Question 1:
Under what circumstances nuget SHOULD ignore a dependency and knowingly cause a nuget installation to fail. The logic behind the question is: Why would I include a .dll in my .nupkg if I did not intended for that .dll to be referenced as part of the installation?

Question 2:
In this specific case being discussed in this ticket where the .dll is actually included in the .nupkg, what is the reason that that the installer failed to add it to the consuming application?

I don't understand your reply about editing the nuspec file - did you intend that as a reply to a different post?

[zivkan]

Just stumbled across this issue. NuGet first selects a TFM (target framework moniker) for asset selection, before selecting assets. So, which dlls, or how many dlls exist in each lib\* directory is not relevant. In @sam-wheat's example, the package contains lib\net47\ and \lib\net472\ directories, telling NuGet that it supports both (or either, depending on how you consider it) net47 and/or net472. If the project using the package supports net472 or higher, it will only select net472 assets, and none of the net47 assets will be selected.

Therefore in the scenario where you bundle a dependent assembly in your package with your assembly, it needs to be in the same TFM directory as your assembly, even if it was compiled against a lower TFM. An alternative to that is to put the other dll in its own package and make it a dependency of your package. I consider this good practice anyway since other packages may want to use that other dll and if it's always used a package there are fewer problems than if multiple packages have the same assembly name, causing the build system to choose which one to use and potentially have problems.

I hope this helps.

[zivkan]

@leaderanalytics To answer your questions:

Under what circumstances nuget SHOULD ignore a dependency and knowingly cause a nuget installation to fail.

NuGet is a package manager, not an assembly manager. NuGet don't examine assemblies and what assembly references each assembly has and ensure that they will work at compile or runtime. That's the package author's responsibility. NuGet does check NuGet dependencies, which are different to assembly "dependencies".

In the original question there was no nuget dependency, therefore the idea of ignoring a dependency is out of context.

Why would I include a .dll in my .nupkg if I did not intended for that .dll to be referenced as part of the installation?

The package in the original question is instructing NuGet to inform MSBuild that lib\net472\MyDll.dll exists when the package is installed in a project that is compatible with net472. Alternatively if the project using the package is not compatible with net472, but is compatible with net47, then tell MSBuild that lib\net47\Other.dll exists. If the project is not compatible with either net47 or net472, then installation (in packages.config world) or restore (in PackageReference world) will fail as the project is not compatible with any assets that the package provides.

In this specific case being discussed in this ticket where the .dll is actually included in the .nupkg, what is the reason that that the installer failed to add it to the consuming application?

The package says "I have this set of assets for net47 projects, and these other set of assets for net472 projects". The idea is that if you have a library that can provide improved or additional functionality in newer versions of the .NET Framework, then NuGet selects those assets. But if a project using the package targets an older .NET Framework, NuGet selects the assets that allows the project to use the package's reduced functionality.

Assuming the user-scenario for this question is that you want to package an assembly that has a dependency on another assembly, there are two options:

1. package each assembly in its own package, and use NuGet dependencies.
2. package both assemblies in a single package, but both assemblies need to be in the same lib\tfm directory, and the tfm name must be the highest (least compatible) tfm of the two assemblies.

If my two comments on this issue don't help, please explain the problem you are trying to solve. We might be able to find a solution more quickly than discussing specific technical implementation details.

If my comments helped you understand how NuGet works, and you still find the documentation confusing, I would appreciate feedback on what is confusing. If you have suggestions how it could be improved, that would be better.

[leaderanalytics]

@zivkan Please reopen until I respond.

[leaderanalytics]

@zivkan

The package in the original question is instructing NuGet to inform MSBuild that lib\net472\MyDll.dll exists when the package is installed in a project that is compatible with net472. Alternatively if the project using the package is not compatible with net472, but is compatible with net47, then tell MSBuild that lib\net47\Other.dll exists. If the project is not compatible with either net47 or net472, then installation (in packages.config world) or restore (in PackageReference world) will fail as the project is not compatible with any assets that the package provides.

This is not my intent at all! My package contains exactly one set of dependencies and those dependencies should be installed for all versions of the framework greater than or equal to .net 4.7. The preceding is my intent - If my package is incorrect please tell me how to fix it. I am not asking nuget to manage or examine anything. I am giving it a single, explicit list of files to install when the package is installed.

The package says "I have this set of assets for net47 projects, and these other set of assets for net472 projects".

Again - this is NOT my intent. I have only one set of dependencies. My intent is to tell Nuget: "Create a package that will work with .net 4.7 or above. When the user installs the package ADD A REFERENCE TO THESE TWO ASSEMBLIES. As is demonstrated with the attached projects Nuget is only adding a reference to ONE of the assemblies. Why is that happening?

Please see attached projects which reproduce the behavior described in this ticket.

MyDll.zip
MyDllHost.zip

[zivkan]

If you open MyDll.csproj in a text editor, you'll see that it contains <TargetFrameworkVersion>v4.7.2</TargetFrameworkVersion>. Since you said you intend for your package to support net47 and up, it's invalid for you to pack an assembly compiled against net472 in the lib\net47 directory, since 4.7.2 is a higher version than 4.7.

So, you need to go to project properties and change your project to target ".NET Framework, v4.7" instead. Since you're already packing WpfAnimatedGif.dll in the lib\net47 directory, then both dlls will be in the same directory. This tells NuGet that your package only supports net47, and when it's used in a package both dlls in the lib\net47 directory will be referenced by the project, as is your intent.

In short, when you want to package multiple dlls in a single package and have all of them referenced by a project using the package, all the dlls must exist in the same lib\<TFM> directory.

[zivkan]

I didn't look very carefully at MyDllHost.zip before writing my previous comment. What's happening is when you pack a project, NuGet will find the project's output assembly, determine the project's TFM, and automatically add the output assembly to the appropriate TFM folder, which is lib\net472, since that's what your project targets. Then, your nuspec file includes bin\$configuration$\*.dll and puts them in lib\net47.

Now, the main problem with this is as I mentioned in my previous comment, your dll was compiled against net472, so net47 and net471 projects using your project should fail to compile and/or fail to run because your assembly, despite being in the lib\net47 directory, actually requires net472.

However, net47 and net471 projects should correctly reference both dlls when referencing your package. Since the project assembly was automatically added to lib\net472, net4722 and higher projects using your package will only reference that assembly, but since there is no WpfAnimatedGif.dll in lib\net472, it won't be referenced.

When you want projects using your package to reference all the dlls in the appropriate lib\<tfm> directory, it's not necessary to include the <references> section. <references> is intended to limit the assemblies that are referenced to a subset of what's available in lib\<tfm>, so the other dlls won't be used for intellisense or be available to compile against. But all the lib\<tfm> assemblies will still be there at runtime. However, be aware that the <references> section in the nuspec only works correctly for projects using packages.config (PC). Projects using PackageReference (PR) need to use the ref/<tfm> directories. To support both PC and PR projects, you need both.

[leaderanalytics]

NuGet don't examine assemblies and what assembly references each assembly has and ensure that they will work at compile or runtime.

How does nuspec know to create net47 and net472 folders? In my nuspec I am simply telling it to create a package that targets net47.

it's invalid for you to pack an assembly compiled against net472 in the lib\net47 directory, since 4.7.2 is a higher version than 4.7.

If that is the case nuget should generate an error when the package is created. I am not choosing what .dlls wind up in which directories. Nuget is doing that.

It is interesting to note that MyDll.dll winds up in the net47 directory even though MyDll.dll is invalid for 4.7. Rather than create an invalid set of files to install I would expect nuget to not create a net47 directory at all.

However, net47 and net471 projects should correctly reference both dlls when referencing your package.

I don't understand this based on your previous comments. If MyDll.dll targets 4.7.2 it should NOT be added as reference for a net47/net471 project. Is that correct?

but since there is no WpfAnimatedGif.dll in lib\net472, it won't be referenced.

In the net472 directory WpfAnimatedGif.dll IS MISSING. Why does nuget not copy it there?? Net472 is in fact a VALID target framework. THIS IS THE PROBLEM. MyDll nuget package should install correctly on net472 but it does not.

I think if nuget is smart enough to determine the minimum framework version my pkg can target it should be smart enough to create folders for those frameworks only. In this specific example net47 should not be created and net472 should be created correctly.

[zivkan]

How does nuspec know to create net47 and net472 folders?

The project is net472, hence the project dll in the lib\net472 directory. The nuspec explicitly tells NuGet to copy bin\$configuration$\*.dll to lib\net47.

In order to minimise further miscommunications (my personality is that I'm a very detailed oriented person, but this can lead to information overload, particularly when I'm not clear about the context of the information I'm giving), here are two ways you can solve the problem:

1. Change MyDll.csproj to target .NET Framework 4.7 instead of .NET Framework 4.7.2.

2. Change the nuspec so that the file target is lib\net472 instead of lib\net47.

The key is that the file target in the nuspec needs to match the project's target framework version exactly.

Either of these solutions should result in your package working as you intend.

[zivkan]

I forgot to mention that we're currently considering adding some additional pack validation, so thanks to your feedback, I've added checking lib\<tfm>\*.dll compatability as a possible addition.

[leaderanalytics]

The key is that the file target in the nuspec needs to match the project's target framework version exactly.

Thanks for that answer. That does fix the problem in this case.

To close out this issue I think you should answer my original question directly. Key words are "if a match is not found". Adding a compatibility check is good (I suppose) but will it solve the entire problem? As you said:

The nuspec explicitly tells NuGet to copy bin$configuration$*.dll to lib\net47.

So if you do a compatibility check nuget will see that MyDll.dll is not compatible with net47 so a package will not be create for it. That will solve one problem.

The second issue is not copying other required dlls:

In the net472 directory WpfAnimatedGif.dll IS MISSING. Why does nuget not copy it there?? Net472 is in fact a VALID target framework. THIS IS THE PROBLEM. MyDll nuget package should install correctly on net472 but it does not.

The above is the issue I am asking about. Will the above issue be fixed with a compatibility check?

Thanks again for your help. You have answered many questions - except the ones I keep asking! :)