В настоящее время я пишу оснастку PowerShell, которая имеет определенные зависимости от сборников смешанного режима (сборки, содержащие собственный код), которые специально нацелены на x64 или x86. У меня есть обе версии зависимой сборки, но мне интересно, как лучше управлять сборки и развертывания этой оснастке, а именно:Как управлять разработкой оснасток PowerShell с версиями x86 и x64
- Нужно иметь две версии оснастке, один x86 и один x64, и использовать две разные версии installutil для их установки, по одной для каждой архитектуры?
- Предполагая, что # 1 истинно, рекомендуется ли устанавливать две разные версии snapin в разных каталогах «Program Files» и «Program Files (x86)»?
- Каков идеальный (наименее сложный) способ структурирования пары проектов, которые делят все, кроме одной ссылки, для создания двух разных архитектур?
- Если snapin скомпилирован как «AnyCpu», а зависимые DLL загружаются в GAC, будет ли среда выполнения загружать правильную сборку из GAC на основе архитектуры текущего хоста PowerShell?
- Есть ли быстрый способ динамически, во время выполнения, выбрать, какую зависимую dll загрузить (если он не может по различным причинам быть установлен в GAC), не запускаясь в головные боли с контекстами нагрузки сборки?
Модули (добавлены в PSH2) намного проще - не требуют установки - есть ли у вас веские основания для поддержки PSH1? – Richard
@ Richard: могут ли модули скомпилировать код? – Mark
Модули могут загружать сборки и выполнять скрипты (которые, в свою очередь, могут использовать любой метод '[system.reflection.assembly] :: LoadXXX' для загрузки сборки. Если вы планируете не поддерживать PSH1, то рекомендация @ Richard очень. В вашем файле .psd1 элементы 'RequiredAssemblies' и' ScriptsToProcess' могут позволить вам обрабатывать сбои сборки и пользовательскую инициализацию, когда ваш модуль загружается. Подумайте о том, чтобы дать ему возможность, если вы еще не вложили значительные средства в оснастку -in. – kbrimington