Letysite.ru

IT Новости с интернет пространства
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Gac глобальный кэш сборок

Использование разделяемых сборок

C# — Сборки .NET — Использование разделяемых сборок

Установка сборок со строгими именами в GAC

Предпочитаемым способом для развертывания сборок в GAC в производственной среде является создание инсталляционного пакета Windows MSI (или применение какой-то коммерческой инсталляционной программы, подобной InstallShield), в .NET Framework 4.0 SDK поставляется работающая утилита командной строки gacutil.ехе, которой удобно пользоваться для проведения быстрых тестов.

Для взаимодействия с GAC на своей машине необходимо иметь права администратора, что может требовать внесения соответствующих изменений в параметры контроля учетных записей пользователей (UAC) в Windows Vista или Windows 7.

Ниже перечислены некоторые наиболее важные опции этой утилиты (для вывода полного списка поддерживаемых ею опций служит флаг /?):

Чтобы инсталлировать сборку со строгим именем с помощью gacutil.exe, нужно открыть в Visual Studio окно командной строки и перейти в каталог, в котором содержится библиотека fontinfo.dll, например:

Затем можно инсталлировать библиотеку с помощью опции -i:

gacutil -i fontinfo.dll

После этого можно проверить, действительно ли библиотека была развернута, выполнив следующую команду (обратите внимание, что расширение файла при использовании опции /l не указывается):

gacutil -1 fontinfo

Если все в порядке, в окне консоли должен появиться примерно такой вывод (разумеется, значение PublicKeyToken будет уникальным):

Просмотр содержимого GAC с помощью проводника Windows

С выходом версии .NET 4.0 кэш GAC был поделен на две части. В частности, в папке С: Windowsassembly теперь размещаются библиотеки базовых классов .NET 1.0 — .NET 3.5 (а также различные дополнительные сборки, в том числе библиотеки сторонних производителей). Однако при компиляции сборки в .NET 4.0 и ее развертывания в GAC с помощью gacutil.ехе она размещается в совершенно новом месте, а именно — в папке С:WindowsMicrosoft.NETassemblyGAC_MSIL.

В этой новой папке также имеется набор подкаталогов, каждый из которых именован в соответствии с дружественным именем конкретной библиотеки кода (например, System.Windows.Forms,- System.Core и т.д.). Внутри каждой папки с дружественным именем размещен еще один подкаталог, который всегда именуется по следующей схеме:

Префикс v4.0 свидетельствует о том, что библиотека компилировалась в версии .NET 4.0. После этого префикса идет один символ подчеркивания, а за ним — номер версии изучаемой сборки, каковым в рассматриваемом примере будет 1.0.0.0 для fontinfo.dll. Далее за парой символов подчеркивания следует значение маркера открытого ключа, основанное на строгом имени. На рисунке показано, как может выглядеть структура каталогов fontinfo в среде Windows XP:

Использование сборки

При создании приложений, использующих разделяемую сборку, единственным отличием от применения приватной сборки является способ, которым должна добавляться ссылка на соответствующую библиотеку в Visual Studio 2010. Фактически для этого используется тот же самый инструмент — диалоговое окно Add Reference. Однако разница в том, что в этом случае упомянутое диалоговое окно не позволяет добавить ссылку на сборку за счет нахождения нужного файла в папке С:WindowsAssembly, которая предназначена только для сборок .NET 3.5 и предшествующих версий.

Опытные разработчики приложений .NET наверняка помнят, что и раньше при переходе в папку С:Windowsassembly в диалоговом окне Add Reference внутри Visual Studio не разрешалось добавлять ссылки на разделяемые библиотеки. По этой причине приходилось создавать отдельную копию библиотеки просто для того, чтобы иметь возможность добавлять на нее ссылку. В Visual Studio 2010 дела обстоят гораздо лучше.

Если необходимо добавить ссылку на сборку, которая была развернута в GAC версии .NET 4.0, на вкладке Browse необходимо перейти в представляющий нужную библиотеку каталог по имени v4.0_major.minor.build.revision_publicKeyTokenValue, как показано на рисунке. С учетом этого немного сбивающего с толку факта, давайте создадим новый проект типа Console Application и добавим в него ссылку на сборку fontinfo только что описанным образом. Как и следовало ожидать, после этого в папке References внутри окна Solution Explorer появится соответствующий значок. Выделив этот значок и выбрав в меню View (Вид) пункт Properties (Свойства), в окне Properties можно увидеть, что свойство Copy Local (Локальная копия) теперь установлено в False.

Несмотря на это, добавим в новое клиентское приложение следующий тестовый код:

Если теперь скомпилировать это клиентское приложение и с помощью проводника Windows перейти в каталог, в котором содержится файл Program.exe, то можно будет увидеть, что среда Visual Studio 2010 не скопировала fontinfo.dll в каталог клиентского приложения. Объясняется это тем, что при добавлении ссылки на сборку, в манифесте которой присутствует значение .publickey, Visual Studio 2010 считает, что данная обладающая строгим именем сборка, скорее всего, будет развертываться в GAC, и потому не заботится о копировании ее двоичного файла.

Исследование манифеста SharedCarLibClient

Вспомните, что при генерировании строгого имени для сборки в ее манифест записывается открытый ключ. В связи с этим, когда в клиентское приложение добавляется ссылка на строго именованную сборку, в ее манифест записывается и компактное хеш-значение всего открытого ключа в маркере .publickeytoken. Поэтому, если открыть манифест Program.exe в утилите ildasm.exe, можно увидеть там следующий код (разумеется, значение открытого ключа в маркере .publickeytoken будет выглядеть по-другому):

Если теперь сравнить значение открытого ключа, записанного в манифесте клиента, и отображаемого в GAC, то легко обнаружить, что они совпадают. Как упоминалось ранее, открытый ключ является одной из составляющих идентификационных данных строго именованной сборки. Из-за этого CLR-среда будет загружать только версию 1.0.0.0 сборки по имени fontinfo, из открытого ключа которой может быть получено хеш-значение DC473F9D2D5D12C3. В случае невозможности обнаружить сборку, соответствующую такому описанию в GAC (и приватную сборку по имени fontinfo в каталоге клиента), будет сгенерировано исключение FileNotFoundException.

Создание пакетов установки

Глобальный кэш сборок GAC (Global Assembly Cache). Утилита gacutil.exe

Глобальный кэш сборок (Global Assembly Cashe , GAC) — это хранилище сборок, одновременно используемых несколькими приложениями. Такие сборки называются публичными. GAC может содержать в себе несколько сборок, отличающихся друг от друга только версией. На вашем компьютере GAC находится в каталоге C:WINDOWSassembly (рис. 9.15).

Читать еще:  Ноут asus как войти в биос

Все сборки, находящиеся в GAC, подписаны строгим именем — при установке сборки среда Common Language Runtime проверяет сборку на уникальность и сравнивает ее с другими, уже имеющимися сборками.

Управлять глобальным хранилищем сборок можно несколькими способами. Первый способ — с помощью утилиты gacutil.exe, файл которой располагается в папке CProgram FilesMicrosoft Visual Studio .NET 2003SDKv1.1Bin gacutil.exe. Для работы с ней, как и большинством других утилит в командной строке Visual Studio.NET, следует ввести

При этом появляется описание команд утилиты (рис. 9.16), среди которых нас интересуют всего три:

Управление сборками при помощи утилиты gacutil.exe — не самый удобный способ. Более широкие возможности управления сборками предоставляет консоль MMC (Microsoft Management Console), для запуска которой в окне Выполнить (Run) набираем mmc (рис. 9.17).

В появившемся окне выбираем в меню «КонсольДобавить или удалить оснастку …» (рис. 9.18).

Оснасткой называется основной тип инструментов, которые можно добавить на консоль. В данном случае оснасткой будет глобальный кэш сборок. В окне «ДобавитьУдалить оснастку» нажимаем кнопку «Добавить» и в появившемся списке выбираем .NET Framework 1.1 Configuration (рис. 9.19).

В открывшемся окне можно управлять сборками — добавлять их или удалять (рис. 9.20).

Не удаляйте сборки, которые вам неизвестны, — вы можете нарушить работоспособность некоторых программ!

Вопросы и ответы

При нажатии на Сумма в примере ArbitraryMethod из Лекция 7, VS 2013 выдается ошибка:

Необработанное исключение типа «System.InvalidOperationException» в System.Windows.Forms.dll

Дополнительные сведения: Недопустимая операция в нескольких потоках: попытка доступа к элементу управления «lblResult» не из того потока, в котором он был создан.

Затем:

Необработанное исключение типа «System.InvalidOperationException» в mscorlib.dll

Дополнительные сведения: Для каждой асинхронной операции метод EndInvoke может вызываться только один раз.

Свойство WindowState формы blank Maximized. Не открывается почемуто на всё окно, а вот если последующую форму бланк открыть уже на макс открывается :-/

Gac глобальный кэш сборок

Общие сборки и GAC

Общие сборки .NET хранятся в глобальном кэше сборок (GAC). Наличие глобального кэша экономит дисковое пространство и память, поскольку на стадии выполнения программы на диске или в памяти достаточно хранить лишь один экземпляр сборки. Конечно, при совместном использовании сборок возникают некоторые проблемы, присущие старому механизму совместного использования DLL на базе реестра. К счастью, средства контроля версии .NET позволяют хранить в GAC разные версии одной сборки, поэтому каждое приложение может использовать нужную версию. Постарайтесь как можно реже использовать глобальный кэш сборок и ограничиться следующими ситуациями:

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

Список сборок, находящихся в GAC, выводится утилитой gacutil.exe из каталога bin .NET SDK. Команда имеет следующий синтаксис: gacutil.exe -1

Ниже приведено начало списка для одного из наших компьютеров. Полный список имеет внушительные размеры; даже на этой ранней стадии существования .NET он занимает около трех страниц:

Microsoft (R).NET Global Assembly Cache Utility.Version 1.0.2914.16

Copyright (C)Microsoft Corp,1998-2001,All rights reserved.

The Global Assembly Cache contains the following assemblies:

Crystal Deci si ons.Crystal

Для общих сборок контроль версии играет гораздо более важную роль, чем для закрытых сборок, поэтому в списке указаны номера версий каждой сборки. Последнее из Четырех чисел в номере версии определяет номер ежедневного построения, изменение которого считается непринципиальным. Далее следует номер ревизии, изменение которого тоже считается непринципиальным. Изменения следующих двух чисел (дополнительного и основного номеров) принципиальны. Это означает, что если программа запрашивает сборку версии 2.0.0.0, а в GAC находится только версия 2.5.0.0, программа не будет работать, если не внести специальные изменения в конфигурационный файл. С другой стороны, версия 2.0.0.37 считается совместимой с версией 2.0.0.0 и успешно загружается.

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

Включение и удаление сборок из GAC

Чтобы общая сборка автоматически включалась в GAC в процессе установки, проще всего воспользоваться программой установки с поддержкой GAC — например, последней версией пакета Microsoft Installer (MSI). Описание этой программы выходит за рамки книги, но мы укажем, что эту программу можно бесплатно загрузить с сайта MSDN ( http://msdn.microsoft.com) .

На стадии разработки вместо программы установки обычно используется утилита

gacutil.exe. Синтаксис командной строки:

Сборка с заданным именем помещается в GAC.

Сильные имена и совместное использование сборок

Сильные имена, как и GUID, должны быть уникальными в пространстве и времени. В отличие от GUID, которые теоретически могут быть похищены, сильные имена защищены от несанкционированного использования при помощи механизма шифрования с открытым ключом [ При условии надежного хранения закрытого ключа. ]. Конкретные схемы шифрования бывают очень сложными, однако в целом шифрование с открытым ключом построено на довольно простой идее — в некоторых ситуациях вернуться от конечного результата к исходным данным бывает очень, очень сложно. Например, вы можете легко перемножить два целых числа и получить результат, но узнать исходные множители по произведению невозможно — для этого нужно знать хотя бы один из них [ Этот принцип заложен в основу RSA, распространенного алгоритма шифрования с открытым ключом. ].

Внутренняя реализация выглядит следующим образом: на основании всей информа-ции, содержащейся в сборке, .NET вычисляет хэш-код и применяет к нему закрытый ключ. Результатом является зашифрованный хэш-код. Поскольку схема шифрования должна обеспечивать возможность восстановления зашифрованных данных, зашифрованный хэш-код расшифровывается при помощи открытого ключа, при этом получается исходный хэш-код. На последнем шаге хэш-код заново вычисляется на основании данных, содержащихся в манифесте, и два числа сравниваются. Если хэш-коды не совпадают, значит, сборка была модифицирована, и .NET отказывается загружать ее.

Читать еще:  Скорость кулера в биосе

Во всех схемах с открытым ключом используется пара ключей: открытый и закрытый. Открытый ключ (public key) может свободно распространяться, поскольку без знания закрытого ключа зашифрованное сообщение невозможно восстановить за сколько-нибудь приемлемый промежуток времени. Применение закрытого ключа к данным манифеста позволяет сертифицировать их. Другие пользователи при помощи открытого ключа убеждаются в том, что сборка поступила именно от вас, а не из постороннего источника. А в некоторых случаях (например, при использовании Verisign) они даже могут убедиться в том, что открытый ключ принадлежит именно вам, а не кому-то другому (шифрование с открытым ключом защищает целостность данных, но для проверки открытого ключа необходимы услуги третьей стороны).

Сборки .NET, установка приложений и COM Interop

В завершение мы решили остановиться на проблемах установки и размещения программ, а также на использовании готовых программ, использующих модель COM (Component Object Model). Вообще-то на эту тему можно написать целую книгу, но мы надеемся, что это короткое вступление поможет вам перейти к самостоятельному изучению этой темы.

Установка большинства приложений .NET сводится к простому копированию каталога, содержащего необходимые файлы, на любой компьютер с установленной исполнительной средой .NET. Программа запускается двойным щелчком на имени ЕХЕ-файла в окне Проводника (Windows Explorer).

Выбирая значок Setup and Deployment Project в диалоговом окне New Project, вы получите доступ к весьма нетривиальным возможностям установки. Мастер Setup Wizard чрезвычайно прост в использовании, но для большинства стандартных ситуаций его возможностей оказывается вполне достаточно.

Тем не менее даже в .NET иногда встречаются ситуации, когда простое копирование не подходит, а программа-мастер слишком ограничивает вашу свободу действий. Чтобы разобраться в принципах установки приложений .NET, необходимо знать, как работают сборки (assemblies), поскольку приложения .NET распространяются в виде сборок.

Во многих устанавливаемых приложениях хотя бы часть работы выполняется традиционными объектами СОМ, поэтому в этой главе будут кратко затронуты вопросы использования объектов СОМ в .NET [И наоборот — объекты .NET могут использоваться в СОМ, однако эта возможность выглядит несколько экзотически.]. А поскольку одной из целей разработки .NET было исправление недостатков СОМ, мы начнем с краткого обзора СОМ и основных проблем, связанных с этой технологией.

Принципы работы СОМ

Технология СОМ упрощает создание программ, сохраняющих совместимость в разных версиях платформы Windows и более или менее независимых от языка программирования. Компоненты СОМ могут создаваться на разных языках, включая классический С (вариант для мазохистов), C++, Delphi, VB5 и 6. Технология СОМ с большим успехом применялась для создания объектов, предназначенных для решения специализированных задач, таких как элементы VB OCX.

Технология СОМ была задумана как механизм, при помощи которого программные компоненты получают информацию о возможностях других компонентов и обращаются к ним с запросами, не беспокоясь о подробностях внутренней реализации [Существуют и другие технологии, ориентированные на повторное использование программного кода (например, CORBA), но пока наибольшего успеха добилась именно модель СОМ.]. Для этого был выработан стандартный протокол получения информации об интерфейсах, поддерживаемых другими компонентами, наряду со стандартизацией средств для обращения к конкретной реализации интерфейса в экземплярах.

Тем не менее у СОМ были свои недостатки. Во-первых, реализация СОМ для Windows требовала, чтобы в системном реестре хранилась вся информация обо всех компонентах в системе. Пользователю приходилось регистрировать компоненты при установке программ и стирать соответствующую информацию при удалении программ. При попытке удаления программ возникала опасность того, что изменения, внесенные в реестр, повлияют на работу других программ. Стоило серьезно повредить реестр, и система вообще переставала работать. Более того, установка новой версии компонента нередко нарушала работу программ, рассчитанных на более раннюю версию компонента.

В Windows 98 была впервые представлена концепция параллельного выполнения (side-by-side execution); это означало, что приложение могло использовать локальный экземпляр компонента СОМ, находящийся в каталоге приложения, вместо экземпляра, зарегистрированного в системе. Справедливости ради следует сказать, что параллельное выполнение так и не решило проблемы с «кошмаром DLL», вдобавок оно работает только в Windows 98, 2000 и ХР — и то если об этом специально позаботится разработчик программы.

Давайте посмотрим, что происходит на уровне реестра при регистрации компонентов СОМ.

  1. Разработчик создает для компонента глобально-уникальный идентификатор (GUID).
  2. Разработчик создает для компонента программный идентификатор (ProgID).
  3. Утилита регистрации связывает ProgID компонента с GUID, создавая соответствующую запись в реестре.
  4. Утилита регистрации заносит полный путь к двоичному файлу компонента в реестр и связывает его с GUID компонента.
  5. Утилита регистрации также может сохранить в реестре дополнительные сведения о компоненте — например, тип потоковой модели.

При попытке использования компонента происходит следующее:

  1. Разработчик приложения создает экземпляр компонента, используя ProgID.
  2. СОМ ищет в реестре GUID компонента.
  3. СОМ находит двоичный файл компонента.
  4. СОМ создает экземпляр компонента.

Несмотря на большое количество выполняемых операций, главные проблемы возникают при копировании в систему нового файла с компонентом, не сопровождающимся обновлением реестра, и при смене GUID. Приложение, которое раньше благополучно работало, работать перестает. Это связано с тем, что в механизме установки СОМ не предусмотрено нормальных средств для контроля версии компонентов.

Как было сказано в начале этой главы, процесс установки в .NET часто сводится к простому копированию файлов, после чего программа готова к немедленному запуску. Если удалить скопированные файлы, то работать перестает только эта конкретная программа. В этом процессе не используется реестр и не учитываются зависимости между компонентами. Чтобы эта схема нормально работала, в .NET используется концепция сборки.

С технической точки зрения сборка (assembly) в .NET представляет собой минимальную устанавливаемую единицу программного кода. Сборка оформляется в виде автономного ЕХЕ-файла или в виде библиотеки DLL, на которую можно ссылаться из других приложений. Однако сборка содержит нечто большее, чем обычный IL-код, компилируемый и выполняемый исполнительной средой .NET. Как минимум, сборка состоит из одного или нескольких модулей и классов, откомпилированных в IL-код, и метаданных (данных, описывающих данные [Префикс «мета» для подобных абстракций второго порядка позаимствован из метаматематики — области математики, посвященной описанию самих математических объектов.]), которые описывают сборку и функциональность входящих в нее классов. Метаданные являются частью сборки, поэтому в документации сборки названы самодокументируемыми. Во многих ситуациях сборка состоит из одного файла, но встречаются и многофайловые сборки. Например, в сборку могут входить ресурсные файлы, графические изображения и даже дополнительные EXE/DLL-файлы. В любом случае сборка является минимальным объектом .NET, для которого производится контроль версии или задаются привилегии.

Читать еще:  Ноут asus зайти в биос

В большинстве случаев создаются однофайловые сборки, состоящие из одного ЕХЕ-или DLL-файла.

Сборки бывают закрытыми (private) и общими (shared). Закрытые сборки всегда находятся в каталоге приложения или в одном из его подкаталогов. Общие сборки хранятся в глобальном кэше сборок (GAC, global assembly cache). Начнем с закрытых сборок, поскольку именно они используются по умолчанию для решений, построенных в VS .NET IDE. С общими сборками дело обстоит сложнее, и мы займемся ими позже.

Обычно у закрытых сборок не бывает проблем с несовместимостью версий, однако они требуют дополнительных затрат дискового пространства, если в системе приходится хранить несколько копий одного файла в разных каталогах [В наше время дисковое пространство обходится так дешево, что эти затраты с избытком компенсируются удобствами, связанными с использованием закрытых сборок.]. При создании ссылок на сборку командой Project > Add Reference по умолчанию в каталоге приложения создается новый экземпляр закрытой сборки. Мы рекомендуем по возможности ограничиваться использованием закрытых сборок.

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

Теоретически сборка может быть устроена весьма сложно, поэтому в нее включается манифест — совокупность всех сведений о сборке, необходимых исполнительной среде (CLR) для загрузки, компиляции (при необходимости) и выполнения сборки. В манифест входят следующие сведения:

  • информация, необходимая для поиска модулей, от которых зависит работа сборки;
  • имена всех файлов, входящих в сборку;
  • имена и метаданные всех сборок и файлов, используемых сборкой;
  • данные о версии сборки;
  • информация о типах, используемая исполнительной средой для экспортирования типов из сборки (по аналогии с информацией, находящейся в библиотеке типов СОМ).

Именно благодаря наличию манифеста появляется возможность создания сборок, состоящих из нескольких файлов. Кроме того, данные манифеста заменяют сложную систему регистрации компонентов в реестре. Первое представление о сборке и ее манифесте дает файл Assemblylnfo.vb; чтобы просмотреть содержимое этого файла, дважды щелкните на соответствующей строке окна решения VS .NET. Как видно из приведенного ниже примера, этот текстовый файл содержит многочисленные атрибуты сборки. Большинство атрибутов (например, название организации) можно редактировать вручную, хотя чаще значения задаются в IDE при помощи диалоговых окон свойств проекта.

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

‘Review the values of the assembly attributes

Установка сборки в GAC с gacutil.exe

есть сборка с названиям: MyAssebly.dll находится: D:MyAssebly.dll

питаюсь закинуть ее в GAC:
D:>gacutil.exe /i MyAssembly.dll

не получается((((
что не так делаю.

Установка сборки в GAC Windows 7
Не удаётся установить сборку в папку assembly. Пробовал перетаскиванием .dll файла, пишет отказано.

Командная строка не находит GACUTIL.EXE
Привет ребята! Хочу закинуть CarLibrary.dll в GAC, а тут

Запуск из сборки другой сборки(exe)
У меня есть одна большая программа(windows forms) и вторая поменьше(win forms). По нажатию кнопки.

Перенаправление версий сборки. Приложение не читает .exe.config
Всем привет. Читаю Э.Троелсена дошел до главы где он объясняет как перенаправить версию сборки от.

Для начала следует написать, что выводит консоль.

вот что я прописал^^^

Добавлено через 27 секунд
на диске Д єсть: gacutil.exe

И зачем Вы его туда скопировали? Вызывайте из того места где он находится (MS SDK’s по умолчанию), зачем его куда-то копировать?

Регистрация подписанной сборки:

а как проверить єсть ли права админа?

Добавлено через 4 минуты

Добавлено через 1 минуту
This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.
как ето понять?
оно хочет другую версию сборки?

Ребята, столкнулся с такой же проблемой.

Пишет
C:UserskavDocumentsVisual Studio 2012ProjectsConsoleApplication2ConsoleApplication2binDebug>sn.exe -T Abstract.dll

Microsoft (R) .NET Framework Strong Name Utility Version 3.5.30729.1
Copyright (c) Microsoft Corporation. All rights reserved.

Public key token is 2350a0854aae3bb2

C:UserskavDocumentsVisual Studio 2012ProjectsConsoleApplication2ConsoleApplication2binDebug>gacutil -i Abstract.dll
Microsoft (R) .NET Global Assembly Cache Utility. Version 3.5.30729.1
Copyright (c) Microsoft Corporation. All rights reserved.

Failure adding assembly to the cache: This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.

Права администратора есть. Версия .NET на компе 4.5.1. Установление версии в сборке с 4.5.1 на 4.0 (с перекомпиляцией и переподписанием ничего не дает). Visual Studio 2012. Win7 Enterprise

Добавлено через 1 час 28 минут
Все получилось сделать с первого раза из Developer Command Prompt. Как я понял, чего-то нехватало Gacutil.exe когда я запускал её из обычной командной строки.

Добавлено через 9 минут
в MSDN так и написано : «To run the tool, use the Developer Command Prompt (or the Visual Studio Command Prompt in Windows 7). «

Тогда сразу следующий вопрос: а как регить в GAC расшаренную dll на компьютере пользователя?

Ссылка на основную публикацию
Adblock
detector