Развертывание сборки клиента WCF в SQL2005

Question

Я пытаюсь развернуть сборку клиента WCF в SQL 2005. Это означает, что мне нужно создать / зарегистрировать зависимости для моего клиента WCF, а именно:

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

С помощью этого скрипта:

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

Регистрация System.Web.dll завершается с этим сообщением об ошибке:

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

ОК, разобрался:

Я думаю, это происходит из-за того, что я работаю в 64-битной системе. Я пытался добавить 32-разрядную версию System.Web к 64-разрядному SQL Server (и я думаю, что 32-разрядная версия действительно ссылается на 64-разрядную версию).

Во всяком случае, для справки рабочий код ниже:

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

У меня была такая же проблема, но с клиентской сборкой, которую я написал сам. Более простым решением было перекомпилировать мои сборки с установленным для платформы Platform Target значением «AnyCPU» вместо «x86», что сделало их приемлемыми для 64-разрядной системы с SQL Server.

1. Щелкните правой кнопкой мыши проект VS и выберите Свойства.
2. Нажмите на вкладку «Сборка» в левой части окна «Свойства».
3. Измените целевое значение платформы с x86 на AnyCpu.
4. Рекомпилированные.
5. Переустановите сборку в SQL Server.

Правда, это решение не помогает вашему случаю, когда сборки были предоставлены Microsoft и не могут быть перекомпилированы, однако я хотел бы ответить для других людей с пользовательскими сборками, которые могут найти эту страницу полезной, как я.

Answer 3

просто чтобы сказать ... Я не уверен, что размещение клиента WCF внутри SQL-сервера является особенно желательным вариантом. Существует несколько вариантов использования SQL / CLR, например, если вы (по какой-либо причине) хотите использовать заказные типы .NET в базе данных или (что более вероятно) вам нужна какая-то очень ограниченная утилита методы, такие как Split, Regex и т. Д. Однако я не запускаю основную логику приложения (например, клиенты WCF) в среде выполнения SQL.

Самое близкое, что я мог бы получить - это иметь таблицу очередей в базе данных, и заставить службу Windows работать в режиме очереди, обрабатывать ее и помечать как завершенную (или удалять). Это позволяет вам масштабировать такую ​​работу, не перегружая базу данных.

Я уверен, что это может сработать ... Я бы просто не сделал это сам.

Answer 4

Это, похоже, решает эту проблему для других людей ..

Я только что попробовал точно такой же оператор при установке SQL Server 2005 с пакетом обновления 2 (SP2), и он работал нормально. Я предполагаю, что ваша установка .NET Framework, особенно System.Web, повреждена, поскольку она ссылается на себя. Можете ли вы попробовать это в любой другой системе или попробуйте переустановить .NET Framework

Это пришло из MSDN, и человек с исходной проблемой сказал, что решил проблему.