Как управлять разработкой оснасток PowerShell для версий x86 и x64 - PullRequest
Новая
       40

Как управлять разработкой оснасток PowerShell для версий x86 и x64

2 голосов
/ 24 августа 2010

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

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

Ответы [ 2 ]

4 голосов
/ 24 августа 2010

Марк, у нас такая же ситуация с расширениями сообщества PowerShell для 32-битных и 64-битных версий 7zip.dll.Вы можете довольно легко обойти это, используя PInvoking для LoadLibrary в начале запуска оснастки (или до того, как вам нужно будет обратиться к нативной 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

1 голос
/ 24 августа 2010

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

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

...