Разработка надстройки MS Access 2016 (Ribbon / VSTO) с помощью Visual Studio 2015

Question

Надеюсь, ты сможешь мне помочь.Я с нетерпением жду программирования своей первой надстройки MS Access с помощью Visual Studio 2015 (ленточная панель в виде VSTO), но пока я не запустился, мне уже нужно остановиться.Visual Studio предоставляет шаблоны практически для любого офисного продукта, кроме MS Access.Я слышал, что можно «изменить», например, VSTO-шаблон Excel, чтобы его можно было использовать для разработки ленты MS Access.Кто-нибудь знает хорошую инструкцию, как справиться с этим?Как вы разрабатываете VSTO для MS Access?

Спасибо за вашу помощь

Answer 1

Для этого существует учебник. Я не пробовал, не знаю, работает ли он, но звучит многообещающе.

Вот сочные кусочки.

1. Чтобы начать создание надстройки Access, я мог бы создать надстройку Word (или InfoPath, PowerPoint, Project или Visio) (Excel или Outlook также будут работать, но они имеютдополнительный избыточный специфичный для хоста код).

2. Затем я добавлю ссылку на библиотеку объектов Microsoft Access на вкладке COM (здесь также содержатся ссылки на ADODB и DAO),Он также извлекает файл Microsoft.Office.Core.dll, который дублирует файл Office.dll, на который уже есть ссылки по умолчанию, поэтому я удалю один из этих двух дубликатов.

3. В обозревателе решенийЯ могу выбрать проект и нажать кнопку «Показать все файлы».Это облегчает открытие файла ThisAddIn.Designer.cs - здесь я могу изменить объявление и инициализацию поля Application с MOIWord.Application на MOIAccess.Application.Обратите внимание, что этот шаг изменяет файл, который создается автоматически: файл обычно не создается повторно, но может произойти, если я испортил проект (суть в том, что мои ручные изменения будут потеряны, если файл будет повторно создан):

//internal Microsoft.Office.Interop.Word.Application Application;
internal Microsoft.Office.Interop.Access.Application Application;

//this.Application = this.GetHostItem<Microsoft.Office.Interop.Word.Application>(typeof(Microsoft.Office.Interop.Word.Application), "Application");
this.Application = this.GetHostItem<Microsoft.Office.Interop.Access.Application>(typeof(Microsoft.Office.Interop.Access.Application), "Application");

Вот и все изменения кода.Теперь для проекта изменения.Есть два способа сделать эти изменения - через IDE таким способом, который переопределяет или отменяет настройки по умолчанию;или вручную отредактировав файл .csproj, чтобы заменить настройки по умолчанию.Давайте рассмотрим оба подхода: сначала через IDE, затем вручную.

Сначала я изменю свойства проекта |Отладка |Запустите действие, чтобы «Запустить внешнюю программу» и укажите путь к Access, например:

C: \ Program Files (x86) \ Microsoft Office \ Office12 \ MSACCESS.EXE

Затем я создам файл .reg с тем же именем, что и мое решение для надстроек, и помещу его в папку решения.Этот reg-файл используется для регистрации надстройки для Access (и отмены регистрации для Word).Приведенный ниже пример reg-файла - это просто дамп того, что стандартная задача сборки VSTO делает для каждого типа надстройки, с дополнительной строкой.Дополнительная строка (первая запись reg ниже) просто удаляет запись, которую задача сборки вставляет для Word.Остальные записи идентичны для Word и Access, единственное изменение заключается в замене «Word» на «Access»:

Windows Registry Editor Version 5.00
[-HKEY_CURRENT_USER\Software\Microsoft\Office\Word\Addins\MyAddIn]
[HKEY_CURRENT_USER\Software\Microsoft\Office\Access\Addins\MyAddIn]
"Description"="MyAddIn"
"FriendlyName"="MyAddIn"
"LoadBehavior"=dword:00000003
"Manifest"="C:\\Temp\\MyAddIn\\bin\\Debug\\MyAddIn.vsto|vstolocal"

В свойствах проекта |События сборки. Я добавляю командную строку событий после сборки, чтобы объединить файл .reg с реестром:

regedit / s "$ (SolutionDir) $ (SolutionName) .reg"

Вот и все.Теперь я могу нажать F5, чтобы построить решение: это зарегистрирует надстройку для Access и запустит Access для отладки с загруженной надстройкой.

Обратите внимание, что вместо настройкиОтладка свойства внешней программы (шаг 4 выше), я мог бы напрямую изменить файл .csproj, чтобы установить из Word в Access.Например, измените это:

<ProjectProperties HostName="Word"
  HostPackage="{D2B20FF5-A6E5-47E1-90E8-463C6860CB05}" OfficeVersion="12.0" VstxVersion="3.0"
  ApplicationType="Word" Language="cs" TemplatesPath="" DebugInfoExeName="#Software\Microsoft\Office\12.0\Word\InstallRoot\Path#WINWORD.EXE"
  AddItemTemplatesGuid="{147FB6A7-F239-4523-AE65-B6A4E49B361F}" />

… на это:

<ProjectProperties HostName="Access"
  HostPackage="{D2B20FF5-A6E5-47E1-90E8-463C6860CB05}" OfficeVersion="12.0" VstxVersion="3.0"
  ApplicationType="Access" Language="cs" TemplatesPath="" DebugInfoExeName="#Software\Microsoft\Office\12.0\Access\InstallRoot\Path#MSACCESS.EXE"
  AddItemTemplatesGuid="{147FB6A7-F239-4523-AE65-B6A4E49B361F}" />

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

Я также мог бы изменить значение имени элемента, чтобы изменить имя родительского узла для ThisAddIn.cs в обозревателе решений.Измените это:

<Host Name="Word" GeneratedCodeNamespace="MyAddIn" IconIndex="0">
  <HostItem Name="ThisAddIn" Code="ThisAddIn.cs" CanonicalName="AddIn" CanActivate="false" IconIndex="1" Blueprint="ThisAddIn.Designer.xml" GeneratedCode="ThisAddIn.Designer.cs" />
</Host>

… на это:

<Host Name="Access" GeneratedCodeNamespace="MyAddIn" IconIndex="0">
  <HostItem Name="ThisAddIn" Code="ThisAddIn.cs" CanonicalName="AddIn" CanActivate="false" IconIndex="1" Blueprint="ThisAddIn.Designer.xml" GeneratedCode="ThisAddIn.Designer.cs" />
</Host>

Также регистрация определяется значением элемента.Таким образом, вместо настройки файла .reg в качестве задачи после сборки (шаги 5-6 выше), я мог бы отредактировать .csproj напрямую, чтобы изменить это:

<OfficeApplication>Word</OfficeApplication>

… на это:

<OfficeApplication>Access</OfficeApplication>