Ссылки на сборки Microsoft Office Interop
У меня есть приложение, разработанное в Visual Studio 2005, которое я развертываю с помощью ClickOnce. Мое решение содержит два проекта - слой пользовательского интерфейса, закодированный в VB, и библиотеку классов, написанную на C#. В моей библиотеке классов C# есть некоторый код, который использует сборки взаимодействия Outlook и Excel (Microsoft.Office.Interop.Outlook и Microsoft.Office.Interop.Excel, обе версии 11). Вот мои вопросы.
- Хотя я не нашел, где это указано как абсолютное, я понимаю, что вы ДОЛЖНЫ иметь соответствующие версии приложений Office (Outlook/Excel), чтобы установить приложение, использующее сборки Interop. Это правильно?
Если (1. = Да), то
Как бы вы справились с ситуацией, когда ваше приложение использует сборки Interop только для пары функций, которые будут использоваться только некоторыми избранными из общей базы пользователей? Почему я должен требовать, чтобы каждый пользователь моего приложения устанавливал Microsoft Office, если только некоторым пользователям потребуется использовать эти функции? Эти сборки Interop представляют собой просто файлы .dll, так что же отличает их от других тем, что вы не можете просто опубликовать файл вместе с вашим проектом и получить его, который соответствует эталону, независимо от того, какое программное обеспечение установлено на клиенте? (Очевидно, я плохо понимаю GAC, и это влияет на поведение Visual Studio.) Я был бы рад написать свой собственный код, чтобы проверить наличие необходимого программного обеспечения Office для тех немногих функций, которые их используют. Нет офиса, нет доступа к функции...
еще
Если мое понимание этого неверно, то КАК настроить параметры ссылок и настройки ClickOnce, чтобы при попытке установки пользователи не сталкивались со следующей ошибкой?
"Невозможно установить или запустить приложение. Приложение требует, чтобы сборочная редакция Версии 11.0.0.0 была сначала установлена в глобальный кэш сборок (GAC).
Пожалуйста, обратитесь к системному администратору."
- Я попытался установить для свойства 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.
По возможности, пожалуйста, постарайтесь ответить на мои конкретные вопросы как можно более прямо. Хотя статьи полезны, я уже прочитал МНОГО статей и попробовал МНОГО предложенных решений, но не нашел успеха. Имейте в виду мое непонимание логистики того, как все это работает с самого начала.
Прости меня за отсутствие понимания, и спасибо за любую помощь, которую ты можешь предложить. Это высоко ценится!
5 ответов
Возможно, вы захотите взглянуть на проект NetOffice: http://netoffice.codeplex.com/.
Это бесплатный (лицензия MIT) и полный (все версии 2000-2010 и все приложения Office) набор сборок, не зависящих от версии. Сборки генерируются из фактических PIA с помощью инструмента, поэтому они являются правильными, полными и актуальными и, вероятно, будут быстро обновляться для будущих версий.
Еще одна приятная особенность заключается в том, что IntelliSense для каждого участника отображает, какие версии Office реализуют этот элемент.
Для развертывания вы можете скопировать или установить сборки с вашим приложением.
По моему опыту, попытка управлять сборками взаимодействия офиса в широком сценарии развертывания является кошмаром. Если вы развертываете с помощью ClickOnce, даже если вы обойдете проблему GAC, о которой вы упомянули выше (возможно, из-за того, что ваш ИТ-отдел выдвинет регистрацию GAC для сборок взаимодействия, если это корпоративная среда), вам придется работать в ситуациях, когда пользователи имеют версию Office, отличную от стандартной, и это поможет вам, когда выйдет Office 13, и пользователи начнут обновляться, и это нарушит работу вашего приложения.
Чтобы обойти использование сборок взаимодействия с привязкой к версии, можно выполнить автоматизацию офиса, используя pinvoke непосредственно для оболочек Office COM, которые не зависят от версии (они вытаскивают текущую версию office на клиенте из реестра). Однако это будет иметь свои собственные проблемы с развертыванием (например, вам может потребоваться обновить реестр, чтобы обрабатывать компьютеры, на которых установлены PIA, что может быть очень сложным при использовании ClickOnce для развертывания), и с ним гораздо сложнее работать.
Если бы я был на вашем месте, я бы начал с тщательного изучения функциональных возможностей взаимодействия, которые вы используете в своей библиотеке классов - есть ли другой способ предоставить необходимую функциональность за пределами офисного взаимодействия на клиентском компьютере? Возможно, это сервис-ориентированное решение, когда клиенты отправляют запрос на сервер, чтобы создать индивидуальный офисный документ и предоставить его для загрузки...
Лучший способ - использовать библиотеку позднего связывания.
https://sourceforge.net/projects/exceldata/
- без проблем с iterops и tlbs в разных офисных версиях
- поддержка различных офисов
- легко сделать модификацию
Тем не мение:
- трудно поддерживать эту библиотеку
Вот что я знаю из своего опыта (я должен отметить, что мы не использовали ClickOnce, но я не уверен, почему это будет иметь значение):
Если вы пишете в API-интерфейсы Excel 2003 и развертываете на компьютере с Excel 2007, это будет работать, потому что Excel 2007, по сути, олицетворяет Excel 2003. Проблема заключается в том, что некоторые API-интерфейсы изменились, а некоторые из них даже были удалены. Вы должны попробовать это сами, чтобы увидеть, если ваше приложение затронуто.
На самом деле, это немного хуже, чем это. Если вы запустите приложение на компьютере с установленными Excel 2003 и Excel 2007, Interop будет по-прежнему использовать Excel 2007.
Одной из возможностей является использование SpreadsheetGear for.NET, который предоставляет совместимый с Excel элемент управления Windows Forms, реализованный полностью в одной сборке.NET, которую вы можете развернуть вместе с приложением, чтобы ваше приложение не зависело от Office.
Вы можете скачать бесплатную пробную версию здесь, если вы хотите попробовать его.
Отказ от ответственности: я владею SpreadsheetGear LLC
Используйте интерфейс COM и позднюю привязку. VB.NET всегда поддерживал позднюю привязку. Просто используйте Marshal.GetActiveObject() и установите тип вашей переменной в Object. Вы можете создать объект VB.NET, который делает это, и вызывать его из C#.
С C# вы получаете позднюю привязку, если вы используете API отражения, но писать код, используя это, довольно больно. В C# 4 вы также можете получить позднюю привязку через динамический тип.
Если вы сделаете это, вам не нужно распространять какие-либо сборки Office, и ваш код будет работать до тех пор, пока атрибуты объектов в API Office не изменятся.
Код с поздним связыванием медленнее, чем код с ранним связыванием, но для многих целей это не проблема.