VS2013 Database Project without generating dll

Question

How to disable generating dll in VS2013 Database Project?

I don't use SQLCLR at all.

Rexfourd

It's not possible to disable this, but I'm interested - why do you want to disable DLL generation? During build both the .dacpac and .dll files are generated, but you can ignore the .dll unless you are using SQLCLR. I can't think of any performance benefit from doing this, and the generated file is only 4KB. Is there something I'm missing here? – Chickenlivered

I'll add that I wanted to ignore the dll to simplify creating an automated deployment. We have a project with 10 dbs and a couple of separate SQLCLR projects. So, I can't just ignore .dlls when setting up deployment artifacts, because a couple of them are needed. But I was trying to not explicitly define them. If I could have not built the database .dlls, then I could just copy any others into deployment. Alas, there are lots of references between the databases, thus I have to create the .dlls and explicitly define any I actually need. – Sedimentation

Answer 1

Assuming that the goal is simply to not have the DLL in the output folder (e.g. \bin\{configuration}) along with the .SQL and .DACPAC files, the cleanest way to prevent this seems to be adding the following XML element under the main <PropertyGroup> element in your project's .sqlproj file:

<CopyBuildOutputToOutputDirectory>false</CopyBuildOutputToOutputDirectory>

The DLL is technically still generated, but that happens in the \obj\{configuration} folder.

EDIT:
If you also want to prevent the PDB file from being copied into the output folder, then use the following element in the same location as noted above:

<CopyOutputSymbolsToOutputDirectory>false</CopyOutputSymbolsToOutputDirectory>

Brahmin

Doing this disables the build, which means a Dacpac file wouldn't be created - this would mean that on publish an out of date version of the project is used, which I don't think is what's wanted here – Chickenlivered

@KevinCunnane: fair enough, and thanks for at least giving a reason for the downvote (assuming that was you) instead of making it appear random. There is a way to do this without disturbing anything else. I just need to test it. I will update my answer soon with the proper method. And btw, I also question the reason for doing this, however, it is possible and there could be a legit reason for not wanting it. – Brahmin

@KevinCunnane: answer has been updated such that the build still happens and the .dacpac file is created. – Brahmin

thanks, I have removed the downvote since you have updated it with a working answer. I'm a little new at up/downvoting and I didn't mean to make it seem harsh, it's just the original answer might have caused real issues when deploying. – Chickenlivered

The dll is not copied to bin. However, the pdb is still copied to bin – Rexfourd

@linquize: I don't remember that happening on my test but I will see if I can reproduce and if so, then fix. – Brahmin

@linquize: I updated the answer with additional info that should do this new requirement. – Brahmin

Answer 2

SSDT must generate a dll as the MSBuild Key Output to enable other project types to reference SSDT. Unfortunately many project systems in VS assume it's references generate a dll and when they don't unfortunate things happen.

Deluca

How does your answer relate to the accepted answer, as the DLL is not copied to the output. – Fluorometer

@JohnSaunders While the accepted answer appears to have met the OP's requirements, the question explicitly states "without generating dll". Even the accepted answer still generates a dll, and Patrick was simply explaining why the dll is necessary. – Insular

@Patrick Sirr Your comment might address my problem. I'm adding a database reference but dll isn't being generated which leads to unresolved references. What do I need to do? – Orthodontia

Answer 3

You could just add

del $(TargetPath)

To the post-build event in Database Project.

Grantinaid