Вместо того, чтобы пытаться разобраться с индивидуальными болями, с которыми я имею дело, я хочу дать обзор на 10 000 футов. Я изучаю .NET по ходу работы и подозреваю, что есть что-то очевидное, чего я здесь не хватает.
Я сижу на работе сверхурочно в воскресенье, и я был бы очень признателен, если бы кто-то бросил свои пять центов.
Вот так:
Наш основной продукт представляет собой систему управления процессом.
Существует много возможных способов расширения / настройки системы. Мы традиционно отделяли выпуск системы управления от конкретной конфигурации контролируемой технологической установки, чтобы их можно было поддерживать отдельно.
C: \ Базовый выпуск системы управления \ (я называю это CS $ ) Это базовый выпуск. Исправление ошибок и т. Д.
C: \ Delivery Project \ (я называю это Proj $ ) Это информация об управляемой системе.
Небольшой фон:
- Ожидается, что наши сервисные инженеры смогут переустановить или обновить папку CS $ без потери данных настройки.
- Проект Delivery традиционно развертывается XCOPY.
- Между ними есть некоторая dll-ссылка, которая отлично работает в MFC.
- На наших лабораторных машинах обычно установлено много версий одновременно.
- Система запускается из .bat-файлов, находящихся в проекте доставки, который устанавливает среду, а затем запускается. Процесс запуска интенсивно зависит от окружающей среды.
Теперь я испытываю некоторые трудности с адаптацией этой модели при использовании .NET.
Когда система использует встроенные элементы управления .NET или отображает winform, mscorlib загружается по требованию, а CS $ \ Run \ bin является базовым путем приложения. Это вызывает у меня некоторые проблемы:
- .NET сборки, развернутые в Proj $, находятся вне базового пути приложения.
- .NET сборки, развернутые в CS $ \ Run \ bin, будут удалены, если люди переустановят базу системы управления. Конечно, я могу сделать развертывание частью пакетного запуска.
- . Пути сборки .NET предоставляются в текстовой конфигурации, находящейся в структуре папок Proj $. Относительные пути в проекте доставки распространены, но они являются проблемой, когда они начинают получать доступ к CS $, который может быть изменен.
- .NET-сборки, развернутые в CS $ \ Run \ bin, могут иметь дополнительные зависимости. У меня могут быть две разные версии Util1.dll в CS $ \ run \ bin \ ext1 и CS $ \ run \ bin \. Это приводит к тому, что CLR не может разрешить CS $ \ run \ bin \ ext1 \ util1.dll из-за порядка пути поиска.
- Я экспериментировал с разделением доменов приложений, но экземпляры классов, найденные в CS $ \ run \ bin \ ext1 \ ext1.dll, могут исчисляться сотнями. И я активно использую Singletons (статические) для координации управления ресурсами.
Само собой разумеется, я использую много Reflector и Fuslogvw. Есть ли еще инструменты, о которых я должен знать?
Можно ли проверить запущенные процессы на наличие информации CLR внутри них? Так как mscorlib загружается по требованию, я иногда обнаруживаю, что CLR имеет базу приложений, которая уже далеко. Иногда это препятствует загрузке моего кода, поэтому я не могу программно получить доступ к домену приложения или вывести его для трассировки.
Можно ли каким-либо образом контролировать путь пробного запуска относительно вызывающей сборки, прежде чем начинать с базового пути приложения?
Могут ли сборки смешанного режима в GAC получить доступ к ресурсам MFC в CS $?
Хотя у меня нет базы кода MFC, которая загружает mscorlib по требованию, у меня есть поговорка. Есть ли что-то, что можно сделать оттуда? Я собираюсь запросить, чтобы ключевая информация при загрузке mscorlib выводилась на трассировку (а также на исключения).
Буду признателен за статьи, инструменты или краткое описание некоторых аспектов, которые мне не хватает.
Я ценю, что вы нашли время, чтобы прочитать это и сохранить ясную голову в течение всей этой наследственной боли, которую я описываю здесь:)