How to handle project having depency on both Standard and StrongName

[Tazer]

Hello,

I got into some problem , I have 2 different nuget packages that have different StackExchange dependencies on on StackExchange.Redis and one on StackExchange.Redis.StrongName. How should this be handled ?

[mgravell]

Yeuch; that's a mess; extern alias is your only option; in project properties, select the reference you want to tweak; note the "Aliases" entry says "global". Change it to something else, "signed", perhaps. Now in the class files where you need to talk to that type, add:

extern alias signed;

at the top - that tells it to include the alias. Now you have two options; a using directive, i.e.

using signed::StackExchange.Redis;

or explicit full types in your code:

signed::StackExchange.Redis.ConnectionMultiplexer foo = ...

Let me know if that doesn't work out for you, but it seems ok in a console exe here.

[mgravell]

I should note that you can have multiple aliases against a single reference; it could be global and signed, for example - comma delimted, so "global,signed"

[mgravell]

Of course, if you don't need to use SE.Redis directly, it should all already work...

[TheCloudlessSky]

@mgravell I can appreciate all the thought you've put into strong naming. Since you decided to strong name this library as a separate Nuget package, it means that those of us that use StackExchange.Redis as a dependency to our libraries should really maintain two separate Nuget packages.

In this case, @Tazer is referencing Microsoft.Web.RedisSessionStateProvider and my library, NHibernate.Caches.Redis for caching in NHibernate.

The session state provider does not provide an unsigned package (and therefore the build conflicts when referencing my library since my references is of the unsigned package) since he has to do ConnectionMultiplexer setup with my library.

What I propose is that there be a single Nuget package that is strongly named (akin to AutoMapper, JSON.NET etc). Even though I'm personally against strong naming, projects that want strong name can all use the same Nuget dependency.

What do you think?

[TheCloudlessSky]

This is what @jbogard, @haacked and others proposed in the long debate of the Octokit.NET strong naming.

[jbogard]

@TheCloudlessSky Pretty much.

Strong-named: painful to few
Not-strong-named: painful to orders of magnitude more

I would prefer not to strong name, but the choice between pleasing a set of users I could count on one hand versus frustrating hundreds or thousands, AND it's really no work for me one way or the other, the obvious choice for me was SN in a single package. Tacking SN away from AutoMapper was a short-sighted, selfish mistake made out of hubris. It went back shortly after.

[NickCraver]

Should we just strong name a 2.0 release for CoreCLR in a single package? /cc @mgravell

I also hate StrongNaming, but since Microsoft elected to not remove it in .Net Core, it seems we're stuck with it forever.

[TheCloudlessSky]

@NickCraver It's frustrating that they kept it around because they don't even necessarily recommend using it.

However, I think going the single-package route is best for library maintainers like myself that depend on SE.Redis.

[jbogard]

FYI for my new packages, I don't strong name and refer them to the strongnamer tool AutoMapper/AutoMapper.Data#14

[TheCloudlessSky]

@jbogard That's awesome! I'll be doing the same for all the projects I manage now.

[NickCraver]

Folding this into #528 where we'll eliminate the .StrongName package split in 2.0.