Развертывание PIA на смешанных версиях Office - PullRequest
6 голосов
/ 13 сентября 2010

Здравствуйте. Я боролся с некоторыми сложностями в понимании развертывания первичных сборок взаимодействия (PIA) для MS Office. У меня есть надстройка Visual Studio Com, встроенная в VS 2008 по технологии чистых коммуникаций (не VSTO, смотрите подробности ниже), которая ссылается на основные сборки взаимодействия 2003 года, но надстройка может использоваться в 2003, 2007 или 2010 году. Офисные машины. Поскольку я никогда не знаю, будет ли клиент использовать 2003, 2007 или 2010, я не могу просто развернуть одну версию PIA в качестве предварительного условия (если я не сделаю 3 установщика, которые я не хочу делать). Теперь я понимаю, что когда вы выполните шаги здесь , чтобы добавить PIA 2003 и 2007 в списки предварительных требований, которые отображаются в пакете установки Visual Studio (2008), необходимые условия достаточно умны, чтобы определить, какой офис версия работает на клиенте, на которого вы нацелены. Таким образом, если вы выбрали предварительные сборочные сборки 2003 и первичные сборки iterop 2007 как предварительные условия, то при установке на компьютере с 2003-м он должен быть достаточно интеллектуальным, чтобы попытаться добавить PIA 2003 только в том случае, если они отсутствуют на этой машине, и если это Office 2007, то он будет устанавливать только PIA 2007 (и не будет пытаться установить PIA 2003).

Вопрос 1 Является ли это правильным пониманием (что необходимые пакеты являются интеллектуальными для установки только того, что ему нужно, в зависимости от версии Office?)

Вопрос 2 есть ли способ заставить PIA 2010 отображаться в списке предварительных условий в VS 2008, как это делают 2003 и 2007? Я не хочу обновлять этот проект до VS 2010, поскольку он считается унаследованным приложением, и его используют многие клиенты со всего мира.

Вопрос 3 Несмотря на то, что фактическая сборка ссылается на первичные взаимодействия 2003 года, в настоящее время я не развертываю эти взаимодействия с надстройкой в ​​месте установки. Вместо этого я предполагаю, что если я смогу установить правильную PIA, то мне не нужен этот подарок в пути установки, так как PIA будет в GAC. Тем не менее, один из возможных подходов может состоять в том, чтобы просто включить сборки 2003, на которые есть ссылки (в моем случае в excel и word), в путь установки, а не беспокоиться о PIA. Я подозреваю, что это будет работать на машинах 2003 года, но, возможно, не на машинах 2007 и 2010 годов, поскольку на последнем будут обнаружены взаимодействия, на которые имеются ссылки, во время выполнения в пути установки сборки, я думаю, что если нет Policy.11.0.Microsoft.Office.Interop.Excel / Word (и т. д.) в GAC, тогда 2007 и 2010 гг., вероятно, не будут знать, что делать с взаимодействиями 11.0 (2003) (как мне кажется, Policy.11.0.Microsoft. Файлы Office.Interop перенаправляют запросы для операций 2003 на 2007 или 2010). Есть мысли по этому поводу?

Вопрос 4: Существует известная ошибка с приложениями Framework 2.0 для надстроек Office и Office 2003, когда надстройка не загружается. Это было решено KB907417 или KB908002. Кто-нибудь знает, нужен ли этот KB, если вы разрабатываете на платформе 3.0 или 3.5 (и делаете 3.0 или 3.5 обязательным условием), так как эта проблема была характерна для фреймворка 2.0? Или же все-таки нужно развернуть КБ, потому что это проблема с Office 2003, а не с версией фреймворка?

Как вы можете судить по моим 3 вопросам, я пытаюсь выяснить, можем ли мы создать единый установщик с помощью утилиты настройки VS. Если PIA можно выполнить с помощью одного установщика, но указанная выше КБ является препятствием (поскольку, возможно, ответ вернется, что даже на 3.0 или 3.5 framework 2003 потребителям потребуется КБ), тогда, возможно, путь к одному установщику состоит в том, чтобы KB является обязательным условием и устанавливается на машины 2007 или 2010 гг., хотя они технически в них не нуждаются. Любые мысли по этому варианту также будут оценены. Наконец, я знаю, что написание управляемой надстройки Com для Excel или Word теперь обычно выполняется с помощью VSTO вместо чистого кода управляемой платформы, но в настоящее время это не вариант, чтобы изменить устаревшее приложение в этом направлении. Также сообщается, что инфраструктуру 4.0 теперь можно использовать для развертывания надстроек, не делая обязательным условием PIA, но опять же, сейчас это нереальный вариант.

Ответы [ 2 ]

0 голосов
/ 25 мая 2017

Как вы можете судить по моим 3 вопросам, я пытаюсь выяснить, можем ли мы создать один единственный установщик с помощью утилиты настройки VS

Вы не можете.Вы должны создать собственный установщик упаковщика (setup bootstrapper).

Много лет назад я использовал dotNetInstaller с HTML GUI Builder, сегодня WiX toolset было бы лучшим решением, я думаю,

Проверьте, как создаются установщики PIA .msi с помощью Orca или .msi и .exe и .msi и .exe потока проверки журналов установщика Windows.

На основе проверок реестра, проверок файлов, установленныхПроверки продукта, версии Windows, версии Office позволяют создать условия, должен ли компонент быть установлен или нет.

О, и я советую делать установщики плагинов без предварительных условий и устанавливать их условно с помощью загрузчика вашего пользовательского установщика.

0 голосов
/ 07 декабря 2013

Использует ли код какие-либо методы или классы Office 2007+?Если нет, вы уверены, что не можете использовать PIA 2003 во всех случаях?Более поздние приложения должны быть обратно совместимыми (поддерживающими тот же API), поэтому единственная причина, по которой вам понадобится обновленная PIA, - это необходимость доступа к какой-либо функции, добавленной к 2007 или более поздней версии.

Вы можетехочу взглянуть на Add-in Express , который обещает установить единый для всех версий и довольно прост в использовании.

...