У якомусь коді C #, який я взяв (у Visual Studio 2005), я помітив, що всі збірки підписані одним .snkфайлом.
Відповіді:
Чому попередній автор таким чином підписав збори?
Не маю ідеї, можливо, він хотів, щоб усі його збори були підписані одним ключем.
Чи потрібне підписання асамблей і що було б не з його підписанням?
Ні, це не обов'язково, але це механізм, що дозволяє вам забезпечити справжність збірки. Це дозволяє переконатися, що збірка не була підроблена і вона походить від цього автора. Це також необхідно, якщо ви хочете помістити їх у GAC.
Які недоліки є у підписання зборів - це спричиняє затримки?
Підписані збори можуть завантажувати лише інші підписані збори. Крім того, вони прив’язані до певної версії, що означає, що вам потрібно використовувати перенаправлення прив’язки або перекомпілювати додаток, якщо ви хочете використовувати іншу версію. Невеликі результати роботи також пов'язані з підтвердженням підпису, але це так мало, що вас не повинно турбувати.
Вам потрібно підписати збірки, якщо ви хочете помістити їх у GAC .
Якщо ви підписуєте виконуваний файл, то будь-які бібліотеки класів, на які він посилається, також повинні бути підписані. Це може бути складно, якщо ви використовуєте сторонні бібліотеки (особливо якщо вам потрібно використовувати елемент управління ActiveX або подібне).
Річард Грімс написав хороший семінар з питань безпеки в .NET, який включає в себе розділ про це: Семінар з безпеки
Причиною того, що всі збірки будуть підписані одним і тим же .snk-файлом, може бути, якщо він використовував тестування одиниць із покриттям коду. Щоб мати можливість охопити код (принаймні, за допомогою інструментів, вбудованих у тестувальну версію Visual Studio 2005) та якщо збірки підписані, вам потрібно вказати, які .snk файли використовуються для підписання, але, думаю, ви можете лише вкажіть один .snk-файл для всього рішення, тому якщо ви підписуєте різні бібліотеки класів з різними .snk-файлами, ви можете одночасно перевіряти покриття коду на одному з них.
Дуже важлива причина підписання зборів - це ви можете бути впевнені, що це ваша збірка. Оскільки приватний ключ ваш, ніхто більше не може підписати збірку з цим самим ключем. Це означає, що коли відкритий ключ збірки - це той, кого ви знаєте (ви можете отримати це за допомогою GetType().Assembly.GetName().GetPublicKey()функції), збірка є вашою, і вона не була підроблена.
Незважаючи на всі звичаї підписання dll, dll слід підписувати лише з двох причин
1. Версія
2. Аутентифікація
а. Версія позначає, на якій версії побудовано dll, і при натисканні на них у GAC два dll з тим самим іменем можуть існувати, але інша версія
б. Автентифікація позначає, чи DLL не підроблений і чи існує той самий, коли він був створений.
Якщо ви хочете дізнатися більше про основи та підписання dll, ви можете посилатися тут
На додаток до існуючих відповідей, я хотів би додати, що ви повинні використовувати підпис, коли ваша DLL буде динамічно завантажена та споживана стороннім програмним забезпеченням. Сама по собі не є технічною вимогою, але є раціональною, тому дуже поширеною, щоб сторонній виробник програмного забезпечення здійснював таку політику з огляду на безпеку.
Приклади, коли потрібно підписати збірку: