c# - can you make a "weak" assembly reference to a strong named assembly

Question

For various reasons i would rather not use strong named (signed) assemblies in my project. however, one of the projects is referenced by a sharepoint web part which means it must be signed.

is it possible to have this assembly signed but when I reference it from other projects, to do so using a non-strong reference. this would give me the advantages of having a non-signed assembly for the rest of my code but still allow it to be loaded by sharepoint.

Alfie

Answer 1

The simplest way to do this is probably to have two different project configurations - one of which builds a strongly named assembly and one of which doesn't. Obviously you'll need to be careful how you build and reference the assembly, but that goes with the territory of having conflicting requirements.

Subterranean

How would you set up "two different project configurations" in Visual Studio? – Binocular

Configuration drop-down is disabled on Signing tab in project properties: i.imgur.com/vwZKy.png – Binocular

@PavelChuchuva: Without knowing more about what you're doing, it's hard to say why it's disabled, I'm afraid - and I don't have Visual Studio with me to experiment. – Subterranean

I think it is not possible to have two project configurations where one signs assembly and one doesn't. – Binocular

Answer 2

Just keep building your project w/o strong names. When you need to deploy it to Sharepoint, use a tool to sign it after it is built. Here's a tool that does exactly that:

http://signer.codeplex.com/Wikipage

You can also do it manually, but it's a PITA:

http://buffered.io/posts/net-fu-signing-an-unsigned-assembly-without-delay-signing/

Petuntse

Answer 3

This is the OP but I don't have an OpenID login so I guess I can't reply as myself.

Thanks for both the responses. I think either would have worked but the situation turned out to be a bit more complex. I've documented my findings here in case anyone else is interested.

In fact sharepoint references assembly A and assembly A in turn references assembly B.

I can build assembly A and B both unsigned with no problem, but then if I want to sign A, I have to change the project itself to reference the signed version of assembly B.

Although there might have been a way to do this, we decided the possible DLL conflicts and configuration control problems with having different sets of DLLs with the same name were not worth the hassle.

So we have decided to sign both these assemblies in all builds, refactoring code into different assemblies where necessary to make sure that only the minimum amount of code is in the signed ones so they are less likely to change.

Tim

Alfie