У меня есть проект 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.
Я обнаружил, что проблема на самом деле не в том, что я использую .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
Кроме того, я бы не сказал, что это плохая идея, чтобы CLR вызывал .NET Web Service. Я ограничиваю свой CLR для запуска под учетной записью пользователя с разрешениями EXTERNAL_ACCESS. DLL подписана с сильным именем, а учетная запись пользователя сопоставляется с асимметричным ключом для этой DLL. Это очень безопасно. В базу данных необходимо было импортировать только два файла DLL: CLR и DLL сериализации для CLR, что помогает сериализовать сгенерированный прокси-класс с помощью инструмента wsdl, в котором я сохранил только конструктор и синхронные методы. Его страшно, насколько это безопасно. – Alexandru
Поскольку DLL содержит веб-ссылку, файлы DLL, которые он загружает, уже поддерживаются MSSQL Server, поэтому мне не нужно было импортировать другие DLL-файлы, как если бы вы создавали прокси-сервер для службы WCF. Кроме того, единственным неудачным недостатком для меня, использующего x64 в качестве целевой архитектуры, было то, что мне пришлось вручную ссылаться на сборки для x64, чтобы мой проект мог построить, выгружая его и редактируя файл .csproj. – Alexandru