2012-06-26 2 views
4

У меня есть проект CLR, который вызывает простой HTTP-сервис HTTP. Его x64-таргетинг, и я получил его для правильной сериализации, только пройдя шаги, описанные в следующей ссылке, в которой говорится об изменениях, необходимых для того, чтобы VS2010 указывал на правильную целевую архитектуру (x64) - изменения, которые требуется только для разгрузки и изменения. csproj файл с несколькими дополнительными строками для ссылки на правильную версию sgen.exe: http://geekswithblogs.net/akraus1/archive/2011/12/10/148002.aspxСериализованная сборка не будет загружена в базу данных

Теперь я могу построить этот проект и его .XmlSerializers.dll, установив «Генерировать сериализованную сборку» на. Я хочу сделать это, потому что мой проект CLR будет развернут в базе данных, и я не хочу, чтобы он запускал сериализацию любых объектов, поскольку эти DLL не ссылаются в моей базе данных, и я не хочу предоставлять свои права на проект CLR выше, чем EXTERNAL_ACCESS по соображениям безопасности, потому что это будет использоваться в производственной среде, где важна безопасность, а также потому, что моя база данных НЕ заслуживает доверия.

Короче говоря, я следую руководство по следующей ссылке, чтобы загрузить мой сериализованную сборку в базу данных, но я получаю сообщение об ошибке: http://footheory.com/blogs/bennie/archive/2006/12/07/invoking-a-web-service-from-a-sqlclr-stored-procedure.aspx

Ошибка: CREATE ASSEMBLY для сборки».XmlSerializers' не удалось из-за сборка построена для неподдерживаемой версии Common Language Runtime.

Кто-нибудь знает, как исправить это, заставив sgen.exe сериализовать версию сборки, поддерживающую CLR? Viva the Stack.

ответ

2

Я обнаружил, что проблема на самом деле не в том, что я использую .NET 3.5 в качестве цели, но я ссылался на неправильную версию инструмента sgen.exe, которая в этом случае мне нужна была версия x64 6.0A (что соответствует .NET 3.5) на этом пути: C: \ Program Files \ Microsoft SDK \ Windows \ v6.0A \ Bin \ x64 \ sgen.exe. Теперь я могу создать правильную версию сборки сериализации, загрузить ее, а также использовать ее.

2

SQL Server 2005/2008/2008R2 поддерживает только .Net 2.0. Вам нужно изменить свой проект, чтобы настроить его, см. How to: Target a Specific .NET Framework Version or Profile. Вы делаете не необходимо указать x64 для цели сборки, сборки SQLCLR должны быть общими целевыми.

Сказанное, вызов веб-служб от SQLCLR - это действительно действительно плохая идея. Не делай этого. Попросите внешний процесс обрабатывать вызовы HTTP.

+1

Я обнаружил, что проблема на самом деле не в том, что я использую .NET 3.5 в качестве цели, но я ссылался на неправильную версию инструмента sgen.exe, которая в этом случае мне нужна версия x64 6.0 A (который переводит на .NET 3.5) по этому пути: C: \ Program Files \ Microsoft SDK \ Windows \ v6.0A \ Bin \ x64 \ sgen.exe. Теперь я могу создать правильную версию сборки сериализации, загрузить ее, а также использовать ее. – Alexandru

+0

Кроме того, я бы не сказал, что это плохая идея, чтобы CLR вызывал .NET Web Service. Я ограничиваю свой CLR для запуска под учетной записью пользователя с разрешениями EXTERNAL_ACCESS. DLL подписана с сильным именем, а учетная запись пользователя сопоставляется с асимметричным ключом для этой DLL. Это очень безопасно. В базу данных необходимо было импортировать только два файла DLL: CLR и DLL сериализации для CLR, что помогает сериализовать сгенерированный прокси-класс с помощью инструмента wsdl, в котором я сохранил только конструктор и синхронные методы. Его страшно, насколько это безопасно. – Alexandru

+0

Поскольку DLL содержит веб-ссылку, файлы DLL, которые он загружает, уже поддерживаются MSSQL Server, поэтому мне не нужно было импортировать другие DLL-файлы, как если бы вы создавали прокси-сервер для службы WCF. Кроме того, единственным неудачным недостатком для меня, использующего x64 в качестве целевой архитектуры, было то, что мне пришлось вручную ссылаться на сборки для x64, чтобы мой проект мог построить, выгружая его и редактируя файл .csproj. – Alexandru

Смежные вопросы