So, I am trying to create a COM Add-In for 64-bit MS Office (no application in particular, just trying to get something working). I am not trying to make an add-in for the VBE, just something for the Office application itself. I have implemented IDTExtensibility2 like this (top of the file):
<Guid("94164866-CD9D-497A-9A8B-B476BE39749F"),
ProgId("COM_Add-In_Test.Connection"),
ComDefaultInterface(GetType(IDTExtensibility2)),
ClassInterface(ClassInterfaceType.None), ComVisible(True)>
Public Class Connection
Implements IDTExtensibility2
I have added registry entries under HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\Excel\Addins\COM_Add-In_Test.Connection (FriendlyName, Description, and LoadBehavior).
The add-in is automatically registered for COM-Interop by Visual Studio (the box is checked).
I have also tried adding registry entries manually under HKCU\Classes\CLSID{94164866-CD9D-497A-9A8B-B476BE39749F}, but to no avail.
When I load up Excel, the add-in is not in the COM Add-Ins dialog box and nothing happens (My OnConnection method is MsgBox("Hello World!")).
I am not using any add-in framework of any kind (VSTO, ExcelDNA, etc). I have used these before, but would very much like to understand how to do this process manually.
What am I missing here?
So, after doing some research, this is what I found:
Don't have Visual Studio register COM interop classes for you.
Use the RegAsm tool with the /reg argument to have it generate a .reg file for you.
Edit the .reg file and replace references to HKEY_CLASSES_ROOT with references to HKEY_LOCAL_MACHINE\SOFTWARE\Classes, if you don't want to require admin rights to install. Example:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{YOUR_GUID}]
#="YOUR_PROG_ID"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{YOUR_GUID}\Implemented Categories]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{YOUR_GUID}\Implemented Categories\{62C8FE65-4EBB-45e7-B440-6E39B2CDBF29}]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{YOUR_GUID}\InprocServer32]
#="mscoree.dll"
"ThreadingModel"="Both"
"Class"="YOUR_PROG_ID"
"Assembly"="YOUR_ASSEMBLY_FULL_NAME"
"RuntimeVersion"="v4.0.30319"
"CodeBase"="file:///PATH_TO_YOUR_DLL"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{YOUR_GUID}\InprocServer32\1.0.0.0]
"Class"="YOUR_PROG_ID"
"Assembly"="YOUR_ASSEMBLY_FULL_NAME"
"RuntimeVersion"="v4.0.30319"
"CodeBase"="file:///PATH_TO_YOUR_DLL"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{YOUR_GUID}\ProgId]
#="YOUR_PROG_ID"
Use add-in spy (available here: https://github.com/NetOfficeFw/AddInSpy) to help diagnose problems and monitor your progress along the way.
Related
I have a com dll developed in VB.net that provides an interface to eBay api's. Been working for many years. Recently eBay change certificate authority and moved to TLS 1.2. Sorted through that but now the dll seems to quit in mid transaction when called from Access. The functionality does listings from local inventory to eBay. The first part loads pictures of the listing item to eBay. That works fine. I can see the calls and responses using Fiddler. It then moves on to actually listing the item which seems to stop when called from Access. What I get back in Access is "Can't find x.dll at file location". I know the call is going to the dll because it uploads the pictures.
I have a test project developed in VB.net to test the dll and when run from that everything works. I can see the listing call and response in fiddler. When run from Access there is no listing call. I can verify that the endpoints for the calls are the same from test project or Access.
My question is how to debug the dll in the Visual Studio IDE when it is called from Access. Any thoughts?
Yes, the way you do this is open up the vs class you have for the .dll.
Then in debug of the project, setup this:
Now, when you hit f5, then access will launch and run.
If at this point, say you close access (exit), then you note the debugging process stops.
However, go though the forms and whatever in Access, and get to the point where you hit that button or whatever.
You find now that you can say set a break point and even step and debug your .net code like any other code. So say in my example (a custom sage 300 .net interface to access), I want to debug "find customer" routine from VBA.
Well, in vb.net I have this code:
so, when any routine - even those in the class instances is called, you can set break-points etc.
And to stop? Just exit access.
So, you can make a change to your code, and even hit f5.
It not clear how you are registering your .dll (or do you use some VBA to side-load the .net - that's what I do, since it is a pain to have to register my .net com objects on each PC.
But, do give the above a try. It should let you debug your .dll code. The trick is to have VS launch ms-access as a attached debug session - and that is exactly what the above setting in your class project above allows you to do.
do note in above, I used the path to access 2010 (access 14), so replace the path name to the access.exe with your version of access you are using.
And keep in mind, that if have some installer, or some custom "thing" that registers your .net .dll for you?
Well, during this process, if your VBA assumes a registered com object, then ensure you have this check box enabled:
On compile for the project settings, you thus want this option checked:
NOTE very careful, checking the above option does not change the code or anything at all - it ONLY does a regasum automatic for you, and this would of course re-register your existing .dll - which is what we want for debugging. After you done, do run your re-register of your .dll to switch back from the debug .dll that going to be in your current project bin folder to whatever you "regular" use on your PC.
FYI:
In MOST cases, I find this whole idea does NOT work unless you launch VS as administraor. So, make sure VS is being run as administraor for this to work.
I tend to just tap windows key, or even right click on your vs shortcut, and of course choose run as administraor.
This is so often required, you note that VS will EASY and quite CLEAR show you running in admin mode, and I quite much now always run VS this way.
You should see this:
Finding information on Add-In development for Microsoft Access is like getting all of your teeth pulled! Yes I've found the couple Managed Add-In Articles written... but could find next to nothing for Un-Managed Add-Ins. I did find one great article which is very old in creating basically an unmanaged .mda project... which I've followed and created a add-in. Now I would like an automated way to deploy this add-in.
I've seen it done from VBA with such tools as Rick Fisher's Find and Replace add-in tool... but can not find a way to do this programatically in Access. I have found lot's and lot's of articles on Excel Add-In's and even Excel Add-In Installation. One such method uses VBA like so:
Sub InstallAddIn()
Dim AI As Excel.AddIn
Set AI = Application.AddIns.Add(Filename:="C:\MyAddIn.xla")
AI.Installed = True
End Sub
Unfortunately Access does not use the same method. If anyone could point me in the right direction I would greatly appreciate it. AND if anyone knows of any books or references that goes more in-depth to developing Add-Ins for Microsoft Access that would be greatly appreciated as well as most of the picking seem slim.
This is just a bad idea. To be honest, I'm not sure where it's even located in the current version of Windows/Office. I have found Word and Excel at the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office, but I have Access installed and I don't see an Access folder there. At one point, Access add-ins were accessible through this registry key:
HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\SOFTWARE\Microsoft\Office\11.0\Access\Menu Add-Ins
This worked for Office 2003 on Win Vista. But it changes every time Microsoft updates Office/Windows, so trying to do it programmatically would be moot because you would have to update and roll out a database change every time you updated Office or Windows.
If you target the main registry hive there is logic that will put the key in the correct location for you. For example, you never hard code Wow6432Node because that location is automatically managed by 64-bit windows when a 32-bit application tries to use the registry. Likewise, in modern C2R versions of office the registry location is in a really strange place. You don't have to worry about it. If you target the main key from Access, the key will end up in the correct location magically.
If you want to install per user I recommend using the following locations.
Put the file here:
Private Function GetAddinFileName() As String
GetAddinFileName = Environ$("AppData") & "\Microsoft\AddIns\" & CodeProject.Name
End Function
Use this registry location:
Private Function GetAddinRegPath() As String
GetAddinRegPath = "HKCU\SOFTWARE\Microsoft\Office\" & _
Application.Version & "\Access\Menu Add-Ins\"
End Function
I've seen this tip on DevX which should 'account for most of the Visual Basic IDE settings'.
Does anyone whether this is sufficient or whether there are more settings out there?
It looks pretty complete, however if you have custom Add-Ins this will not get them. I did a quick search of my Add-Ins and I don't see any generic way of backing them up as they have their own registry keys. The HKEY_CURRENT_USER\Software\Microsoft\Visual Basic\6.0 has an Addins sub-folder so if you have custom add-ins you should at least get a message that they can't be found. Otherwise, use Process Monitor and take note of the registry keys and files that are read when you start Visual Basic.
They are stored in these two registry keys:
HKEY_CURRENT_USER\Software\Microsoft\VBA\Microsoft Visual Basic HKEY_CURRENT_USER\Software\Microsoft\Visual Basic\6.0
Access them by running Regedit.
I have run into an odd problem while attempting to register a vendor-supplied ActiveX control on two different computers. On one computer, I can register the part using regsvr32, and then use it in an Access 2007 form with no problems. On the other computer, after I register the same DLL, it is simply not recognized as a valid ActiveX part by Access 2007, or any other Office 2007 program.
The ActiveX part is contained in a single DLL. I am not missing an additional file on one of the computers.
I cross-checked the exact version of the DLL on both computers using md5sum. Both DLL files are exactly identical.
I cross-checked all of the registry entries generated when the part is registered, using the Nirsoft ActiveX Helper utility. The entries are identical.
I checked Access to make sure that the part had a reference entry which pointed to the DLL.
I checked that the location of the DLL was specified as a Trusted Location in Access.
Unfortunately, I am not enough of a COM expert to know whether or not I am overlooking something odvious. Any additional ideas would be appreciated.
OK, total shot in the dark, but we have some computers in our organization the the IT has locked down pretty tight. When we run setup's they run OK and register our ActiveX components, but the first time we run the program it has to be as an administrator. After that the normal user is able to run the program.
You could try a simple VBS script to verify that the control can be created.
Using Notepad (or similar) save the following as test.vbs, and then double click it to run it.
set oTest = CreateObject("<YOUR PROGID HERE>")
MsgBox ("All Done Successfully")
You should get an reasonably descriptive error or "All Done Successfully".
This would at least point to whether its a system wide or Office specific problem.
And if you get an error it may well point to the actual problem.
OTH, if you don't get an error then you probably have an Office installation issue - which could be resolved by a re-install.
My configuration is windows server 2003 (i'm logged in with admin privileges), office 2003, vtso runtime 2005 se. After installing my addin, all registry keys are in the correct locations and I have given fulltrust to my assembly using caspol.exe. My addin is a application level addin.
When I run excel with regmon and filemon running I can see that excel reads the registry keys of my addin, but I do not see the AddinLoader.dll being loaded in filemon. I get no errors from vsto since it doesn't appear the runtime is even starting up. I've read almost all of the vsto doco on msdn particularly the application addin architecture and vsto runtime overview as well as various other articles and discussions on the topic. I still can't figure out why the runtime won't load on the terminal server.
When installing this on an XP machine it all works fine and my addin gets loaded every time.
Anyone have any idea what might be preventing the vsto runtime from loading?
I had a similar problem with Outlook 2007 on a 64 bit Windows.
I added this reg key and then it worked:
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\12.0\Common\General]
"EnableLocalMachineVSTO"=dword:00000001
Keep in mind to update Office 2007 to the latest service pack ( 3 as of now )
Never Mind I found that I was missing some registry keys after all. Got it working now.
For anyone that is looking for an answer to a similar problem then the registry keys you need to make a 2003 VSTO addin load for all users should look something like this:
[HKEY_CLASSES_ROOT\CLSID\{MY-EXCEL-ADDIN-GUID}]
#="MyExcelAddin -- an addin created with VSTO technology"
[HKEY_CLASSES_ROOT\CLSID\{MY-EXCEL-ADDIN-GUID}\InprocServer32]
#="Is vsdrvtEnvironmentString value type with "%CommonProgramFiles%\Microsoft Shared\VSTO\8.0\AddinLoader.dll" as its value"
"ManifestLocation"="C:\\Path\\To\\MyExcelAddin\\"
"ManifestName"="MyExcelAddin.dll.manifest"
"ThreadingModel"="Both"
[HKEY_CLASSES_ROOT\CLSID\{MY-EXCEL-ADDIN-GUID}\ProgID]
#="MyExcelAddin"
[HKEY_CLASSES_ROOT\CLSID\{MY-EXCEL-ADDIN-GUID}\Programmable]
[HKEY_CLASSES_ROOT\CLSID\{MY-EXCEL-ADDIN-GUID}\VersionIndependentProgID]
#="MyExcelAddin"
[HKEY_CLASSES_ROOT\MyExcelAddin]
#=""
[HKEY_CLASSES_ROOT\MyExcelAddin\CLSID]
#="{MY-EXCEL-ADDIN-GUID}"
[HKEY_CURRENT_USER\Software\Classes\MyExcelAddin]
#=""
[HKEY_CURRENT_USER\Software\Classes\MyExcelAddin\CLSID]
#="{MY-EXCEL-ADDIN-GUID}"
[HKEY_CURRENT_USER\Software\Classes\CLSID\{MY-EXCEL-ADDIN-GUID}]
#="MyExcelAddin -- an addin created with VSTO technology"
[HKEY_CURRENT_USER\Software\Classes\CLSID\{MY-EXCEL-ADDIN-GUID}\InprocServer32]
"ThreadingModel"="Both"
#="Is vsdrvtEnvironmentString value type with "%CommonProgramFiles%\Microsoft Shared\VSTO\8.0\AddinLoader.dll" as its value"
"ManifestLocation"="C:\\Path\\To\\MyExcelAddin\\"
"ManifestName"="MyExcelAddin.dll.manifest"
[HKEY_CURRENT_USER\Software\Classes\CLSID\{MY-EXCEL-ADDIN-GUID}\ProgID]
#="MyExcelAddin"
[HKEY_CURRENT_USER\Software\Classes\CLSID\{MY-EXCEL-ADDIN-GUID}\Programmable]
[HKEY_CURRENT_USER\Software\Classes\CLSID\{MY-EXCEL-ADDIN-GUID}\VersionIndependentProgID]
#="MyExcelAddin"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\Excel\Addins\MyExcelAddin]
"Description"="MyExcelAddin -- an addin created with VSTO technology"
"LoadBehavior"=dword:00000003
"FriendlyName"="MyExcelAddin"
"CommandLineSafe"=dword:00000001
Of course you will need to change GUIDs and paths to appropriate values. By Putting the addin keys under local machine instead of current user the addin will work for all users without having to repair the install after running excel for the first time. Also this only lets the office application know the addin is there and that it needs to attempt to load it, this does not give the assembly trust in the system, you need to use Caspol.exe to do that. Read the msdn article about SetSecurty to do this http://msdn.microsoft.com/en-us/library/bb332052.aspx.