Develop MS Access 2016 AddIn (Ribbon / VSTO) with Visual Studio 2015 - visual-studio

Question

Hope you can help me. I am looking forward to programming my first MS Access AddIn with Visual Studio 2015 (a Ribbon-Bar as VSTO), but not having started I have to stop already. Visual Studio provides templates for almost every office product, but MS Access. I heard it is possible to "change" for example the Excel VSTO-Template so it can be used to develop an MS Access Ribbon.
Does anyone know a good instruction how to handle this? How are you developing VSTO for MS Access?
Thanks for your help

Answer 1

There exists a tutorial for this. I haven't tried it, don't know if it works, but it sounds promising.
Here are the juicy bits.
To start building an Access add-in, I could create a Word (or InfoPath, PowerPoint, Project or Visio) add-in (Excel or Outlook would also work, but they have additional redundant host-specific code).
Then, I'll add a reference to the Microsoft Access Object Library, on the COM tab (this also pulls in references to ADODB and DAO). It also pulls in Microsoft.Office.Core.dll, which duplicates the Office.dll already referenced by default - so I'll delete one of these two duplicates.
In Solution Explorer, I can select the project and click the "show all files" button. This makes it easier to open the ThisAddIn.Designer.cs file – here I can change the declaration and initialization of the Application field from M.O.I.Word.Application to M.O.I.Access.Application. Note that this step changes a file that is auto-generated: the file is not normally re-generated, but can be if I corrupt the project (the point being that my manual changes will be lost if the file is re-generated):
//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");
That's all the code changes. Now for the project changes. There are two ways to do these changes – through the IDE in a way that overrides or counters the default settings; or by manually editing the .csproj file directly, to replace the default settings. Let's look at both approaches: first through the IDE, then manually.
First, I'll change the Project Properties | Debug | Start action, to "Start external program", and specify the path to Access, for example:
C:\Program Files (x86)\Microsoft Office\Office12\MSACCESS.EXE
Then, I'll create a .reg file with the same name as my add-in solution, and put it in the solution folder. This reg file is used to register the add-in for Access (and unregister it for Word). The example reg file listed below is simply a dump of what the standard VSTO build task does for each add-in type, with an additional line. The additional line (the first reg entry below) simply removes the entry that the build task puts in for Word. The remaining entries are identical for Word and Access, with the only changing being to replace "Word" with "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"
In Project Properties | Build Events, I add a Post-build event commandline to merge the .reg file into the registry:
regedit /s "$(SolutionDir)$(SolutionName).reg"
That's it. I can now press F5 to build the solution: this will register the add-in for Access, and run Access for debugging with the add-in loaded.
Note that instead of setting the Debug property to an external program (step 4 above), I could modify the .csproj file directly, to set the from Word to Access. For example, change this:
<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}" />
… to this:
<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}" />
Note that changing the value, as show above, changes the icons used in the Solution Explorer .
I could also change the element's Name value to change the name of the parent node for the ThisAddIn.cs in the Solution Explorer. Change this:
<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>
… to this:
<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>
Also, registration is determined by the element value. So, instead of setting up a .reg file as a post-build task (steps 5-6 above), I could edit the .csproj directly to change this:
<OfficeApplication>Word</OfficeApplication>
…to this:
<OfficeApplication>Access</OfficeApplication>