Аннотация:
При проектировании платформы .NET одной из задач являлось легкое развёртывание (инсталляция) и поддержка приложений, так как в настоящее время эта проблема стала серьезно беспокоить не только разработчиков, но и рядовых пользователей. Наверное, каждый знаком с ситуацией, когда после установки новой программы некоторые старые приложения наотрез отказывались работать. Ниже я вам поведаю о том, какое решение данной проблемы предоставила Microsoft на этот раз.
Здравствуйте, der Igel, Вы писали:
DI>Hello, MNZ!
M>> Интересная, подробная статья. Обо всём в одном месте. Только некоторые M>> запятые стоят не на своих местах
DI>А там вверху, в левом угле, кнопочка такая есть — Орфо.
Дык, Орфографию оно проверяет. А запятые -- это пунктуация.
К тому же, проблемы написания слитно-раздельно, тоже надо учитывать.
Цитирую:
Если быть до конца честным, то мы конечно же не вызвали данную функцию, на прямую.
Hello, Spaider!
DI>> А там вверху, в левом угле, кнопочка такая есть — Орфо.
S> Дык, Орфографию оно проверяет. А запятые -- это пунктуация. S> К тому же, проблемы написания слитно-раздельно, тоже надо S> учитывать.
И орфографию, и пунктуацию посетители проверяют, а не конопочка.
Ты выдели кусок, напиши комментарий, как надо — мы и исправим.
А кнопочка помогает в коммуникации.
Хотелось бы уточнить про версионность сборок в GAC
Я тут провел смелые научные эксперименты и получил следующие результаты:
Я проверид это утверждение
Информация о версии приложения разбита на две части вовсе не случайно. При поиске необходимой сборки, политика требует точного совпадения лишь основной версии сборки. А дополнительная версия используется для поиска наиболее свежей сборки. То есть будет загружена сборка с наибольшими номерами построения и ревизии.
Не зависимо от того какая часть версии сборки меняется меняется, если не находится сборка в GAC с точным соотвесвием версии, то выдается ошибка, что не найдена сборка, что очень печально.
Проверялось это под Framework 1.1
1. Утверждение верно для сборок с нестрогими именами. Для ссылок на сборки со строгим именем (а только такие и могут лежать в ГАКе) требуется полное совпадение полного имени сборки.
2. В общем-то ты и сам можешь загрузить нужную сборку, если стандартный загрузчик не нашел, подцепившись на соответствующее событие домена
iT>1. Утверждение верно для сборок с нестрогими именами. Для ссылок на сборки со строгим именем (а только такие и могут лежать в ГАКе) требуется полное совпадение полного имени сборки.
iT>2. В общем-то ты и сам можешь загрузить нужную сборку, если стандартный загрузчик не нашел, подцепившись на соответствующее событие домена
И что делать? Я же не знаю, какая версия последняя. Кроме того не всегда удобно подцепиться на событие домена, так как я могу работать под COM+ или WEBом
В>И что делать? Я же не знаю, какая версия последняя. Кроме того не всегда удобно подцепиться на событие домена, так как я могу работать под COM+ или WEBом
Давай тогда рассказывай, что за задача в целом — может какие-то другие решения есть?
Здравствуйте, Igor Trofimov, Вы писали:
В>>И что делать? Я же не знаю, какая версия последняя. Кроме того не всегда удобно подцепиться на событие домена, так как я могу работать под COM+ или WEBом
iT>Давай тогда рассказывай, что за задача в целом — может какие-то другие решения есть?
Да задача то простая
Есть несколько подсистем, которые как то между собой взаимодействуют. Версии подсистем меняются часто( раз в неделю точно ).
Соотвесвенно после переустановки подсистемы приходтся конфигураить сборки, что бы старые версии других подсистем могли нормально подцеплять новые версии сборок. И это при установке может занимать значительное время. Соотвесвенно нужно решение, которое позволит сократить это время или вообще избавится от конфигурации сборок.
В>что бы старые версии других подсистем могли нормально подцеплять новые версии сборок. И это при установке может занимать значительное время. Соотвесвенно нужно решение, которое позволит сократить это время или вообще избавится от конфигурации сборок.
Так там по-моему можно просто сказать: для поиска любых сборок "MyAsm, 1.1.*, PublicKey=ABCDEF01234" использовать последнюю имеющуюся версию. Или нет такого в MSDN?
Здравствуйте, mihailik, Вы писали:
В>>что бы старые версии других подсистем могли нормально подцеплять новые версии сборок. И это при установке может занимать значительное время. Соотвесвенно нужно решение, которое позволит сократить это время или вообще избавится от конфигурации сборок.
M>Так там по-моему можно просто сказать: для поиска любых сборок "MyAsm, 1.1.*, PublicKey=ABCDEF01234" использовать последнюю имеющуюся версию. Или нет такого в MSDN?
В>Соотвесвенно после переустановки подсистемы приходтся конфигураить сборки, что бы старые версии других подсистем могли нормально подцеплять новые версии сборок.
Тут вот какая штука... если меняется интерфейс взаимодействия подсистем и этот интерфейс описан в этих самых сборках — то сам бог велел все-таки их пересобрать, чтобы удостовериться, что они остались совместимы хотя бы на уровне компиляции.
Если же речь идет об изменении реализации при то, что интерфейс остается тем же — тогда можно интерфейсы вынести в отдельные, неизменяемые сборки, а новые реализации загружать динамически, просто прописывая в некий конфиг перечень имен сборок, которые следует загрузить.
Здравствуйте, Igor Trofimov, Вы писали:
iT>Тут вот какая штука... если меняется интерфейс взаимодействия подсистем и этот интерфейс описан в этих самых сборках — то сам бог велел все-таки их пересобрать, чтобы удостовериться, что они остались совместимы хотя бы на уровне компиляции.
iT>Если же речь идет об изменении реализации при то, что интерфейс остается тем же — тогда можно интерфейсы вынести в отдельные, неизменяемые сборки, а новые реализации загружать динамически, просто прописывая в некий конфиг перечень имен сборок, которые следует загрузить.
Речь идет об обратной совместимости. Если меняется интерфейс, то функциональность только добавляется, а существующий интерфейс не меняется. По этому мне было бы логично, что более поздняя версия может использоваться старыми компонентами, они прост о не будут трогать новые функции.
M>>Так там по-моему можно просто сказать: для поиска любых сборок "MyAsm, 1.1.*, PublicKey=ABCDEF01234" использовать последнюю имеющуюся версию. Или нет такого в MSDN?
В>Где там? Можно примерчик?
В myprogram.exe.config — конфигурационном файле. Если такой файл лежит рядом с EXE-шником, то он при запуске прочитывается и учитывается.
Формат в MSDN есть, я наизусть не помню, мутноватый он малость. Ищи bindingRedirect, и посмотри соседние пункты. Как-то так оно называется.
В>Речь идет об обратной совместимости. Если меняется интерфейс, то функциональность только добавляется, а существующий интерфейс не меняется. По этому мне было бы логично, что более поздняя версия может использоваться старыми компонентами, они прост о не будут трогать новые функции.
А может при этом все-таки должно грузиться две версии интерфейсов — старая и новая? Как вообще подсистемы между собой взаимодействуют? И как взаимодействуют с клиентом?
Здравствуйте, Igor Trofimov, Вы писали:
iT>А может при этом все-таки должно грузиться две версии интерфейсов — старая и новая? Как вообще подсистемы между собой взаимодействуют? И как взаимодействуют с клиентом?
А зачем оставлять 2 версии интерфейсов( кстати почему 2, а не все? ), возникает вопрос, зачем исправляли ошибки и что то добавляли, если все равно будет использоваться старая версия?
Здравствуйте, mihailik, Вы писали:
M>>>Так там по-моему можно просто сказать: для поиска любых сборок "MyAsm, 1.1.*, PublicKey=ABCDEF01234" использовать последнюю имеющуюся версию. Или нет такого в MSDN?
В>>Где там? Можно примерчик?
M>В myprogram.exe.config — конфигурационном файле. Если такой файл лежит рядом с EXE-шником, то он при запуске прочитывается и учитывается.
M>Формат в MSDN есть, я наизусть не помню, мутноватый он малость. Ищи bindingRedirect, и посмотри соседние пункты. Как-то так оно называется.
А если приложение COM+? А если это библиотека, которую используют несколько приложений?
В>А если приложение COM+? А если это библиотека, которую используют несколько приложений?
Во-первых, можно положить рядом с тем процессом, из которого оно будет работать. Ну, это, конечно, не всегда подходит.
Во-вторых, нужно покопаться насчёт publisher Policy. Есть возможность навесить для сборки особый после-релизный конфиг.
Для этого пишется сборка, туда кладётся текст конфига в виде ресурса, и сборка с особым наименованием кладётся в GAC. Это общее видение, подробнее посмотри в MSDN. Я сам никогда такого не делал своими руками.
В>А зачем оставлять 2 версии интерфейсов( кстати почему 2, а не все? ), возникает вопрос, зачем исправляли ошибки и что то добавляли, если все равно будет использоваться старая версия? В>Способ взаимодействия можент быть различным.
В общем, я наверное ничего тебе толкового не посоветую ;( Или выкручивайся со стандартной политикой загрузки, или грузи сам сборки. Возможно, не из GAC, а просто из каталога. И резольви ссылки на сборки и типы.
После выполнения данной команды в текущем каталоге будет создан файл, в котором располагается пара криптографических ключей: открытый и закрытый. При помощи данной утилиты вы можете просмотреть открытый ключ, а так же узнать его маркер.
sn -tp keys.snk
То же я читал и в паре книжек.
На практике же у меня получается , что маркер который присутствует в строгом имени полученной описанным в статье способом не совпадает с тем, что выдает sn -tp keys.snk
если же вытащить публичный ключ в отдельный файл
sn -p keys.snk pubkey.snk
то
sn -tp pubkey.snk
выдает правильный маркер.
Не могли бы Вы пояснить с чем это связано. Заранее благодарен за ответ.
С первого взгляда Microsoft поступила более чем странно, использовав для хранения сборок файлы формата PE ...
...
Но зато выбор данного формата позволил Microsoft создать беспрецедентную по мощности систему взаимодействия .NET кода с родными сервисами операционных систем класса Windows
Слова-то какие: беспрецедентную!
.NET, детка, мне пытаются тебя впарить. Молодца,товарищ! В лучших традициях MSDN. Между маркетинговым трепом иногда проскакивает полезная информация.
4>С первого взгляда Microsoft поступила более чем странно, использовав для хранения сборок файлы формата PE ...
4>...
4>Но зато выбор данного формата позволил Microsoft создать беспрецедентную по мощности систему взаимодействия .NET кода с родными сервисами операционных систем класса Windows
4>Слова-то какие: беспрецедентную!
А что, у тебя есть какие-то другие прецеденты смешивания managed и unmanaged кода?
Может, я что пропустил, и, к примеру, джава вдруг научилась вставлять x86 в .class?
А может, есть какая-то другая технология, которая обеспечивает двустороннюю интеграцию управляемого кода с COM при минимуме усилий?
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Сборка может ссылаться на множество других строгих сборок, а посему, связывание при помощи полных открытых ключей было бы весьма накладно. Размер открытого ключа более одного килобайта.
Microsoft (R) .NET Framework Strong Name Utility Version 2.0.50215.44
Copyright (C) Microsoft Corporation. All rights reserved.
Public key is
0024000004800000940000000602000000240000525341310004000001000100cbf4742dcf8bb6
3d9304ece332e028727af8d9421be4d1e743ffdb6bcf2939e2f5fa98830ca49c944d58da8c63dd
0304c1b5645a178e6e725f69a131782d5644c19c1fe07e123d909adcf24f7ded1f7bcd748d576e
15008890290f0a6696ec8526342eb6a62141e2e60f1ec585b47a709d001ebf30b5368de7a18684
22ec2bd8
АД>Авторы: АД> Алексей Дубовцев
АД>Аннотация: АД>При проектировании платформы .NET одной из задач являлось легкое развёртывание (инсталляция) и поддержка приложений, так как в настоящее время эта проблема стала серьезно беспокоить не только разработчиков, но и рядовых пользователей. Наверное, каждый знаком с ситуацией, когда после установки новой программы некоторые старые приложения наотрез отказывались работать. Ниже я вам поведаю о том, какое решение данной проблемы предоставила Microsoft на этот раз.
Извиняюсь за поднятие столь давнего вопроса, но у меня возник один вопрос. "Вытяжка" из вашей статьи:
Способы подключения динамических библиотек
"Всего существует два способа подключения динамических библиотек: статический и динамический..."
Согласно Рихтеру существует еще один способ загрузки динамических библиотек:
Отложенная загрузка DLL
"Microsoft Visual C++ 6.0 поддерживает отложенную загрузку DLL — новую, просто фантастическую функциональность, которая значительно упрощает работу с библиотеками. DLL отложенной загрузки (delay-load DLL) — это неявно связываемая DLL, которая не загружается до тех пор, пока Ваш код не обратится к какому-нибудь экспортируемому из нее идентификатору..."
1.1.4 stable rev. 510
