I am currently supporting a Microsoft Access 2000 line of business application with a number of external dependencies, including Microsoft Word 2007 for mail merges. The application uses a batch script to keep external references up to date by copying and registering (if needed) each DLL on the user's computer, something like the script below:
COPY "\\fileshare\references\fileX.dll" "C:\WINDOWS\system32\fileX.dll"
regsvr32 "C:\WINDOWS\system32\fileX.dll"
Here are the DLL's affected:
comdlg32.ocx (registered)
mscomctl.ocx (registered)
stdole2.tlb
MS09.dll
MSACC9.OLB
msoutl.olb
MSWORD.OLB
VBE6.DLL (registered)
dao360.dll (registered)
msado21.tlb
More often than not the batch script simply replaces a user's DLL with the same version of the same DLL. However, for some reason after this batch script executes and a user tries to open a document in Office 2007, a configuration wizards pops up and steals focus from the document only to require a reboot to finish.
While this isn't really a critical work-stopping issue, it is certainly an annoyance. The obvious guess is that it is one of the Office 2007 DLL's, but I haven't been able to isolate which DLL is the culprit.
Any input is greatly appreciated!
It's my understanding that you should not be distributing the OLB files. They are included in the install of Office, and will already be present on any workstation that has office installed.
You also should not be installing any ADO, DAO, or any other MDAC/WDAC components manually.
For older OS's, you should run an installer (MDAC_TYP.EXE) that installs the entire set of Data Access Components; google for MDAC installer for more info. On newer OS's, WDAC is installed as part of Windows.
Of your list, these are the only files that I would consider safe to distribute:
comdlg32.ocx
mscomctl.ocx
stdole2.tlb (although, this REALLY shouldn't be necessary)
All of the other files are either part of Office, and should already be on the box, or are part of WDAC/MDAC.
If absolutely necessary, you can always install the Access 2000 Runtime. This would allow users that do not have Access 2000 installed to still be able to start your application.
Related
Utility under discussion: Microsoft word 2010 add in using .Net3.5
Target platform Windows Server 2008 R2, Microsoft Office 2010 professional 32 bit
In Visual studio setup project i add registry enftries in HKCU as well as in HKLM. As per my research Addin to be made available to all users registry has to be added in
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\Word\Addins\myaddin.
but when i install my addin on target machine HKCU entries are correcrt so administrator can use the installed addin but for HKLM it becomes
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Wow6432Node\Microsoft\Office\Word\Addins\myaddin
so when users logg in through AD they dont see the add in. every time i have to manually write enties in
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\Outlook\Addins\myaddin
through server administrator account. Why is extra Wow6432Node added after Wow6432Node
please guide what am i missing.
You are not supposed to add "Wow6432Node", it is handled automatically by the system, depending on your setup type (x86/x64). In particular, depending on whether the component in setup is x86 or x64.
Visual studio generates x86 setup, this this node should be added automatically.
Try simply removing this "Wow6432Node" part.
I have a VB.NET application that uses a .accdb access file (2010 version) as a backend. The application only reads from this DB file, no writing ever. The application and database file need to be deployed together on the user's PC.
I understand that users will need either:
1) Full version of Access installed already or
2) The runtime installed
in order for the application to run.
That's fine and dandy but my problem is that the AccessRuntime.exe is HUGE (175 MB) and I would rather not deploy it with my app if I don't have to. Is there a way to just deploy the needed Runtime DLLs/files with my VB app and DB file? If so, what/where are these files located?
If your .NET application will just be reading the Access database file via System.Data.OleDb or System.Data.Odbc then you don't need the Microsoft Access Runtime. You just need to have an Access database engine installed, either
the older "Jet" database engine, if you only need to access .mdb files from 32-bit applications, or
the newer "ACE" database engine if you need to access .accdb files (or .mdb files from a 64-bit application).
Since your database apparently does not need any specific Access 2010 features you can just convert your .accdb file to an .mdb file and use the "Jet" database engine that is already installed on all Windows machines. However, Jet is only available to 32-bit applications so you need to go into your VB.NET project and target it to the x86 platform so it will always run as a 32-bit application (even on 64-bit machines).
Edit
If you want to manipulate an .accdb database file then you need to ensure that the Access Database Engine ("ACE") is installed on each machine. The installer is available for download here:
Microsoft Access Database Engine 2010 Redistributable
Notes:
There are both 32- and 64-bit versions of the ACE database engine. The installed version must match the "bitness" of your application (32-bit or 64-bit). This can be tricky, because Microsoft has designed the ACE installers so that you can have either the 32-bit or the 64-bit version installed. (There is a workaround that can force-install both, but it is not recommended because it can break Microsoft Office.)
Further to point #1, so even if you target your .NET app to the x86 platform and require the 32-bit version of ACE you can still have difficulties dealing with target machines that already have the 64-bit version of Office installed. They cannot install the 32-bit version of ACE because the 64-bit version is already installed. So, to use your app they would have to uninstall the 64-bit version of Office and install the 32-bit version.
As far as I know there is no practical way to include the ACE installer in the setup program for your application. Your users would need to download and install the appropriate version (from the link above) for themselves.
An amateur programmer has made a nice little program that works through VBA on top of a MS-Access2010 database. We are asked to make an installer for this database+VBA project. The code runs fine on any computer with Office installed, but on computers without Office we get the error above. On computers without office we install the MS-Access2010 Runtime, which is free, in order to be able to open the .accde file at all. But this does not prevent the VBA error.
I did some research on the issue but did not find anything related to this specific scenario. How can this be troubleshooted?
The problem was a version mismatch between the .accde file (sp1) and the installed ms access 2010 runtime (original) After upgrading the runtime to sp1 all was fine.
I'm not an experienced vba programmer and working with access is not my cup of tea. I've been asked to fix some errors in an MS Access 2010 VB application. The sole user previously ran the application on a 32-bit platform but now has migrated to 64-bit. This caused the aplication to break. I have made some progress but every issue I resolve another seems to appear.
The following piece of code
DoCmd.OutputTo acOutputReport, "rptQLDExport", acFormatRTF, frm.txtDirectory.Value + "\QLD\All\QDATA.DOC"
is causing a runtime error 2587: Microsoft Access can't complete the Output operation
I have seached on the net for an answer but to no avail.
My development environment is Windows 7 SP1 (64-bit) and the application is running in Access 2010 (vba7, 64-bit). I'm willing answer questions to provide more information. Any suggestion will be appreciated.
This forum post suggests it is related to runtime versus full versions of Access (or Office). The suggested solution is to Copy the file UTILITY.ACCDA from the ACCWIZ directory to the same directory as MSACCESS.EXE
You would need to check licensing before distributing the file in your application installer, obviously.
Update: On a machine that fails, copy over ProcessMonitor (from technet; no install required). Filter to your application. Repeat the process and get it to fail. Examine the files that your application is trying to access and why they fail.
I'm trying to diagnose why my Outlook plugin written in C#/VSTO 3.0/VS 2008 doesn't load after being installed.
The plugin works awesomely on my development machine, which has Visual Studio 2008 installed. I can't expect all my users to have all the prerequisites though so I went through these steps to write an installer:
http://msdn.microsoft.com/en-us/library/cc563937(loband).aspx
I installed the add-in on a fresh Windows XP SP 2 machine with a fresh install of Outlook 2007. It installs all the prereqs ok (.NET 3.5, VSTO 3.0 runtime, Windows Installer 3.1, 2007 PIAs). Outlook starts but the add-in isn't run. If I go to the Add-ins tab in the Trust Center, I see my add-in in the "Inactive Application Add-ins" section with the message "Not loaded. A runtime error occurred during the loading of the COM Add-in.".
Not sure how to find the specific error so I can fix it.
The reg keys look ok. Under HKEY_CURRENT_USER\Software\Microsoft\Office\Outlook\Addins\BlahAddin I see Description, FriendlyName, LoadBehavior (set to 3 until it fails after which if becomes set to 2), and Manifest.
Tried the VSTO_SUPPRESSDISPLAYALERTS environment variable trick and then launched Outlook from the command line but no output came out.
I have remote debugging more or less working but I'm not sure what to look for. I don't see my DLL loaded when I attach to Outlook, but then again maybe managed DLLs don't show up the same way in VS.
Any other ideas on next steps I could follow to produce a specific error I can diagnose?
Solved my problem after weeks of pain. The "Manifest" reg key was getting corrupted to some junk value during the setup build. It was a known Visual Studio bug that supposedly got fixed in Visual Studio 2008 SP 1, but apparently wasn't for me. Renaming the project name to be different from the plugin name fixed the problem. Random, huh?
Make sure you have try-catch handlers at the top level of all methods called by Outlook and log any exceptions you are unable to handle in some way. Focus your troubleshooting on methods like the Startup method and other methods called during initialization.
You probably want to debug this using the remote debugger. Share out the MSVCMON.EXE folder from your developer machine (in your Visual Studio folders in Program Files) on your test machine (share it with a UNC path), and launch Outlook under the debugger trapping (.NET) exceptions in your modules and putting breakpoints in your methods.
If you need to clean your test computer each time before you install your solution, you should probably run XP under a Virtual PC 2007 VM (free download) and switch to a differencing HD after setting up everything but your plugin to snapshot your pre-installed state once so you don't have to keep uninstalling/reinstalling as you make changes to your program to fix bugs.
Are you installing Debug builds or Release builds? Perhaps one flavor has different requirements. Just guessing.
-Mike [MSFT Office Dev]
On your machine, when you run the addin from Visual Studio, it should create a registry key in HKEY_CURRENT_USER\Software\Microsoft\VSTO\Security\Inclusion{SomeGuid}. Make sure that these registry settings are also being deployed with your addin. They are the ones that allow your code to be trusted.