Force to use Client profile

Feb 10, 2012 at 10:01 AM

Is there a way to force an assembly to use a specific framework profile (Client Profile).


We have one assembly running full and one client profile.

They both use log4net. Log4Net has support for both Full and client profile.


The problem is that NuGet chooses Client profile for one and full for the other. Since they are placed in the same folder we want them both to use the Client profile of log4net. 

Is this possible?


Feb 28, 2012 at 10:45 AM

There isn't a way to override the target framework NuGet uses to determine which assembly to use from the package. If the log4net package has different assemblies, it's always going to use the one that best matches the target framework. Can you describe what issue this is causing?

Feb 28, 2012 at 12:11 PM
Edited Feb 28, 2012 at 12:18 PM


Main program uses .NET 4.0
Module A uses .NET 4.0 client profile
Both import the Log4Net NuGet package which supports both normal .NET and client profile.

If main program imports Module A through NuGet and compiles the code the following will be placed in the /bin/Debug folder:
-MainProgram.exe <-- .NET 4.0
-ModuleA.dll <-- .NET 4.0 client profile
-log4net.dll <-- .NET 4.0 since the current project uses .NET 4.0

When running the program there will be an exception in ModuleA.dll when it tries to use log4net.

Everything would have worked fine if the client profile version of log4net was the one being placed in the /bin/Debug folder since .NET 4.0 assemblies can talk with 4.0 client profile assemblies.

Feb 28, 2012 at 4:06 PM
Edited Feb 28, 2012 at 4:09 PM

Maybe I'm misunderstanding something, but it seems like in this case ModuleA's package should also have both full and client profile assemblies. As a package author, if I'm taking a dependency on a package that has both client profile and full profile assemblies, I know I need to do the same, or else my consumers could end up in this very situation.

To fix this in NuGet would mean doing a lot of extra work when building the dependency graph and deciding which assemblies to get, and even if we did that, I'm not convinced there are enough packages out there containing client profile bits that it would make much difference (not to mention there's no guarantee that the assembly in the client profile folder actually targets the client profile). I think it's even more rare that a package would have *only* client profile assemblies in the package, which is what really causes this scenario, if I understand it right.

One thing we could do to make things better is when packaging ModuleA, you get a warning if you only have client profile bits, since your dependencies have full profile bits.

Do you have an actual repro using packages on the gallery today? I'd like to contact folks like ModuleA and let them know they should consider adding full profile bits to their package.

Feb 28, 2012 at 4:27 PM

What I understood from this was that the assembly name was the same from both cp and full package lib folders, when it gets compiled to one folder (i.e. a dependency on cp project from full .net assembly), the cp assembly is overwritten by the full assembly by the same name.

Did I catch that right?