c# - можете ли вы сделать слабую ссылку на сборку со строгой именованной сборкой

По разным причинам я бы предпочел не использовать сборки со строгими именами (подписанные) в своем проекте. однако на один из проектов ссылается веб-часть SharePoint, что означает, что он должен быть подписан.

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


person Tim    schedule 22.03.2010    source источник


Ответы (3)


Самый простой способ сделать это, вероятно, состоит в том, чтобы иметь две разные конфигурации проекта, одна из которых создает сборку со строгим именем, а другая — нет. Очевидно, вам нужно быть осторожным при сборке и ссылке на сборку, но это связано с наличием противоречивых требований.

person Jon Skeet    schedule 22.03.2010

Просто продолжайте создавать свой проект без громких имен. Когда вам нужно развернуть его в Sharepoint, используйте инструмент, чтобы подписать его после его сборки. Вот инструмент, который делает именно это:

http://signer.codeplex.com/Wikipage

Вы также можете сделать это вручную, но это PITA:

http://buffered.io/posts/net-fu-signing-an-unsigned-assembly-without-delay-signing/

person Fábio Batista    schedule 08.04.2010

Это OP, но у меня нет логина OpenID, поэтому я не могу ответить от своего имени.

Спасибо за оба ответа. Я думаю, что любой из них сработал бы, но ситуация оказалась немного сложнее. Я задокументировал свои выводы здесь, если кому-то еще интересно.

На самом деле sharepoint ссылается на сборку A, а сборка A, в свою очередь, ссылается на сборку B.

Я могу без проблем собрать сборки A и B без подписи, но затем, если я хочу подписать A, мне придется изменить сам проект, чтобы он ссылался на подписанную версию сборки B.

Хотя, возможно, существовал способ сделать это, мы решили, что возможные конфликты DLL и проблемы управления конфигурацией, связанные с наличием разных наборов DLL с одинаковыми именами, не стоят хлопот.

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

Тим

person Tim    schedule 08.04.2010