Friday, June 10, 2011

refer unsigned assembly in SharePoint 2010 Project ( Visual Studio 2010)

I have around 50 3rd party dll's which I need to refer in my SharePoint project.
But since my project dll is strong named we were unable to refer unsigned dll's in it.
I tried below mentioned things:
1. removed signing of my dll from project properties. Project is build But in this case xml template of the package fails .The error I get while package creation is :
Value cannot be null. Parameter name: PublicKey
2. I tried below mentioned commands to strong name all the 3rd party dlls :
ildasm myDLL.dll /
This generates and myDLL.res
ilasm /key:Key.snk /res:myDLL.res /dll /out:myDLL.dll
This generates back strong named DLL.
But after this few of the namespaces get missing in the final DLL !!!!! well to my surprise .
3. I created a blank class library project . Given predefined structure to deploy 3rd party dll ( 80\bin) , with user controls inside proper structure as per wspbuilder guidelines. given the output path of my project dll as (80\bin).
Now I have a wsp ready and working being deployed . But neither my project dll is strong named nor the third party DLLs. dlls are deployed in web application bin and user controls inside proper control template folders . They work fine . but …
Now I come to my query:
I need to strong name my project dll still use 3rd party unsigned dll's inside my SharePoint project very similar to point 2 above.
Kindly suggest something.

Reply 1 By

Ask the 3rd party to provide properly signed assemblies?


Reply 2 By


Might be a good option to wrap your business logic up that uses the DLLs in a WCF service and run it outside SharePoint, then you can call these methods safely from inside SharePoint (are you writing web parts?).

Reply 3 By

1. Use IlDasm to disassemble the DLL to an .il File

2.  Then use IlAsm to reassemble it passing in a new key generated with the sn command line utility to generate strong names.

Make sure you use the .Net 3.5 versions of ILDasm and ILAsm or it will reassermble the Dll for the wrong framework, sharepoint  2010 stuff is .Net 3.5

The downside is you'll have to do that everytime a new version comes around.

This is how I got the .Net 3.5 version of the AJAX Control Toolkit to work in sharepoint 2010.


Heres a pretty in depth article that even covers signing DLL's that reference each other.

My Blog: Website: Under Construction

No comments:

Post a Comment