Assembly generation failed - Dapper has no strong name

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Sign your own assembly (i.e. App.snk).
2. Reference Dapper 1.8.
3. Try to compile your app.

What is the expected output? What do you see instead?
Expected: Build succeeded
Instead: Assembly generation failed -- The assembly Dapper, which is 
referenced, has no string name (<- translated from german)

What version of the product are you using? On what operating system?
version 1.8 on Windows XP SP3

Please provide any additional information below.

Original issue reported on code.google.com by mrt...@gmail.com on 1 Feb 2012 at 12:26

[GoogleCodeExporter]

"has no strong name" instead of "has no string name"

Original comment by mrt...@gmail.com on 1 Feb 2012 at 12:29

[GoogleCodeExporter]

If your in need of a mitigation, since this is Open Source software you could 
compile and sign the code yourself until the ticket has been completed.

Original comment by hype8...@gmail.com on 15 Feb 2012 at 2:41

[GoogleCodeExporter]

I would just like to add comments to this, I added dapper extensions now to the 
project and even though I have built my own version of dapper to get around the 
strong name limitation nuget will install the dapper version from nuget as a 
dependency requirement to dapper extensions which is extremely frustrating. 
Nuget is such an awesome tool to use to depend on updates and such and using 
the work around is a huge inconvenience and it seems like a rather simple fix. 
Nuget should just make a requirement that the assembly be strong named if 
that's even possible.

Original comment by casey.en...@gmail.com on 22 Aug 2012 at 8:01

[GoogleCodeExporter]

+1 for this.  IMHO binaries distributed by NuGet etc should always be strong 
named, for these reasons.  

- Either with a private key known only to the developers, which then makes an 
assertion about the provenance of signed binaries.  In this case, others who 
generate their own versions from the source code should be encouraged to use a 
different assembly name, and a different strong name key (or leave it unsigned).

- Or with a publicly available private key, in which case no assertion is made 
about the provenance of signed assemblies, but at least they can be consumed by 
other strong-named assemblies.

In either case, versions signed with different strong names should also have 
different assembly names, to avoid the problems that now face log4net users.

Original comment by Jocular...@hotmail.com on 19 Oct 2013 at 11:11

[GoogleCodeExporter]

+1 here too, I could really use a strong name version

Original comment by fljoh...@gmail.com on 12 Nov 2013 at 4:50

[GoogleCodeExporter]

I understand that there are arguments for and against strong naming, but 
numerous NuGet packages take the agnostic approach of providing a strong named 
and non-strong named package. This appears to be the best approach, since 
otherwise one group is forced to compile the code, nullifying the entire 
benefit of publishing a package.

Original comment by codekai...@gmail.com on 24 Nov 2013 at 5:32

[GoogleCodeExporter]

I agree with #6 - there should be a strongly named version of Dapper available 
on NuGet.

Using Dapper with SharePoint code is particularly painful, as SP DLLs are 
generally deployed to the GAC and therefore have a strong naming requirement. 
Updating Dapper involves manually downloading the unsigned version and using 
ILDASM to hack in a key.

Original comment by pitmanna...@gmail.com on 6 Jun 2014 at 1:57

[GoogleCodeExporter]

This will likely never be solved. See Marc Gravell's thoughts on it here: 
http://blog.marcgravell.com/2014/06/snk-we-need-to-talk.html

Original comment by alibhai....@gmail.com on 29 Aug 2014 at 2:57

[GoogleCodeExporter]

Well, I made a strong named version of SE.Redis; I haven't ruled it out - it 
just really vexes me that this double world exists and is necessary.

Original comment by marc.gravell on 29 Aug 2014 at 4:21

[GoogleCodeExporter]

Please see https://www.nuget.org/packages/Dapper.StrongName

Original comment by marc.gravell on 29 Sep 2014 at 11:30

• Changed state: Fixed