Раздел 4. Работа с серверами автоматизации Word и Excel в Visual Studio .Net
Глава 1. Введение в разработку Windows приложений с использованием COM объектов
Глава 2. Работа с COM сервером Excel
Глава 3. Работа с COM сервером Word
Глава 4. В работе.
Глава 1. Введение в разработку Windows приложений с использованием COM объектов
Параграф 1.1. Краткое введение в технологию взаимодействия с COM объектами
Компонентная модель объектов или технология COM (Component Object Model) предоставляет возможность одной программе (клиенту) работать с объектом другой программы (сервером). Технология СОМ упрощает создание программ, обеспечивая их совместимость в разных версиях платформы Windows и относительную независимость от языка программирования (компоненты СОМ могут создаваться на разных языках и далее внедряться в приложении путем использование стандартного интерфейса).
Обобщенно, COM приложение может содержать от одного до нескольких внедренных объектов, а каждый объект может содержать один или несколько интерфейсов, каждый из которых содержит методы объекта. Внешняя программа, используя методы объекта, выполняет необходимые действия по обмену данными с сервером, не беспокоясь об особенностях внутренней реализации. Сервером может быть либо исполняемый файл, либо библиотека.
Основным недостатком использования СОМ объектов являлась необходимость хранения и регистрации в системном реестре всей информация обо всех COM компонентах. Отказ от регистрации экземпляра компонента в реестре и помещение его в доступное место или в каталог приложения, частично решает проблемы связанные с использованием реестра (отпадает необходимость в регистрации компонента, присвоении ему глобальных идентификаторов GUID и поиска по ним исполняемого файла или библиотеки компонента и т.п.). Реализацией данного подхода в .NET является технология сборок.
Сборка (assembly) - это совокупность файлов, устанавливаемых на компьютер и необходимых для выполнения программного кода приложения (среда выполнения - NET Runtime Framework не входит в понятие сборки). В большинстве случаев создаются одно файловые сборки, состоящие из одного ЕХЕ или DLL-файла.
Напомним, что среда выполнения (NET Runtime Framework) работает не с инструкциями (командами) для процессоров, а с командами виртуальной машины или промежуточным кодом - Microsoft Intermediate Language (MSIL), который компилируется и выполняется средой. Поэтому сборка, как минимум, имеет один файл кода MSIL, в котором описывается сборка, функциональность входящих в нее классов (так называемые метаданные) и непосредственно программные инструкции. Метаданные являются частью сборки, поэтому в документации сборки называются самодокументируемыми. Кроме того, в сборку могут входить файлы ресурсов, графические файлы, дополнительные EXE файлы, DLL-файлы. Программы на языке MSIL создают так называемый "управляемый код" (managed code). Это означает, что общеязыковая исполняющая среда CLR (Common Language Runtime), которая является частью NET Runtime Framework, не просто преобразует MSIL в машинные инструкции, а выполняет эти действия с учетом внешних установок (Например, Модуль №1 программы может задать собственный набор прав и набор прав для Модуля №2). Сборка является минимальным объектом .NET, в котором задаются привилегии, и производится контроль версии.
Сборки, которые находятся в каталоге приложения (или в его подкаталоге) получили названия закрытых (private) сборок, а сборки, хранящиеся в глобальном кэш сборок (Global Assembly Cache, GAC) общих (shared). Для того, чтобы какой либо объект COM мог быть использован в приложении, он должен быть оформлен как сборка. При добавлении компонента COM в каталоге приложения создается новый экземпляр закрытой сборки (обычно одна или несколько библиотек .dll) и формируются ссылки на объекты сборки.
Если мы создадим новое решение (например, AppWordExcel - смотри раздел "Начала разработки Windows Application решений в Visual Studio 2005/2008") и вызовем Solution Explorer (меню Viev | Solution Explorer), то в дереве структуры решения можно видеть (Рис.1.), что наш проект уже состоит из нескольких составляющих файлов и ссылок на сборки. Эти файлы будут использоваться для построения результирующей сборки приложения.
Рис.1 Приложение AppWordExcel
Узел References в Solution Explorer содержит имена, совпадающие с именами, определенными в директивах using файла кода проекта - AppWordExcel.cs. В файле решения - AppWordExcel.csproj, можно найти код, который наглядно показывает, что наше решение уже будет включать в себя семь библиотек, которые необходимы для выполнения (в принципе, это тоже файлы shared сборки для Microsoft Visual C#).
<ItemGroup>
<Reference Include="System" />
<Reference Include="System.Core">
<RequiredTargetFramework>3.5</RequiredTargetFramework>
</Reference>
<Reference Include="System.Xml.Linq">
<RequiredTargetFramework>3.5</RequiredTargetFramework>
</Reference>
<Reference Include="System.Data.DataSetExtensions">
<RequiredTargetFramework>3.5</RequiredTargetFramework>
</Reference>
<Reference Include="System.Data" />
<Reference Include="System.Deployment" />
<Reference Include="System.Drawing" />
<Reference Include="System.Windows.Forms" />
<Reference Include="System.Xml" />
</ItemGroup>
Для того, чтобы посмотреть расположение библиотек, дважды кликнем по имени узла System в ветви Reference Solutation Explorer. Внизу панели Visual Studio отобразится имя библиотеки (Рис.2.)
Рис.2. Библиотеки сборки
Параграф 1.2. Способы "раннего связывания" и запуск серверов автоматизации
Далее мы будем вести речь о так называемом "раннем связывании", когда COM объекты добавляются в решение и в целевой сборке присутствуют их dll файлы. О "позднем связывании", которое позволяет готовому приложению обходиться и распространяться без офисных файлов dll, мы поговорим несколько позже.
Вначале добавим файлы библиотек для Word и Excel. Для этого выбираем мышкой в дереве структуры решения узел Reference. Далее, правым кликом мышки входим в контекстное меню и выбираем пункт Add Reference... При его выборе появляется диалоговое окно с тремя закладками.
.NET - содержит все доступные .NET компоненты.
COM - содержит все доступные COM компоненты.
Projects - содержит все компоненты многократного использования, созданные разработчиком (совокупность проектов решения).
Замечание: Здесь уместно еще раз остановиться на разнице понятий решение и проект. Слова solution (решение) и project (проект) в литературе часто тождественны, хотя смысл у них несколько различный. Механизм решений и проектов позволяет объединять все необходимые файлы. Файл проекта содержит информацию обо всех файлах, из которых состоит программа. Решение представляет объединение нескольких проектов, и в простейшем случае, когда оно содержит один проект, тождественно проекту.
Мы можем использовать различные способы работы с COM объектами, которые зависят от версии Visual Studio. В Visual Studio 2003/2005 требуется непосредственное добавление ссылки на COM объект. Для этого выбираем вкладку COM и в ней, по очереди, выбираем Microsoft Excel XX.YY Object Library и Microsoft Word XX.YY Object Library (XX.YY номер версии) и нажимаем кнопку "OK" (Рис.3, слева). В этом случае, в дереве нашего проекта (Рис.4, слева) добавится еще четыре ссылки (VBIDE, Microsoft.Office.Core, Excel, Word) на библиотеки самих Com объектов и библиотеки, которые обеспечивают взаимодействия среды с COM объектами.
Начиная с Net 2.0 корпорация Майкрософт предложила несколько .Net сборок взаимодействия с приложениями Microsoft Office XP (в терминологии Майкрософт - primary interop assembly, PIA). В них содержится описание наиболее часто используемых библиотек (для Microsoft Office начиная с XP и более поздних версий) - (Рис.3.4, в центре и справа) . PIA несколько облегчают взаимодействие между управляемым кодом и СОМ объектами Office и позволяют выполнять неуправляемый код (СОМ) из управляемого кода (.NET) при помощи Microsoft .NET Framework и общеязыковой среды выполнения. СОМ сборки взаимодействия позволяют управляемым приложениям привязываться к неуправляемым типам во время компиляции и затем передавать в общеязыковую среду выполнения информацию о том, как в процессе выполнения должны группироваться неуправляемые типы. В VS 2005 были использованы Microsoft.Office.Tools.Excel и Microsoft.Office.Tools.Word, которые, в свою очередь, позволяли использовать Microsoft.Office.Interop.Excel и Microsoft.Office.Interop.Word .NET dll. В VS 2008 Microsoft.Office.Interop.Excel и Microsoft.Office.Interop.Word .NET сборки уже представлены без посредников.
Рис.3. Добавление COM интерфейсов
Итак, для получения доступа с COM объектам в Visual Studio 2003 нам необходимо было добавить в решение только ссылки на библиотеки COM объектов (Рис.4, слева). Вспомогательные библиотеки для связи с Framework автоматически добавлялись вместе с выбранными ссылками на Excel и Word COM объекты. В Visual Studio 2005 нам требовалось добавить ссылки на COM объекты и ссылки Microsoft.Office.Tools.Excel и Microsoft.Office.Tools.Word для связи Framework с выбранными COM объектами (Рис.4. в центре). В Visual Studio 2008 нам потребуется только ссылки Microsoft.Office.Interop.Excel и Microsoft.Office.Interop.Word - все остальное выполняют библиотеки, ассоциированные с этими ссылками (Рис.4, справа).
Рис.4. Добавление COM интерфейсов
Мы можем вновь обратиться к файлам AppWordExcel.csproj проектов и увидеть внесенные изменения. Для проекта в Visual Studio 2003 и 2005 GUID для поиска объекта находится в решении (не в реестре). После компиляции решения в Visual Studio 2003 четыре файла .dll можно найти там, где формируется исполняемый модуль (Рис.5, слева). В Visual Studio 2005 в целевой сборке (Рис.5, справа) появляются библиотеки Microsoft.Office.Interop.Excel и Microsoft.Office.Interop.Word и Office.dll (обратим внимание, что Visual Studio 2005 порой не переносит эти библиотеки в целевую сборку и приходится добавлять их ручками). В Visual Studio 2008 ссылки на Guid COM объектов в файле .csproj нет, но сами библиотеки взаимодействия находятся в директории, где формируется исполняемый .exe файл (Рис.5, в низу).
Рис.5. Файлы сборки приложений
Отметим, особых отличий в использовании Excel и Word COM объектов в трех реализациях студии нет, но для полной идентичности кода в Visual Studio 2005/2008 необходимо ввести алиасы для этих объектов. Эти объявление позволяют использовать весь приведенный ниже код во всех реализациях студии.
using Excel = Microsoft.Office.Interop.Excel; using Word = Microsoft.Office.Interop.Word;
Добавим на форму кнопочку и создадим обработчик события ее нажатия. Запишем в обработчик код:
private void button1_Click(object sender, System.EventArgs e)
{
Word.Application wordapp = new Word.Application();
wordapp.Visible=true;
Excel.Application excelapp excelapp = new Excel.Application();
excelapp.Visible = true;
}
Запустив приложение и нажав кнопочку, мы, тем самым, запускаем Word и Excel параллельно с запущенным приложением.
Первые выводы:
В Visual Studio .NET использование СОМ объектов стало проще (например, по сравнению с Borland C++ Builder).
Использование СОМ в проектах .NET не стало более быстрым (запуск Word в предыдущем коде не стал быстрей, чем запуск его с иконки на рабочем столе). .NET пока не предложил сверхновой технологии работы с COM объектами.
Молчанов Владислав 2.10.2004г.
Адаптировано к VS 2005 7.10.2007г.
Еcли Вы пришли с поискового сервера - посетите мою главную страничку
На главной странице Вы найдете программы комплекса Veles - программы для автолюбителей, программы из раздела графика - программы для работы с фото, сделанными цифровым фотоаппаратом, программу Bricks - игрушку для детей и взрослых, программу записную книжку, программу TellMe - говорящий Русско-Английский разговорник - программу для тех, кто собирается погостить за бугром или повысить свои знания в английском, теоретический материал по программированию в среде Borland C++ Builder, C# (Windows приложения и ASP.Net Web сайты).