В>Речь идет об обратной совместимости. Если меняется интерфейс, то функциональность только добавляется, а существующий интерфейс не меняется. По этому мне было бы логично, что более поздняя версия может использоваться старыми компонентами, они прост о не будут трогать новые функции.
А может при этом все-таки должно грузиться две версии интерфейсов — старая и новая? Как вообще подсистемы между собой взаимодействуют? И как взаимодействуют с клиентом?
Здравствуйте, 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
