Deploying WCF Client assembly in SQL2005

Question

I'm trying to get a WCF Client assembly deploy in SQL 2005. This means I need to create/register the dependencies for my WCF Client, which are:

• System.Runtime.Serialization
• System.Web
• System.ServiceModel

With this script:

CREATE ASSEMBLY System_Runtime_Serialization FROM 'C:\Windows\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\System.Runtime.Serialization.dll'
WITH PERMISSION_SET = UNSAFE
GO

CREATE ASSEMBLY System_Web FROM 'C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Web.dll'
WITH PERMISSION_SET = UNSAFE
GO


CREATE ASSEMBLY System_ServiceModel FROM 'C:\Windows\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\System.ServiceModel.dll'
WITH PERMISSION_SET = UNSAFE
GO

Registration of System.Web.dll fails with this error message:

Assembly 'System.Web' references assembly 'system.web, version=2.0.0.0, culture=neutral, publickeytoken=b03f5f7f11d50a3a.', which is not present in the current database. SQL Server attempted to locate and automatically load the referenced assembly from the same location where referring assembly came from, but that operation has failed (reason: version, culture or public key mismatch). Please load the referenced assembly into the current database and retry your request.

Answer 1

OK, figured this out:

I think this happens because I'm on a 64-bit system. I was trying to add the 32-bit version of System.Web to a 64-bit SQL Server (and I think the 32-bit version indeed references the 64-bit version).

Anyway, for reference the working code is below:

CREATE ASSEMBLY System_Runtime_Serialization FROM 'C:\Windows\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\System.Runtime.Serialization.dll'
WITH PERMISSION_SET = UNSAFE
GO

CREATE ASSEMBLY System_Web FROM 'C:\Windows\Microsoft.NET\Framework64\v2.0.50727\System.Web.dll'
WITH PERMISSION_SET = UNSAFE
GO

CREATE ASSEMBLY System_IdentityModel FROM 'c:\Program Files\Reference Assemblies\Microsoft\Framework\v3.0\System.IdentityModel.dll'
WITH PERMISSION_SET = UNSAFE
GO
CREATE ASSEMBLY System_IdentityModel_Selectors FROM 'c:\Program Files\Reference Assemblies\Microsoft\Framework\v3.0\System.IdentityModel.Selectors.dll'
WITH PERMISSION_SET = UNSAFE
GO

CREATE ASSEMBLY System_Messaging FROM 'c:\windows\Microsoft.net\Framework\v2.0.50727\System.Messaging.dll'
WITH PERMISSION_SET = UNSAFE
GO

CREATE ASSEMBLY System_ServiceModel FROM 'C:\Windows\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\System.ServiceModel.dll'
WITH PERMISSION_SET = UNSAFE
GO

Answer 2

I had this same issue, but with a client assembly that I had written myself. A simpler solution was to recompile my assemblies with the Platform Target set to "AnyCPU" instead of "x86", thus making them acceptable for a 64 bit system running SQL Server.

1. Right click on the VS project and select Properties.
2. Click on the Build tab on the left edge of the Properties window.
3. Change Platform Target value from x86 to AnyCpu.
4. Recompile.
5. Reinstall the assembly in SQL Server.

Admittedly, this solution does not help your case where the assemblies were provided by Microsoft and cannot be recompiled, however I wanted to answer for other people with custom assemblies who might find this page useful as I did.

Answer 3

This seems to solve this issue for other people..

I just tried this exact same statement on my SQL Server 2005 SP2 installation and it worked fine. I am guessing that your .NET framework installation especially System.Web is corrupt since it is refering to itself. Can you try it on any other system or try re-installing the .NET framework

This came from MSDN and the person with the original problem said it solved the issue.

Answer 4

just to say... I'm not sure that hosting a WCF client inside SQL-Server is a particularly desirable option. There are some uses of SQL/CLR, for example if you (for whatever reason) want to use bespoke .NET types in the database, or (more likely) you want some very tightly scoped utility methods such as Split, Regex, etc. However, I wouldn't run my main app-logic (such as WCF clients) inside the SQL runtime.

The closest I might get is to have a queue table in the database, and have a windows service dequeue work, process it, and mark it completed (or delete it). This allows you to scale out such work without overloading the database.

I'm sure it might work... I just wouldn't do it myself.