Distribute Dapper as pre-compiled assembly on Nuget

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Get Dapper from NuGet

What is the expected output? What do you see instead?

An assembly reference.
A single code file.

Please provide any additional information below.

This impacts issue 71 as well, in that I have a project I want to use Dapper in 
(several) but we have XML documentation turned on.  I want to use Nuget to 
manage the versioning of Dapper, but including it in my own projects causes all 
the missing XML comment warnings to come up.

Right now, the workaround is to create a separate class project which exposes 
Dapper and then reference that, but it feels kludgy and introduces a project 
that isn't really aligned with the other assembly names into source control.

Original issue reported on code.google.com by casper...@caspershouse.com on 2 Oct 2011 at 9:19

[GoogleCodeExporter]

Sorry, I meant to reference issue 65 (in the "additional information" section).

Original comment by casper...@caspershouse.com on 2 Oct 2011 at 9:20

[GoogleCodeExporter]

I dislike the idea of this workaround, just submit a patch with the comments I 
will pull it in

Original comment by sam.saff...@gmail.com on 5 Oct 2011 at 10:28

[GoogleCodeExporter]

Sam,

That doesn't solve the problem.  Even if the code file was injected, the code 
might not compile for warnings as errors, or say using Code Analysis with all 
rules turned on.

The point being, everyone will have different checks/standards that they will 
apply to the code that they are developing and we can't expect you and Marc to 
adhere to *all* of *our* standards.

A compiled assembly solves this problem for many people.  Additionally, it 
prevents having what is essentially the same type multiply defined in all of 
the assemblies we choose to use Dapper in (now maybe some people want that, 
which is why you should have two distributions, one for the file, one for the 
assembly).

I could easily provide the XML comments, but it would just result in another 
ticket where something else fails because of the build requirements.

Original comment by casper...@caspershouse.com on 5 Oct 2011 at 4:08

[GoogleCodeExporter]

+1. It's great this can be dropped into a project as a single file, but it 
should also be available as a separate versioned assembly for folks who prefer 
to manage dependencies that way.

Our team, for example, receives no benefit in continually rebuilding dapper on 
every commit and running code analysis, resharper building indexes on it, 
getting warnings about low code coverages etc. It is actually a burden that 
slows our build and adds noise to reports.

Original comment by rdingw...@gmail.com on 10 Nov 2011 at 1:33

[GoogleCodeExporter]

For the record, I could get behind having two packages. It makes deployment a 
*little* trickier, but not much more so than, say, mini-profiler (but: parallel 
packages rather than dependent)

Original comment by marc.gravell on 10 Nov 2011 at 9:53

[GoogleCodeExporter]

@marc.gravell: That sounds like a commitment to me =)  Let me know when I can 
get at it. =)

Original comment by casper...@caspershouse.com on 10 Nov 2011 at 10:10

[GoogleCodeExporter]

+1 for this. Everything from code coverage to StyleCop is affected by including 
this as a source file.

Original comment by chripede@gmail.com on 21 Nov 2011 at 1:24

[GoogleCodeExporter]

@chripede, I submitted a pull request that includes an //<auto-generated/> 
comment at the top of SqlMapper.cs when deployed via Nuget.  If that gets 
accepted, it should at least help with the static code analyzer problems.

https://github.com/SamSaffron/dapper-dot-net/pull/20

Original comment by pagebro...@gmail.com on 2 Dec 2011 at 9:54

[GoogleCodeExporter]

Can't this be closed now because the nuget package deploys as an assembly?

Original comment by richard....@gmail.com on 21 Aug 2013 at 1:39

[GoogleCodeExporter]

Original comment by marc.gravell on 21 Aug 2013 at 1:57

• Changed state: Fixed