NuGet does not treat '*.resources.dll' as an assembly reference

Nov 23, 2011 at 1:46 PM

This post is simply intended to turn up in someone's future search to help diagnose an 'issue' caused by an undocumented feature of NuGet.

We have a set of common libraries that we used across our apps and one of the dlls was called "Common.Resources.dll". Note that this isn't a localization assembly (which get named 'MyAssembly.resources.dll). We packaged this up and the .nuspec inside the package had the requisite <file src="lib\net35\Common.Resources.dll" target="lib\net35\Common.Resources.dll" />. However, when installing the package, we noticed that a reference to this dll was never added.

It turns out the NuGet deliberately does not add references to any dlls that end with '.resources.dll', presumably on the assumption that it's a localization assembly. On the whole this is a sensible thing, but unfortunately in this case it silently excluded our assembly. The real cause of the problem here was our dodgy assembly name, but it would be nice if this particular feature was documented (I had to debug this to discover the issue).

I hope this helps someone in future!

Nov 23, 2011 at 3:08 PM

Thanks for sharing your finding. Yes, we didn't do a good job of documenting all of our features, especially corner cases like this.

Btw, did you know that you can contribute to writing our docs site too? If you are keen to adding this information to the docs site, here's the page that can get you started

Oct 8, 2012 at 4:31 PM

Coming from a point of ignorance here, but how would you then suggest we deliver localised resources to consumers of our NuGet packages?

Is there a best practise or specific feature of NuGet for that?

Oct 8, 2012 at 4:46 PM
Edited Oct 8, 2012 at 4:46 PM

We have added support for localized packages since NuGet 1.8. See the release notes here for more information:

Oct 9, 2012 at 6:49 PM

I see you've added support to handle localized nuget packages (as seperate packages)... In my particular case, I'm trying to use my nuget package as a library of localized strings that are common to all my applications like error messages, validation, "yes", "no",etc.... 

I was able to use this (  in order to successfully pack my primary assembly along with it's satellite/localized assemblies... they show up in the lib folder as expected. However, when i install the nuget package into a project, it adds it to the packages.config without adding anything to the project's references... Please help me address this issue.

Oct 9, 2012 at 7:13 PM

Have you tried to create a localized package as described in the release notes that I shared?

The idea is that you create a separate package to contain your satellite assemblies, and this package will depend on your primary package which contains your primary assembly. When NuGet installs your satellite packages, it copies the satellite assemblies to the same location as the primary assembly. It does not add the satellite assemblies to the project References node. That's how .NET localization mechanism works.

Oct 9, 2012 at 8:18 PM

No i have not... i got it to work by just manually adding a reference to the package's primary dll. i know it's not suppose to add the satellite assemblies but it is suppose to add the primary assembly isn't?

So it should be adding a project reference on nuget install to: \MyProject.Resoruces.dll but not to \es-US\MyProject.Resources.resources.dll, and so on ... right?

Nov 26, 2012 at 9:36 PM

Does this approach not work when specifying the csproj and using replacement tokens for ID, version, etc... where it feeds those variables from the AssemblyInfo.cs file? I imagine I have to have to call pack on each nuspec file as opposed to just once to the csproj file ?

Dec 10, 2015 at 10:05 PM
Is there a workaround for this so I don't have to change my DLL name and still get NuGet to add a reference to files with .Resources.dll?