2010-08-23 2 views
2

В настоящее время я пишу оснастку PowerShell, которая имеет определенные зависимости от сборников смешанного режима (сборки, содержащие собственный код), которые специально нацелены на x64 или x86. У меня есть обе версии зависимой сборки, но мне интересно, как лучше управлять сборки и развертывания этой оснастке, а именно:Как управлять разработкой оснасток PowerShell с версиями x86 и x64

  1. Нужно иметь две версии оснастке, один x86 и один x64, и использовать две разные версии installutil для их установки, по одной для каждой архитектуры?
  2. Предполагая, что # 1 истинно, рекомендуется ли устанавливать две разные версии snapin в разных каталогах «Program Files» и «Program Files (x86)»?
  3. Каков идеальный (наименее сложный) способ структурирования пары проектов, которые делят все, кроме одной ссылки, для создания двух разных архитектур?
  4. Если snapin скомпилирован как «AnyCpu», а зависимые DLL загружаются в GAC, будет ли среда выполнения загружать правильную сборку из GAC на основе архитектуры текущего хоста PowerShell?
  5. Есть ли быстрый способ динамически, во время выполнения, выбрать, какую зависимую dll загрузить (если он не может по различным причинам быть установлен в GAC), не запускаясь в головные боли с контекстами нагрузки сборки?
+2

Модули (добавлены в PSH2) намного проще - не требуют установки - есть ли у вас веские основания для поддержки PSH1? – Richard

+0

@ Richard: могут ли модули скомпилировать код? – Mark

+2

Модули могут загружать сборки и выполнять скрипты (которые, в свою очередь, могут использовать любой метод '[system.reflection.assembly] :: LoadXXX' для загрузки сборки. Если вы планируете не поддерживать PSH1, то рекомендация @ Richard очень. В вашем файле .psd1 элементы 'RequiredAssemblies' и' ScriptsToProcess' могут позволить вам обрабатывать сбои сборки и пользовательскую инициализацию, когда ваш модуль загружается. Подумайте о том, чтобы дать ему возможность, если вы еще не вложили значительные средства в оснастку -in. – kbrimington

ответ

1

Я в конечном итоге создать модуль, но это не решает проблемы, связанные с архитектурой процессора (спасибо, Ричард!). Чтобы решить эту проблему, я поместил обе версии зависимой dll в каталог модуля, а в каждом конструкторе cmdlet поместил некоторый код инициализации (который работает только один раз) для загрузки соответствующей версии зависимой dll.

Спасибо, все, за указатели.

4

Оценка: У нас есть эта ситуация с расширениями сообщества PowerShell с 32-разрядными и 64-разрядными версиями 7zip.dll. Вы можете довольно легко обойти это с помощью PInvoking в LoadLibrary на ранней стадии запуска snapin (или до того, как вам нужно вызвать в родную DLL). Затем вы можете проверить, является ли вы 32-разрядным или 64-разрядным процессом (IntPtr.Size), а затем вручную загружать правильную DLL с помощью LoadLibrary PInvoke. После этого DllImport («YourNative.dll») заметит, что DLL уже загружена и использует эту DLL.

Посмотрите на этих двух файлах исходного кода PSCX: http://pscx.codeplex.com/SourceControl/changeset/view/74794?ProjectName=Pscx#1358100 http://pscx.codeplex.com/SourceControl/changeset/view/74794?ProjectName=Pscx#1358102

+0

Это именно та линия мышления, которую я ищу, но я работаю с сборкой в ​​смешанном режиме, а не с обычным Windows .dll. Я считаю, что это означает, что я не могу просто вызвать LoadLibrary на нем, Правильно? Кроме того, что это за «запуск« snapin », о котором вы говорите? Как я могу запускать код инициализации каждый раз, когда моя snapin добавляется в текущую оболочку? – Mark

+0

Я добавил отдельный вопрос об инициализационном коде: http: // stackoverflow ,com/questions/3551771/how-can-i-run-initialization-code-each-time-my-snap-in-is -load – Mark

+0

В этом случае мне интересно, можете ли вы установить как 32-разрядные, так и 64-разрядные сборки смешанного режима в GAC и посмотреть, будет ли CLR загружать правильный, основанный на битрейте процесса. –

 Смежные вопросы

  • Нет связанных вопросов^_^