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.
Related
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.
I am trying to create a word document using visual basic. I have found that this can be done using the Microsoft.Office.Interop.Word objects.
I have found some tutorials online (https://support.microsoft.com/en-us/kb/316384) about how to create a word document programmatically.
I have created a simple windows form application. When a button is clicked the word document will be created. I made sure to add the reference to Microsoft.Office.Interop.Word in my application.
My problem is that an error keeps getting thrown at this point:
app = New Microsoft.Office.Interop.Word.Application
The error is:
COMException occurred
A first chance exception of type 'System.Runtime.InteropServices.COMException' occurred in mscorlib.dll
Additional information: Retrieving the COM class factory for component with CLSID (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx) failed due to the following error: 80080005 Server execution failed (Exception from HRESULT: ox80080005 (COE_SERVER EXEC FAILURE)).
I have read that the following needs to be done, so I have made sure that word 2013 is installed on my machine and I have set the target CPU to x64 inside the application's properties.
If anyone has any insight to what I am missing or if I am doing something wrong I would appreciate the help.
Update:
I have tested my code on another machine and it works. So the source of this error is not the code.
Update: Pt. 2
I've been doing some more research (http://www.microsoft.com/technet/support/ee/transform.aspx?ProdName=Windows+Operating+System&ProdVer=5.2&EvtID=10010&EvtSrc=DCOM&LCID=1033) and I believe I may be getting closer to the source of the problem. I've gone into the registry and it seems that the local server it is failing to communicate with is pointing to WINWORD.exe which makes sense. What does not make sense is that it is looking for the wrong WINWORD.exe. I am going to try and fix this so it is pointing to the WINWORD.exe for Word 2013 instead of Word 2010.
Solution
What ended up fixing my problem was preforming a quick repair on office. I went to control panel, programs and features, selected office, pressed the change button, and selected quick repair. Do not know what caused things to get messed up, but this did fix my problem.
Where do you run the code? Is it a Windows service or ASP.NET application?
Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution. Read more about that in the Considerations for server-side Automation of Office article.
You may find existing threads with the same issue described:
System.Runtime.InteropServices.COMException (0x80080005): Retrieving the COM class factory for component with CLSID
Office Automation in .NET - COMException 80080005
Word Automation with ASP.NET
Finally, if all the mentioned information is not relevant to your case I'd suggest repairing Office. It looks like something is wrong with its windows registry keys.
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 have an Microsoft Access 2010 database application with split front end and backend which has started to behave oddly, and I've exhausted all the options I know for investigating and resolving the problem.
32-bit Access 2010 running on Windows 8.1... I have both Access 2010 and Access 2013 installed, but the problem also manifests itself on a Windows 8.1 system with a completely fresh install of Access 2010 and no Office 2013 present. The issue also exists if the application is run using Access 2010 Runtime. The front-end is running on my hard disk, not in a Dropbox or similar environment. The back-end is in Dropbox.
There are a couple of third-party elements in the application -- references are as shown -- example 1 on the system with both Access 2010 and 2013 present, example 2 on the system with just Access 2010 present.
There hasn't been a software update to the Treeview control since December 2013. I've checked that the versions of the third-party controls I'm using are compatible with Windows 8.1.
Symptoms:
The application (an unreleased development version) initially works perfectly, but if closed and reopened, one specific operation (right-click on a third party treeview ActiveX control on the main form) misbehaves -- the right-click event is triggered multiple times instead of just once (the number of times is unpredictable). There are two treeviews on the main form with identical settings (populated dynamically with different data sets). One treeview behaves, one doesn't. Even if I remove all code from the right-click event, it fires twice.
This main form configuration and code hasn't been changed in over one year, not has the treeview config or code. I don't use Compact on Close. The application isn't logging any errors.
What I've tried:
If I restore a previous version of the application, it works... and when reopened, doesn't work. (I've tried this with several previous versions of the database.)
I've tried importing a copy of the main form from an old working version of the database -- same problem.
I've tried deleting the malfunctioning treeview and creating a new one (copying the one that is working) -- same problem.
I've tried creating a new blank database and importing all the objects from the old one. Once I've restored the references manually, the same problem.
I've reviewed all the possibilities mentioned in Can't eliminate Access corruption -- one commonality I have with this question is that I've (last three months) started using the VBA Implements keyword, but I hadn't made any changes to this code immediately before the problem showed up, and neither the main form nor the treeview control utilise it.
I've emailed the support team for the treeview control, but they haven't anything to suggest that I haven't already tried.
I've repaired the installation of both Access 2010 and Office 365 in case the references were somehow messed up.
I've un-installed Office 365 and Access 2010, rebooted the machine and reinstalled Access 2010. The references are all Office 14 references and the problem still exists (in a compiled accde). As soon as I reinstall Office 365, the references become mixed 14 and 15. (This is also true for the working version which is two years old).
What I haven't tried yet:
Rolling back a two months' worth of Windows updates to see if it's a Windows issue (this system has only been in use since early September, so this wouldn't be hugely onerous to try).
Rolling back to a version of the app from December 2012 (the last production release) which doesn't seem to have suffered the corruption and manually reapply almost two years worth of development changes. This would be a mega undertaking....
Are there any other options for investigation or resolution that I can try?
Edited to add: What finally worked
I created a new empty database, imported everything from the old database except the main form, which I recreated from scratch to look identical and have the same code as the old one... And the problem has gone away. It not very satisfactory as a resolution, but it seems to confirm that there was a corruption somewhere.
One of the best ways to remove corruption in an Access database is to save the forms and reports to text using the undocumented SaveAsText function, delete the form and report objects, close the database, use the undocumented /decompile switch to decompile the database, compact/repair the database, then re-import all the objects using the undocumented LoadFromText function.
Usually the Access databases corruptions affect the VBA modules, less likely the table data. So hopefully you should be able to copy the data to a blank database, get the VBA code from a older backup (since the last source code update) and merging the two together. It should work!
It won't stay fixed unless you disable updates. And you can't disable updates because you will be compromising security.
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.