Ссылки на сборки Microsoft Office Interop

Question

У меня есть приложение, разработанное в Visual Studio 2005, которое я развертываю с использованием ClickOnce. Мое решение содержит два проекта - слой пользовательского интерфейса, кодированный в VB, и библиотека классов, написанная на C #. В моей библиотеке классов C # есть некоторый код, который использует сборки взаимодействия Outlook и Excel (Microsoft.Office.Interop.Outlook и Microsoft.Office.Interop.Excel, обе версии 11). Вот мои вопросы.

1. Хотя я не нашел, где это указано как абсолют, я понимаю, что вы ДОЛЖНЫ иметь соответствующие версии приложений Office (Outlook / Excel), чтобы установить приложение, использующее сборки Interop. Это правильно?

Если (1. = Да), то

Как бы вы справились с ситуацией, когда ваше приложение использует сборки Interop только для пары функций, которые будут использоваться только некоторыми избранными из общей пользовательской базы? Почему я должен требовать, чтобы каждый пользователь моего приложения устанавливал Microsoft Office, если только некоторым пользователям потребуется использовать эти функции? Эти сборки Interop представляют собой просто файлы .dll , поэтому они настолько отличаются от других, что вы не можете просто опубликовать файл с вашим проектом и получить ссылку, которая не зависит от того, какое программное обеспечение установлено на клиент? (Ясно, что у меня плохое понимание GAC, и это влияет на поведение Visual Studio.) Я был бы рад написать свой собственный код, чтобы проверить наличие необходимого программного обеспечения Office для тех немногих функций, которые их используют. Нет офиса, нет доступа к функции ...

прочее

Если мое понимание этого неверно, то КАК настроить мои ссылки и настройки ClickOnce, чтобы при попытке установки пользователи не сталкивались со следующей ошибкой?

"Невозможно установить или запустить приложение. Приложение требует, чтобы сначала в глобальный кэш сборок (GAC) была установлена ​​сборочная редакция версии 11.0.0.0.

Пожалуйста, свяжитесь с вашим системным администратором. "

• Я попытался установить для свойства Interop ссылки CopyLocal значение True и False.
• В своем списке файлов приложений ClickOnce я попытался установить для этих сборок значения «Включить», «Исключить» и «Необходимые условия».
• В своем исследовании я видел, как некоторые люди ссылаются на * C: \ WINDOWS \ assembly \ GAC *, моя указывает на * C: \ Program Files \ Microsoft Visual Studio 9.0 \ Инструменты Visual Studio для Office \ PIA \ Office11 * но я не нашел способ изменить ссылочный путь. Согласно http://msdn.microsoft.com/en-us/library/ez524kew(VS.80).aspx вы НЕ МОЖЕТЕ добавлять ссылки из GAC, так как же это удалось другим людям?
• Я попытался скопировать ссылки из * C: \ Program Files \ Microsoft Visual Studio 9.0 \ Visual Studio Tools для Office \ PIA \ Office11 * в каталог моего проекта и сослаться на них там.

Конец, если

Полагаю, главное, что мне нужно знать, это как / если я могу включить эти сборки в мою публикацию и удовлетворить или обойти требование GAC.

По возможности, пожалуйста, постарайтесь ответить на мои конкретные вопросы как можно более прямо. Хотя статьи полезны, я уже прочитал МНОГО статей и попробовал МНОГО предложенных решений, но не нашел успеха. Имейте в виду мое непонимание того, как все это работает с самого начала.

Простите за отсутствие понимания и спасибо за любую помощь, которую вы можете предложить. Это высоко ценится!

Answer 1

Возможно, вы захотите взглянуть на проект NetOffice: http://netoffice.codeplex.com/.

Это бесплатный (лицензия MIT) и полный (все версии 2000-2010 и все приложения Office) независимый от версии сборочный узел взаимодействия. Сборки создаются из фактических PIA с помощью инструмента, поэтому они являются правильными, полными и актуальными и, вероятно, будут быстро обновлены для будущих версий.

Еще одна приятная особенность заключается в том, что IntelliSense для каждого участника отображает, какие версии Office реализуют этот элемент.

Для развертывания вы можете скопировать или установить сборки с вашим приложением.

Answer 2

По моему опыту, попытка управлять сборками взаимодействия офиса в широком сценарии развертывания является кошмаром. Если вы развертываете с помощью ClickOnce, даже если вы обойдете проблему GAC, о которой вы упомянули выше (возможно, из-за того, что ваш ИТ-отдел выдвинет регистрацию GAC для сборок взаимодействия, если это корпоративная среда), вам придется работать в ситуациях, когда пользователи имеют версию Office, отличную от стандартной, и они помогут вам, когда выйдет Office 13, и пользователи начнут обновляться, и это нарушит работу вашего приложения.

Чтобы обойти использование сборок взаимодействия, связанных с версией, можно выполнить автоматизацию делопроизводства, используя pinvoke непосредственно к оболочкам Office COM, которые не зависят от версии (они вытягивают текущую версию office на клиенте из реестр). Однако это будет иметь свои собственные проблемы с развертыванием (например, вам может потребоваться обновить реестр, чтобы обрабатывать компьютеры, на которых установлены PIA, что может быть очень сложным при использовании ClickOnce для развертывания), и с ним гораздо сложнее работать.

Если бы я был на вашем месте, я бы начал с тщательного изучения функциональных возможностей взаимодействия, которые вы используете в своей библиотеке классов, - есть ли другой способ предоставить необходимую функциональность за пределами взаимодействия с офисом на клиентская машина? Возможно, это сервис-ориентированное решение, когда клиенты отправляют запрос на сервер, чтобы создать индивидуальный офисный документ и предоставить его для загрузки ...

Answer 3

Лучший способ - использовать библиотеку позднего связывания

https://sourceforge.net/projects/exceldata/

• без проблем с iterops и tlbs в разных офисных версиях
• поддержка различных офисов
• легко сделать модификацией

Тем не менее:

• трудно поддерживать эту библиотеку

Answer 4

Вот что я знаю из своего опыта (я должен отметить, что мы не использовали ClickOnce, но я не уверен, почему это будет иметь значение):

Если вы пишете в API-интерфейсы Excel 2003 и развертываете на компьютере с Excel 2007, это будет работать, потому что Excel 2007 по сути олицетворяет Excel 2003. Проблема в том, что некоторые API-интерфейсы изменились, а некоторые из них даже были удалены. Вы должны попробовать сами, чтобы проверить, не затронуты ли ваши приложения.

На самом деле, это немного хуже, чем это. Если вы запустите приложение на компьютере с установленными Excel 2003 и Excel 2007, Interop будет по-прежнему использовать Excel 2007.

Одной из возможностей является использование SpreadsheetGear для .NET , который предоставляет совместимый с Excel элемент управления Windows Forms, реализованный полностью в одной сборке .NET, которую вы можете развернуть вместе с приложением - поэтому ваше приложение не будет зависеть от Office .

Вы можете скачать бесплатную пробную версию здесь , если хотите попробовать.

Отказ от ответственности: я владею SpreadsheetGear LLC

Answer 5

Используйте интерфейс COM и позднюю привязку. VB.NET всегда поддерживал позднюю привязку. Просто используйте Marshal.GetActiveObject () и установите тип вашей переменной в Object. Вы можете создать объект VB.NET, который делает это, и вызывать его из C #.

С C # вы получаете позднюю привязку, если используете API отражения, но писать код с использованием этого довольно больно. В C # 4 вы также можете получить позднюю привязку через динамический тип.

Если вы сделаете это, вам не нужно распространять какие-либо сборки Office, и ваш код будет работать до тех пор, пока атрибуты объектов в API Office не изменятся.

Код позднего связывания медленнее, чем код раннего связывания, но для многих целей это не проблема.