1

According to MSDN:

When you build a .NET Framework application against a specific version of a strong-named assembly, the application uses that version of the assembly at run time.

https://msdn.microsoft.com/en-us/library/7wd6ex19(v=VS.100).aspx

Question

Is there a way, to build a .Net Framework application against a strong-named assembly, so that it does not require the specific version at run time? The quote from MSDN seems to imply that ("against a specific version of a strong-named assembly")

But how to do that. How do I build against a non specific version of a strong named assembly? All tests I did tell me, that if I build against a strong named assembly, it will always require that version at runtime. Except when I use Publisher Policys or Assembly Redirects.

Update:

But when I check for example this nuget Package:

https://www.nuget.org/packages/Microsoft.Owin.Security.OAuth.

It says that it accepts Newtonsoft.Json greater then 6.0.4. And I want to understand how they do that? Since Newtonsoft.Json is a strongly named assembly. And I don't see any assembly redirects and I think there is also no publisher policy. Or do I miss something?

DanielG
  • 1,217
  • 1
  • 16
  • 37
  • 1
    Why do you want to avoid Publisher Policies or Assembly Redirects if they solve your problem? – D Stanley Mar 31 '16 at 14:03
  • `Strong-named` means it [includes version number](https://msdn.microsoft.com/en-us/library/xwb8f617(v=vs.110).aspx). You can't. – Sinatr Mar 31 '16 at 14:03
  • Ok thanks. Maybe my original question was not totally right ;). I want to understand how others do that. Maybe I just miss something. Just updated my orginial question. – DanielG Mar 31 '16 at 14:13

1 Answers1

1

This is handled by assembly redirection, as you've already mentioned.

The NuGet dependency management for the packet manager itself, not the assembly references. You still have strict binding for the references in your project, and this can cause collisions when you end up with two versions of the same assembly in the same AppDomain as usual. NuGet doesn't even try to solve the problem.

When that conflict arises, you're back to square one - you need to add binding redirects. If that isn't possible (for incompatible versions of the assembly, for example), you're in for a lot of fun.

The policy NuGet uses to pick the best version of the library is quite simple: get the lowest possible major + minor version, and the highest possible patch version (the third version number). Again, this only happens when updating the packages, not at compile-time or runtime. This allows NuGet to pick a compatible version of a dependency when you have multiple packages that have different requirements. However, it isn't transitive - it only helps if all your references are in the same project. If you're referencing a project that NuGet's a different version of the dependency, you're back at the original problem again.

Luaan
  • 62,244
  • 7
  • 97
  • 116