Is there a way to reference a library without a strong name?
When I add a reference to the assembly in references and rebuild solution everything is fine, but when I call the class from this assembly solution it doesn't build.
Output says that referenced assembly should have strong name. What is the best solution? Strong naming library is not preferable.
I think the problem you have here is that the assembly you are trying to add the reference from is being signed with a strong name but the assembly you are trying to reference is not signed. A strong-named assembly can only reference other strong-named assemblies.
Either sign the assembly you are referencing or don't sign the assembly that is referencing it.
The reason why the error only appears when you actually call the class is because the compiler will strip out the reference in the compiled output if there is no code actually invoking the referenced assembly.
If it's the case that you really can't either add a strong name to the one being referenced, or remove the strong name from the one doing the referencing (sorry long-winded) then you are going to have to look at binding the class at runtime via reflection and then accessing it via a common base or interface - not ideal at all; or even worse actually invoking it via reflection, or dynamic.
The whole point of a strong name is that you know what dlls are getting loaded. You can't add a strong-name to your dll if you reference something that isn't strong-named, as anything could be loaded in place of the dll you are thinking of (as long as the name matches). This entirely defeats the guarantees that a strong name is intended to provide.
So (one of):
don't add a strong-name to your dll (for most internal things, you just don't need one)
or; rebuild the dll you are referencing with a strong-name
or; load the additional dll only through reflection (yuck)
Related
Suppose you have an assembly B that references A and you have the source code for the assembly A only. Is it possible to build from source code the assembly A and debug it?
Currently we get this error:
Could not load file or assembly 'name' or one of its dependencies. The
located assembly's manifest definition does not match the assembly
reference.
Is there any way to bypass it?
This will depend on if the original assembly A that is referenced is strongly named. This is a feature where assemblies are signed. Keys for all compile time references are stored in the built assembly, B in your case. When loading assemblies the loader may then verify the signatures of all references to ensure the correct assembly is loaded.
So if strong naming is used it is not easy to replace the assembly A with a newer version without recompiling B. There is however a strong name validation bypass feature for full trust application domains.
If you manage to bypass or disable the strong naming you should simply be able to replace the file in the directory with the new version and attach visual studio.
I have been working on upgrading my application to use the MongoDB 2.0 driver, but have hit a road block since MongoDB is not currently releasing a strongly named version of the assemblies. As a result I cannot build an assembly in my solution that gets registered in the Global Assembly cache (GAC) because GAC requires assemblies to be strongly named.
Using the technique explained on Ian Picknell's and Ryan Farley's Blogs I was able to strongly name the assemblies; MongoDB.Bson.dll, MongoDB.Driver.dll, and MongoDB.Driver.Core.dll. After strongly signing them I removed the old references to these assemblies and added references to the new strongly named versions. When I try to build the project in VS2013 2 errors(see below) are generated both of which are trying to reference the weakly named assembly (This is my understanding because the error states PublicKeyToken=null).
I've also tried building strongly named assemblies straight from the source code since MongoDB is open source but that has been generating hundreds of errors that i'm still working through.
Error 1 The type 'MongoDB.Bson.BsonDocument' is defined in an assembly that is not referenced. You must add a reference to assembly 'MongoDB.Bson, Version=2.0.1.27, Culture=neutral, PublicKeyToken=null'.
Error 2 The type 'MongoDB.Driver.IAsyncCursorSource`1<T0>' is defined in an assembly that is not referenced. You must add a reference to assembly 'MongoDB.Driver.Core, Version=2.0.1.27, Culture=neutral, PublicKeyToken=null'.
I Installed the nuget package StrongNamer and it signed automatically the unsigned dependencies.
Strong Namer will automatically add strong names to referenced
assemblies which do not already have a strong name. This will allow
you to reference and use NuGet packages with assemblies which are not
strong named from your projects that do use a strong name.
Read topic 331520 and Dirk Vollmar's answer (Also give him an upvote). The link he provides explained the problem I was encountering.
A quick summary of the problem was the original MongoDB.Driver.dll and MongoDB.Driver.Core.dll were built with a reference to the unsigned version of MongoDB.Bson, so I had to update the references inside of those DLL's to include the publickeytoken I used to sign the assemblies. All is explained by the .NET-fu article under the Foo, Bar, Baz section.
In my solution, there have one C# class library project(A project). I would like to add the strongly named assembly in that project. But (A project) has include another DLL (B.dll).
I generate the "a.snk" using VS2012 x86 Native Tools Command Prompt.
Like this
sn.exe -k C:\A.snk
And I add the following code in "AssemblyInfo.cs" of (A project). Then build the project.
[assembly: ComVisible(true)]
[assembly: AssemblyDelaySign(false)]
[assembly: AssemblyKeyFile("C:\A.snk")]
After build (A project), it has a error "Assembly generation failed -- Referenced assembly 'B' does not have a strong name". But (B.DLL) is created by third party.
How to fix it? Many Thanks.
You have a problem. Your only option is to ask the third party to provide a strong name otherwise you won't be able to do it for your application.
The point of these strong names is to create some kind of accountability are you going to be accountable for your app if the third party dll is failing or doing things that are not 'normal' ?
This question has been asked before I found something on msdn :
https://social.msdn.microsoft.com/Forums/vstudio/en-US/35930958-9775-4e56-bd38-0362d124ffc4/assign-strong-name-to-third-part-dll
You don't have to create a strong name for your assembly (A project) just because it references an assembly with a strong name. Simply don't do that and you will be able to compile your assembly without problems. In fact, all the BCL assemblies have strong names and could otherwise not be referenced.
But as Philip Stuyck is telling in the answer above, if you need to create a strong name, you will have to ask your third-party vendor for a signed version of B.DLL.
So, I have two projects... One is a big class library, and the other is a big simulator project.
Originally during testing the assemblies were not strong-named, but now that I need COM visibility, I need to strong name them (I need this quick, and it is easier to make them COM visible rather than deal with the CLI).
I generated a .snk and added it to the properties of each of the projects, the class library compiles just fine and outputs the .dll just fine. I added this .dll as a reference in the simulator project, but now the simulator project is giving me the following error:
The type "DynamicsControl" is defined in an assembly that is not
referenced. You must add a reference to assembly "DynamicsControl,
Version=0.4.3.0, Culture=neutral, PublicKeyToken=null"
The type DynamicsControl does exist in the class library (I verified), but it is claiming I am not loading the correct assembly. I believe it is the PublicKeyToken=null that is causing the issue (as my assembly would have a public key).
When I do sn -Tp DynamicsControl.dll (the one in the location I am referencing), it outputs the private and public key, so I know it has a proper signature.
What step am I missing? Do I have to add the assembly to the GAC? Do I manually have to add the public key?
Yes you need to specify the publicKeyToken for a strong named assembly otherwise it will look for unsigned version of the assembly. You can find out the public key token either by adding the assembly to GAC (and you will see it there) or by using the steps mentioned in the this link
If you want to read more about strong name and dll hell you can go to this URL .
Strong name prevents from dll hell which means you can have multiple versions of same assembly.
To your other question you don't have to add the assembly to GAC but CLR will look for the assembly first in GAC and then other places. Also, you don't have to add the key manually. If you remove the reference and add it back using the signed assembly it should automatically take the key.
I have created a test project whose output will be strong named assembly. I have specified the SNK file name in the 'project -> properties - > Signing' section so that assembly will be strong named.
I added reference of the assembly which is NOT signed or strong named. I was expecting that my project will not at all build since it's referencing unsigned assembly. However, it built and i could install the assembly in GAC too! Why is it so? (I'm using .NEt 4.0 and it's gacutil.exe)
Note: I have ensured that the assembly which is being referenced is NOT strong named.
Can i programatically load the 'unsigned' (i.e. non-strong named) assembly in my program whose output is going to be strong named assembly? If yes, why is it allowed to do so when on the other hand, .NET don't allow to add reference to unsigned assemblies?
If I have multiple versions of the same assembly in GAC. In my configuration file, If I specify just the name of the assembly, which version will be loaded from GAC? Will it be latest version everytime? Which API will be useful? I found many methods marked 'deprecated' in Assembly class.
You can reference the unsigned assembly in VS.Net from a signed assembly. But if you call anything from the signed to the unsigned, the build will fail.
There is no problem in signed assembly referencing an unsigned assembly. It can be done and signed assembly can be GACed.
Yes, you can load.
How can you specify assembly by just name ? There is only one API LoadWithPartialName and thats deprecated for many reasons. You need version, culture and public key token to uniquely identify assembly.