Как препятствовать тому, чтобы dll был загружен в других приложениях
в настоящее время я разрабатываю приложение C#.Net, в котором я использую пользовательский элемент управления, который я разработал некоторое время назад. Мне нужен dll, который будет поставлен в рамках нового приложения - но понятно я не хочу, чтобы dll файл использовался для внешних приложений.
Вот почему мне нужен пользовательский dll, который будет так или иначе скомпилирован в рамках нового приложения. В настоящее время dll копируется в каталог приложения.
Какие-либо идеи? Должно быть тривиальным, по моему скромному мнению.
Спасибо и отношения, Daniel
4 ответа
Я думаю, что вам нужно рассмотреть вопрос о лицензировании вашего элемента управления (элементов управления): http://msdn.microsoft.com/en-us/library/fe8b1eh9.aspx
Есть несколько различных уловок, которые вы можете сделать, чтобы людям было сложнее использовать это. Их все можно обойти, но такова жизнь.
Вы можете посмотреть этот ответ здесь, чтобы запретить неизвестной сборке ссылаться на вашу сборку: Защищайте сборки C # от неавторизованных вызывающих лиц
Если вы действительно нервничаете по этому поводу, вам следует запутать вашу сборку. Это затруднит декомпилирование . Что-то вроде Babel отлично работает: http://babelobfuscator.blogspot.com/
Вы также можете использовать ILMerge для хранения сборки в другой сборке. Однако эта сборка будет извлечена и представлена во время выполнения. Вы можете сделать что-то в этом роде, чтобы извлечь двоичный ресурс из одной сборки и создать временную сборку, которая будет использоваться во время выполнения. Если кто-то действительно заинтересован, он может найти и временное собрание ...
Настоящий вопрос в том, как далеко вы хотите зайти !? В какой-то момент оно того не стоит. Вот где вы остановились.
Рассмотрите IL Merge. Эта утилита позволяет объединить несколько сборок .NET в одну сборку.
Цитирую:
ILMerge - это утилита, которую можно использовать для объединения нескольких сборок .NET в одну сборку. ILMerge берет набор входных сборок и объединяет их в одну целевую сборку. Первая сборка в списке входных сборок является первичной сборкой. Если первичная сборка является исполняемым файлом, то целевая сборка создается как исполняемый файл с той же точкой входа, что и первичная сборка. Также, если первичная сборка имеет сильное имя, и предоставлен файл .snk, то целевая сборка переподписывается указанным ключом, чтобы она также имела сильное имя.
Однако следует учитывать, что люди все равно могут использовать созданную сборку. Подумайте об обфускации и лицензировании, чтобы удержать легковерных на расстоянии, но помните, что если кто-то достаточно сильно захочет получить ваш код, он его получит.
Некоторые вещи делают это намного сложнее, например, наличие веб-службы, но даже тогда это не является полным доказательством.
Если вы можете изменить DLL с помощью проприетарного элемента управления, вы можете ...
- Отметить все в управляющей DLL как внутреннее.
- Скомпилируйте вашу сборку так, чтобы вызывающая DLL имела доступ к внутренним членам вашей управляющей DLL.
- Подпишите вызывающую DLL.
См. Эту страницу MSDN для получения подробной информации о том, как это сделать.