Take the 2-minute tour ×
Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.

I need to use a third party DLL in a trigger c# code in SQL Server CLR

But when I try to add reference it just shows some DLLs from SQL Server.

How can I add my third party dll to SQL Server?

share|improve this question

migrated from stackoverflow.com Feb 8 '12 at 16:35

This question came from our site for professional and enthusiast programmers.

2  
The same way you add any SQL CLR assemblies? –  Oded Feb 8 '12 at 15:00

3 Answers 3

up vote 8 down vote accepted

You can only add references to those assemblies which have been registered with Sql Server. If they are not registered, they will no show up in the Add References dialog.

There are a number of steps you'll need to do register a DLL, firstly you'll need to reconfigure your database:

ALTER DATABASE [MyDatabase] SET TRUSTWORTHY ON;
sp_configure 'clr enabled', 1;
RECONFIGURE;

Once this is done, Sql Server is CLR enabled. Next, you'll need to register your assembly:

CREATE ASSEMBLY [MyAssembly] AUTHORIZATION [MyUser]
FROM 'C:\CLR\MyAssembly.dll'
WITH PERMISSION_SET = SAFE

If this last script runs correctly, the assembly is now registered, and will appear in the Add References dialog.

What you will need to consider though, is the application security of your Sql Server CLR configuration:

  1. Prefer to register an assembly as SAFE, only in exceptional circumstances should you use EXTERNAL_ACCESS or UNSAFE.
  2. Don't expect to be able to do everything you can on Full-trust CLR (i.e., not the CLR hosted by Sql Server) - the SQLCLR is a sandboxed runtime.
  3. Don't try and load assemblies dynamically, as Assembly.Load() is purposefully restricted.
  4. You may need to ensure the 3rd party library is signed with a public key if you plan on using UNSAFE.
  5. Code executing runs in the context of the identity of the service running Sql Server (I think!)
  6. Database access made from a hosted assembly (e.g. via context connection = true;) runs in the context of the connected user, so you need to make sure you are aware what access that library has to your data.
share|improve this answer
    
in 4 above you writeyou have to sign the assembly. I get that part, and have been able to do it via selfsigned instructions here: geekswithblogs.net/ktegels/archive/2006/02/16/… But how to install the certificate when you don't have the private key, i.e. when assembly was created and signed by a trusted third party? As far as I can tell in the link above the creation of the certificate requires private key to be present. That seems to make this impossible? –  JorgeSandoval Apr 18 '12 at 20:55
    
Also - marking db as trustworthy is risky (and unecessary for "Safe" assembly installation). Trustworthy is one way around having to sign assemblies for external/unsafe permissions, but not recommended as any CLR assembly installed will be trusted... –  JorgeSandoval Apr 18 '12 at 21:02

I am assuming you are asking about alternatives to installing SQL CLR assemblies from Visual Studio.

Having the code in Visual Studio is not required.

Deploying CLR Database Objects on MSDN details the options, including SQL statements and deployment scripts.

share|improve this answer

I use a very large 3rd party DLL that takes a web page and converts it into a PDF.

The PDF is saved on a file share and the database is updated as to it's location and type.

This is a 3-step process:

  1. Create a console app that uses the 3rd party DLL to create the PDF and accept the URL and FilePath as parameters and returns the PDF size and number of pages.
  2. Create a CLR sproc that then calls the console app on the server
  3. I wrap this all into a single sproc that calls the CLR app to create the PDF and then I write meta-data about it to the database.

I realize this is not perfect and by no means should you do anything so crazy inside a trigger!

I only mention it here for others with questions about using 3rd Party DLL's in their CLR.

My hope is that by spinning off a cmd.exe console to run the 3rd Party DLL, instead of running everything in-proc, if it crashes, it won't adversely affect SQL Server as much. That's what I hope.

Please comment if this is a really-bad approach and why.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.