13

I am writing a Visual Studio 2012 extension, for internal use, which requires that all assemblies have a strong name. I am dependent on RestSharp (and a few other dlls), and since it is not strongly named, I am adding a strong name to it by following this. Everything works according to the output of the process, and even visual studio claims it is strongly named if I look at the properties of RestSharp.dll in the project references. However, when I go to use my extension I get a FileLoadException claiming:

Could not load file or assembly 'RestSharp, Version=104.1.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. A strongly-named assembly is required. (Exception from HRESULT: 0x80131044)

Any thoughts on how to resolve this or work around it?

Adam
  • 3,014
  • 5
  • 33
  • 59
  • From `PublicKeyToken=null`, it's looking for an *unsigned* version of the assembly. I would remove all of your references to RestSharp, and re-add them to the signed assembly. – vcsjones Dec 21 '12 at 14:38
  • In pre-build event I do the ildasm ilasm step and then build the project. Since the project is referencing the dll from the specified path, where the new signed dll is, shouldn't it have the signed version? Does the project reference actually have to be signed? I would have assumed that the dll that is signed at time of build would have been enough. – Adam Dec 21 '12 at 14:46
  • 4
    `Does the project reference actually have to be signed?` yes. Signing it after the fact is not good enough. The assembly manifest for your assembly that *references* RestSharp keeps track of the fully qualified assembly name, including the strong name (or absence of one). – vcsjones Dec 21 '12 at 14:49
  • This worked well for me: https://www.nuget.org/packages/strongnamer – Piedone Mar 29 '20 at 20:01

3 Answers3

5

I wrote a NuGet solution level package to help with strong naming 3rd party assemblies with your own key.

This is targeted for signing the contents of NuGet packages that are using unsigned assemblies, in order to be able to link to these packages where the consuming project is strongly named. Access to the original source code is not required, and you may sign any assembly with your own strong naming key. You may also delay-sign if desired.

https://nuget.org/packages/Nivot.StrongNaming

You can read more about it on my blog:

http://www.nivot.org/blog/post/2013/04/30/Signing-unsigned-assemblies-in-NuGet-packages

x0n
  • 51,312
  • 7
  • 89
  • 111
  • Hi xOn, great work. I have one problem: When I sign a 3rd party assembly from nuGet with your tool everything works fine. But it seems after restarting VS I get the old error message again and have to use your tool again to sign the assembly. Am I doing something wrong or do I just have to put the commands for signing in the pre-build-event of my project? Thanx for your help! – SolarX Dec 11 '13 at 15:39
  • Hmm, maybe VS is rebuilding the output because it thinks it is out of date? I'm not sure... sorry. – x0n Dec 12 '13 at 05:14
  • @x0n - How does your utility handle signing a group of dlls at the same time - when there are references from some of those dlls to other dlls in the group of dlls? Does your utility correctly change the weak references in those dlls to strong references (to the newly signed dlls)? – N73k Apr 17 '19 at 16:29
  • @N73k Yes, it does. See https://github.com/oising/strongnaming -- the only thing it doesn't do is update internalsvisibleto attributes. – x0n Apr 18 '19 at 15:44
  • @x0n - Do you plan to fix the internalsvisibleto thing? Maybe for now you can just make an option to remove all the internalsvisibletos? – N73k Apr 19 '19 at 16:24
1

I tried to use RestSharp from VSPackage and it works. My steps to add RestSharp:

  1. Add RestSharp by NuGet in a project where I will use it. To do this, right-click on the project in Solution Explorer and selecting the “Manage NuGet Packages…”, find RestSharp and press Install button.

  2. Write test code in this project:

    
var test = new RestSharp.RestClient("http://test.com");
Logger.Log(Category.Info, "Test {0}", test.BaseUrl);

  3. Add RestSharp by NuGet in the installer project. Similarly paragraph 1. I use the VSIX Deployment Package. To set the necessary assembly just need to add a reference to assembly in the VSIX Deployment Package. This makes the “Manage NuGet Packages…” command. When you create a VSPackage by VS Wizard, the main project of VSPackage is VSIX Deployment Package.

    If you use another method of installation your VS extension (for example, MSI installer), you need to explicitly add RestSharp.dll to our installation package.

As a result, I got line "Test http://test.com" in the log.

Most likely in your case, that RestSharp.dll been not installed and therefore VS is not finding RestSharp.dll when loading your module. Or the fully qualified name of installed RestSharp assembly is different from the fully qualified name assembly in References of project. To see this check out whether RestSharp.dll file in folder of your extension (for VSPackage by default patch is "%LOCALAPPDATA%\MICROSOFT\VISUALSTUDIO\11.0EXP\EXTENSIONS\{YourCompanyName}\{YourProductName}\{YourProductVersion}\"). You can see the absolute path to your extension in the Modules window if run the extension under the debugger.

Edit: I just now noticed that the RestSharp assembly from NuGet has not a strong name. So the directory of installed extension and References of projects should contain the exact same assembly with a strong name, and everything will work fine.

Mikhail Shcherbakov
  • 1,826
  • 16
  • 22
0

A few things you can check:

It seems you project refrence is still to the unsigned dll .\RestSharp.dll. You should compile your project against the signed .\Signed\RestSharp.dll dll. Remove the current refrences and add the again.

Also check the dll in the bin directory of your project. It's possible the old RestSharp.dll is still there. Remove it and check all build directories.

You can also check if the restsharp.dll is in you GAC. If so remove the dll from your gac.

Peter
  • 27,590
  • 8
  • 64
  • 84