Hopefully this is placed in the right area, but I seem to be having an issue with a registered dll.
Our main application is written with Power Builder Version 11, and through various objects, we are able to call registered C# .dll's
The C# .dll is created in Visual Studio 2008 and is installed via an installer that someone else in the building made. When a user runs the installer, they are given the option to register it for everyone or 'Just Me'
The .dll is installed successfully and the user that did the install is able to run the Power Builder application and call the functions inside the .dll.
The issue that arises is that any other user that runs the Power Builder application is greeted with a message box that says: Unable to connect to: [my dll].
I tried to re-register the .dll (using Regasm) but that doesn't work. I have confirmed that the folder is in the PATH System Variable.
The only solution I found was to uninstall the .dll from the Control Panel and re-install it from scratch. But, the same issue arise after the install.
What could the issue be? I'm starting to think that it has to be a rights issue but I can't be 100% positive.
Related
I'm migrating a VSTO OUTLOOK add-in from 32-bit to 64-bit. It works well on Office 2007 32-bit. The goal is to make it run on Office 365 64-bit.
I have recompiled the add-in for a 64-bit plateform and updated the installshield project.
When I install the add-in on a new Windows 10 machine using my account (I have admin privilege), it works fine. I can see it in Outlook and I can use it.
However, if I log out and ask someone else to log in on the save machine (this someone else also has admin privilege), the add-in shows up in Outlook but this error is shown when the user uses it:
System.Runtime.InteropServices.COMException (0x80040154): Retrieving
the COM class factory for component with CLSID
{29AB7A12-B531-450E-8F7A-EA94C2F3C05F} failed due to the following
error: 80040154 Class not registered (Exception from HRESULT:
0x80040154 (REGDB_E_CLASSNOTREG)).
Any idea?
Details:
This add-in uses only one external DLL: a 64-bit DLL from Redemption.
The solution has been compiled in Visual Studio 2015. Platform target: x64.
To install it on a computer, I use a MSI that I've created using InstallShield Express on Visual Studio 2015.
In InstallShield, I have specified ALLUSERS-1 (Per-machine installation).
The DLL is registered using the following code:
Dim WshShell
Set WshShell = CreateObject("Wscript.Shell")
WshShell.run "regsvr32 /s ""C:\Program Files (x86)\MyCompany\AddInName\Redemption64.dll"
Set WshShell = nothing
Actual Steps: Just an attempted, pragmatic summary on top: 1: Whilst logged in as the second user, try to launch regedit.exe and export HKCR (maybe HKCU as well), then register the COM dll, export again and diff with a suitable diff tool (if the launching worked at all that is). 2: Download ProcMon.exe and monitor your application / add-in launch to determine what is going on.
3: Use Visual Studio and step-through and checking the Modules view to determine what is going on during launch. 4: Use oleview.exe to see what registration the COM file requires (open embedded typelib). File => View Typelib.... More details below.
Quick Check: Maybe check this first: Outlook Redemption - using RedemptionLoader without regsvr32 the DLL.
Also, did you shut down everything before the second user logged on? Or did you just switch users? Maybe try both, make sure your first login has nothing loaded or locked.
The below "registration debugging" might miss the target. It looks like this could be something more peculiar. Maybe just skim it.
Deployment Mnemonic: Maybe try this deployment mnemonic. A little paragraph with reminders how you can think to try to solve deployment problems: "What is locking, what is blocking, what is missing, etc..."
Registration: Though this looks like a simple missing registration, it could be something more peculiar. I have this application launch check list that you can skim. Not written for add-ins, but might give you some ideas.
regsvr32.exe: Did you try to run regsvr32.exe manually as the second user to check if that works? Though it is possible to register a COM file per-user, I don't know of a way to use regsvr32.exe to do so that is reliable.
ProcMon.exe: Are you familiar with using ProcMon.exe? Her is a rudimentary example. And Hanselman showing how it is done (YouTube). You can use that to try to determine what is failing and when. Needs some practice to use effectively, but it is my "first and last resort".
Visual Studio: I like to use Visual Studio to step through the code and look in different windows (modules for example) to understand how the application works and hence to determine what can be wrong during launching.
oleview.exe: To figure out what a COM-file registers during self-registration there are several ways. Launching oleview.exe with admin rights and then going File => View Typelib... and then locating the COM file you want to check and opening gives you the embedded IDL details.
RegSpy2.exe: Alternatively you can use RegSpy2.exe for COM registration extraction. See sample here.
Capture Compare: Finally a setup capture tool can be used for debugging. It scans the registry (and disk) for before and after changes. In other words you make a baseline, register the dlls and then scan for differences. The reliable tools are expensive (AdminStudio, Advanced Installer Architecht, etc...). The poor man's version of a setup or registration capture is to export HKCR before and after using regedit.exe, and then diffing with a file/text-diff tool.
Self-Registration: Self-registration is not recommended for COM registration as described here: MSI register dll - Self-Registration considered harmful. In Installshield you can simply register a COM file by extracting the COM data at build as illustrated in the image below. You can also enable COM-Interop registration in the same list by setting the flag ".NET COM Interop" to yes:
.
COM Interop: .NET assemblies can be registered for COM use using regasm.exe. That is (almost) the same as the .NET COM Interop setting mentioned above set to "yes". If you want to use a COM file from .NET you need to generate an Interop assembly file and then installing and registering the real COM file (which you do). Both operations must be performed.
Throwing in a couple of links. These (ancient) articles deal with the use of regasm.exe, tlbexp.exe, tlbimp.exe and gacutil.exe. Not needed for you, but leaving in for reference:
Calling COM Components from .NET Clients
Calling a .NET Component from a COM Component
Some Links:
Registering COM EXE with WIX
Registering a CPP dll into COM after installation using Wix Msi installer
Application is not getting opened after installing it with the installer created by "Visual studio installer"
On a Windows 7 x64 I have have written an application which also includes a .dll which is installed to the GAC. This has been working without error for about 3 years. I recently made a new version of my Application but did not change the version of the .dll. The application starts at boot time and now I get a message from Windows...
Caution ... You are attempting to open a file of type "Application Extension" .dll
And then it wants you to choose a program to run it with.
I uninstalled this version and installed my previous version and I do not get the error.
I have no idea where the problem is so my tags are an attempt to get the ball rolling. Wix is my installer program which might have something to do with it.
How is my Application started at boot time
There is a registry entry in \Software\Microsoft\Windows\CurrentVersion\Run which has a path to the Application's .exe file. This Applicaion has the dll as a reference.
So if you remove it from autostart and start it after the pc is fully up, does the same message appear ? If that worked, a workaround would be registering your app as a service and set its startup to delayed.
When i googled your error some malware- threads came up. If you straight up load your dll and its unsigned e.g. via rundll32.exe that might cause an issue - but i dont entirely know how your autostart-entrypoint looks like.
I'm following the excellent tutorial by Malte Ahrens on how to create a OneNote add-in.
Initially I followed it step by step, making a few changes (just renaming the class, and using my own name and GUID in the assembly) info. As I'm using VS2012 and am not yet ready to hand-roll a WiX installer I manually copied over the built dll to the correct place and also created a registry file to make the requisite entries. I confirmed that they were all there, loaded up OneNote but no add-in, going to "mange COM addins" section I saw the following error:
Load Behavior: Not loaded. A runtime error occurred during the loading of the COM Add-in.
I spent some time debugging this but didn't get very far. So this afternoon I decided to start again but copy his code verbatim. I simply downloaded the example project, used the trial of Vdproj to Wix to create the installer and built everything.
I get the exact same error.
Why is this please? What does this mean and most importantly how do I debug the problem?
A few specifics about my environment and where it may differ from the original tutorial.
I am running Office 2013 AND it's 64bit. His tutorial is for 2010. This means when I loaded up the demo solution I had to remove the non-existent reference to the Onenote 14 Interop and add the v15 version.
In terms of registry entries they go to the right place, not the WOW6432 registry nodes. I doubly know this as if I load up OneNote and then refresh the HKCR registry node for the add-in, the LoadBehavior switches to 0x00000002, (disabled).
Other things that may be worth noting.
I have enabled OneNote logging and it's quiet on my issue.
There are 2 other posts on here with a seemingly similar problem (but Office 2010) here and here, neither got a response. The first guy had it loading once, but then had to manualy start it each time, mine never loads (and I've not signed my assembly) the second guy never got a response.
As I say, even knowing how to debug this further would be a great step forwards.
Edit:
I've gone back to debugging my own version, which is almost identical anyway as I'm not sure what the installer is actually doing and I think because it's a demo of the wix converter it's only allowing me to build for x86.
If I add OneNote.exe under "start external program" and run debug on my add-in, I see the following lines appear when I try and tick the add-in under "manage COM add-ins" within OneNote. I'm afraid I'm still pretty green at all this so I'm not sure what it means.
First-chance exception at 0x00007ffe4f86ab78 in ONENOTE.EXE: 0x800401FD: Object is not connected to server.
First-chance exception at 0x00007ffe4f86ab78 in ONENOTE.EXE: 0x800401FD: Object is not connected to server.
First-chance exception at 0x00007ffe4f86ab78 in ONENOTE.EXE: 0x800401FD: Object is not connected to server.
Also, since reading up more I think me simply copying my dll into the install folder program files\[manufacturer]\[application] (as I don't have an installer) was not enough. I've now executed this against my dll
PS C:\WINDOWS\Microsoft.NET\Framework64\v4.0.30319> .\RegAsm.exe
and it came back with
Microsoft .NET Framework Assembly Registration Utility version 4.0.30319.33440
for Microsoft .NET Framework version 4.0.30319.33440
Copyright (C) Microsoft Corporation. All rights reserved.
Types registered successfully
Is there anything else I should be doing to register the dll correctly?
Enable logging for OneNote 2013:
Create a file "EnableOneNote2013APILogging.reg"
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\OneNote\Options\Logging]
"EnableLogging"=dword:00000001
"EnableTextFileLogging"=dword:0000001
"ttidLogObjectModel"=dword:00000001
"ttidLogObjectModelAddins"=dword:00000001
Create a file "DisableOneNote2013APILogging.reg"
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\OneNote\Options\Logging]
"EnableLogging"=dword:00000000
"EnableTextFileLogging"=dword:0000000
"ttidLogObjectModel"=dword:00000000
"ttidLogObjectModelAddins"=dword:00000000
This is based on http://blogs.msdn.com/b/descapa/archive/2006/12/08/debugging-the-onenote-api-enable-logging.aspx but you need to add EnableTextFileLogging ;-).
The logfile is created in %temp%\OneNote.log
For OneNote 2010 change the path in the .reg files to \14.0\ instead of \15.0\
I'm not very experienced with deploying applications and i'm having an issue with my very small screen scrape application.
I use a project that handles all screen scrapes and i just call the functions from the dll(on dev machines at least). When i reference that dll from the directory, it works fine on my machine but installing and launching on another machine without the project crashes it immediately when it tries to access the class to instantiate the screen scrape object.
Perhaps my assumption of dll is incorrect but doesn't having the dll mean it incapsulates all the classes/references/etc in that project so it can be used elswhere without having to lug the whole project with it?
What could be going on with this dll?
The dll assembly encapsulates the project, but not its references. Anything that the project needs to reference must be available in the new environment as well, whether in the GAC (global assembly cache), the local directory, in a reference path, or wherever.
If you are using Visual Studio 2010 or earlier, you can use Setup Projects to nicely gather all necessary references and package them into an install package for you. There may still be complications that you will need to troubleshoot sometimes, but it simplifies your deployment effort. In Visual Studio 2012 and later, Setup Projects were dropped, but there are other options, like WIX and Install Shield. And that is a whole other topic with plenty of Q&A on this site.
I've created my first Office Add-in using Visual Studio. It targets the 4.0 .Net framework and was created using the new VS 2012. I need to distribute/install this project on various 32-bit XP and 64-bit Windows 7 computers around the office. So I configured the project to be installed on XP (which was my first speed bump because I didn't realize VS 2012 needed an update in order to make a solution that was XP compatible). Now that I have a valid win32 application, I am getting another error:
The following error occurred attempting to install 'C:\filepath...\Import Contacts.vsto':
"No application is associated with the specified file for this operation."
After doing some digging, I think I need to install the Microsoft Visual Studio Tools for Office Runtime on the client computer. To do this, I would like to use the prerequisites properties for the project. So I read up on creating custom prerequisites using some noteworthy sites (e.g, Creating Bootstrapper Packages, Application Deployment Prerequisites, Adding Custom Prerequisites, and Creating a Bootstrapper package for Office 2013 in Visual Studio 2012). I created the files according to that last URL (even though I'm not sure it pertains to the package I need just yet), but it is not appearing in the dialog box under Project > Properties > Publish > Prerequisites
If you read the article, it says the VS prerequisites dialog box should automatically update once I restart VS 2012, which I did but to no avail. I know I'll need to use this feature again in the future, so I would really like to know what I'm doing wrong and fix this. Please help! And I promise to quickly give the ACCEPT to whoever helps me fix this problem! Thank you in advance.
I didn't have any problems following the directions given in the web page and got the bootstrapper added to the Prerequisites dialog. However, there are plenty of possible ways to get it wrong. Some possibilities:
Triple-check the folder you added these files to. Be sure that you picked Program Files (x86) on a 64-bit version of Windows and not Program Files. And be sure that you now see the added VSTOR40 folder along with the other existing bootstrapper folders, like ReportViewer and VBPowerPacks.
You do not have write permission to this folder, UAC prevents copying files there. Be sure that you managed to copy them from, say, an elevated command prompt. Right-click the Command Prompt shortcut and click "Run as Administrator".
If you created the .xml files with Notepad then make sure you didn't accidentally saved them with the .txt extension. If necessary, put Explorer in "programmer mode" so you can see the filename extensions. Control Panel + Folder Options, View tab, untick the "Hide extensions for known file types" checkbox. If you now see product.xml.txt then rename the file to product.xml, same for package.xml.txt
If you created the .xml files with Notepad then be sure to save the file in UTF-8 encoding. File + Save As, Encoding combobox.
For all those who still may face similar issue I think that I found the cause of this issue. It seems that copying folder with custom bootstrapper package (and all necessary files in it) does not "refreshes" the list of available packages. Only when i went through this walkthrough and manually created folder in %Programfiles%\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages\ for sample package from this walkthrough my package has shown