Click here to Skip to main content
15,843,498 members
Please Sign up or sign in to vote.
1.00/5 (1 vote)
See more:
I have an assembly, for example SomeDLL.dll. I have signed it using the "Sign the assembly" functionality of the VS-2010 in order to protect tampering.
Then, I have referenced it in a project and it did not work and throws some error related to verification. Then, I have disabled the verification using the command of:
sn -Vr SomeLL.dll.

My question is after I have disabled the verification using the above command, does this signing still effective?

Thank you.
Updated 16-Apr-12 12:48pm
Sergey Alexandrovich Kryukov 16-Apr-12 18:10pm    
No, you should not disable the verification, ever. Please explain how you reference the signed assembly and the detail of the problem. What do you mean by "did not work"? This is not informative.

1 solution

You can only skip verification (with -Vr) to simplify development. But this is not your purpose. You reported a problem. So, if you really need strong names (and I strongly suggest you should always sign everything you ever deploy anywhere beyond your development machine), you problem well pop up again. Please see my comment to the question and answer my question. Perhaps I could see where do you screw up things and how to fix them. But first, please read below.

You almost never need to skip verification. Normally, you can develop your solution with signed assemblies without any problems if you choose one of the following principles or their combination: 1) You should put all the projects producing assemblies in on solution and references them by projects; that is: use the tab "Projects" of the window "Add Reference". This is the best way to reference your assemblies: the run-time references will be created on the fly; the project references do not contain key tokens, the references will be modified appropriately when you add or change signatures, as this information is taken from the project files, not from assembly meta-data. 2) You can reference assemblies by their executable module files (using "Browse…" tab of the same window), but in this case you should sign the assemblies before referencing them.

If you already failed to follow the rules listed above, you can fix the problem by re-referencing assemblies in question. Just remove a reference from the referencing project which gives you some trouble and add the same reference again. Then again, prefer reference assemblies by projects which you should better keep in the same solution. There is no need in skipping of signature verification.

Share this answer
MuhtarQong 16-Apr-12 18:47pm    

Thank you very much for your answer and solution. When I deploy the signed DLL on other machine, where can I put the public key or how can I put it?

Thank you again.
Sergey Alexandrovich Kryukov 17-Apr-12 11:10am    
As I say, you can sign every at the very beginning. You can 1) sign with the key of default size and Visual Studio using project properties, "Signing" tab. In the "Choose a strong name key" you can chose "<New...>" or "<Browse...>", so, 2) you can use an externally created key (for example, if you want the keys of bigger size), in this case, you can use sn -k <file_name>.

Please see:

If you agree it makes sense, please accept the answer formally (green button) -- thanks.
VJ Reddy 17-Apr-12 1:30am    
Nice answer. 5!
Sergey Alexandrovich Kryukov 17-Apr-12 11:11am    
Thank you, VJ.
MuhtarQong 17-Apr-12 13:02pm    
Thank you for your answer and solution.For a confirmation I write the while procedure:
1) I have a SomeDLL.dll
2) Sign the DLL (now it has strong name)
3) Then, using VS-2010's Dotfuscator functionality obfuscated it.
4) Referencing this obfuscated DLL in a project. At this stage verification error has been thrown. Strong named DLL has been changed during
the obfuscation (?)

In this case, should I use "Delay" signing and after delay signing obfuscate it and finally sign the DLL?

I need you help.

Thank you.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900