13

This is a classic problem, which has numerous solutions described. However, none of them seem to work for me.

I am using the Report.NET library in a SharePoint solution. Adding the Reports.dll as a reference and compiling results in the error message "Assembly generation failed - Referenced assembly 'Reports' does not have a strong name." My project, however, has a key.snk linked in the project properties. So I try to disassemble, sign and reassemble the dll with this key file, as described elsewhere:

C:\Users\Administrator\Documents\Visual Studio 2010\Projects\MyProj
\dll>ildasm Reports.dll /out:Reports.il

C:\Users\Administrator\Documents\Visual Studio 2010\Projects\MyProj
\dll>ilasm Reports.il /dll /resource=Reports.res /key=..\key.snk

<output removed for brevity>

Class 95
Class 96
Method Implementations (total): 1
Resolving local member refs: 0 -> 0 defs, 0 refs, 0 unresolved
Writing PE file
Signing file with strong name
Operation completed successfully

I end up with a new Reports.dll timestamped to now. Adding this as a reference to my project and building, though, gives the same error message as before. The properties of the "Reports" reference displays "Strong Name: False".

Not to be discouraged by a bit of trouble, I attempt to re-sign the assembly using the strong naming utility:

C:\Users\Administrator\Documents\Visual Studio 2010\Projects\MyProj
\dll>sn -R Reports.dll ..\key.snk

Microsoft (R) .NET Framework Strong Name Utility  Version 4.0.30319.1
Copyright (c) Microsoft Corporation.  All rights reserved.

Assembly 'Reports.dll' successfully re-signed

It might be worth noting that running the SN utility fails with the error message "Reports.dll does not represent a strongly named assembly" when running it before the disassemble/sign/reassemble process.

However, when running it after disassembly/signing/reassembly, I still get the original error message when re-adding it to Visual Studio.

Geir Smestad
  • 1,344
  • 2
  • 15
  • 25
  • possible duplicate of [Assembly generation failed -- Referenced assembly 'Interop.Office' does not have a strong name](http://stackoverflow.com/questions/6845537/assembly-generation-failed-referenced-assembly-interop-office-does-not-have) – JabberwockyDecompiler May 19 '15 at 16:23

2 Answers2

23

I just solved this problem in vs 2010 using this: 

Project Properties -> Signing -> uncheck Sign the assembly checkbox
The Hungry Dictator
  • 3,444
  • 5
  • 37
  • 53
Oleg Guchashvili
  • 246
  • 2
  • 2
  • 7
    I just love stack overflow. 99% of my problems are always resolved with the help of stack overflow. You all rock!! – Karishma May 02 '14 at 09:45
3

I would suggest that if, after you have unambiguously signed the Reports.dll correctly from the command line, VS still says that that dll is unsigned; then it must be referencing the wrong file.

If you want to be really paranoid and double-check the strong-naming after signing, load Reports.dll into ildasm (you have to double-click the manifest node in the tree and scroll down to find the .publickey section). Or for ease just open it in ILSpy.

After signing reports.dll; open your referencing project's proj file as an XML document (if you have the VS PowerCommands you can right-click and 'Edit Project File'; otherwise you can unload the project and then open it in VS using the 'Open With' command from the Open File dialog) and verify that the reference to the dll is indeed the correct path. If it's not, correct it and reload the project.

Andras Zoltan
  • 41,961
  • 13
  • 104
  • 160
  • Hi, thanks for your input. After running the signing commands above, ILSpy (nice tool, by the way) reports [assembly: AssemblyKeyFile("")] and [assembly: AssemblyKeyName("")] for Reports.dll. I am guessing this means that the file isn't actually signed? The file's timestamps still correspond to the supposed signing, though. – Geir Smestad Feb 22 '12 at 09:40
  • Out of interest - when you select the root node of the assembly in ILSpy, the right-hand pane should show in the first two comments the filename and then the full assembly name on the second line. On that second line, does the assembly name end with `, PublicKeyToken=[some_hex_string]`? – Andras Zoltan Feb 22 '12 at 10:26
  • 1
    Also is this the 'Report.Net' library here: http://sourceforge.net/projects/report/ If so can you not open the project and rebuild in VS with your keyfile as part of the build process? – Andras Zoltan Feb 22 '12 at 10:32
  • The assembly name is "Reports, Version=0.8.1774.35468, Culture=neutral, PublicKeyToken=null". So I guess that also points to that the assembly wasn't actually signed. You've found the right library, and I could build it the way you describe. Will probably end up doing that if I don't figure it out soon, but I've always had trouble with signing and wanted to see if I could figure it out once and for all. Thanks. – Geir Smestad Feb 22 '12 at 11:41
  • I notice that Reports.NET is targeted to .NET version 2.0. My project is targeted to .NET 3.5. Does this have any significance? – Geir Smestad Feb 22 '12 at 12:36
  • No that shouldn't be an issue - 3.5 still runs on the 2.0 CLR – Andras Zoltan Feb 22 '12 at 12:53