I'm trying to get a vbScript to work in an hta.
The vbs works fine when I run it independently, but when I try to use it in the hta, it is unable to load the dll file.
I have tried using regasm / codebase to register the dll but that didn't help either. Using regsvr32 is not an option as it cannot be run as an Administrator on the computers.
I'm using ExecuteGlobal to get the vbs file into the hta but I have also tried making a command that just runs the vbs from hta, but it still failed.
Have I overlooked something trivial?
You can register COM dlls with Regsvr32 (usually, but there are exceptions, like RTF 5 and later control). You can register .NET dlls pretending to be COM dlls with RegAsm. Both require admin access.
*.NET dlls register the core .NET dll as the COM handler, which dispatches the COM call to the .NET component DLL, unlike COM where nothing usually gets in the way.
To register a .NET dll without being admin requiresyou to export as a reg file from RegAsm (non admins can do). Search and replace HKCR with HKCU\Software\Classes. The reg file can then be merged by non admins.
when telling windows to run an hta it will automatically assume 32bit. to get it to work on 64bit systems use %WinDir%\System32\mshta.exe c:\page.hta
some sort of wrapper or launcher is needed to make sure you are running the correct mshta version
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"
I've written a DLL that provides methods for extracting data from a MySQL DB and generating a report using the built-in report viewer in VS 2012. The idea is to use this in a VB6 program. I've gone through the following process:
1) Build the DLL in VS with "register for COM interop" selected
2) Placed the DLL and TLB file in the directory of the VB6 program on another machine
3) Used regasm: "regasm Report.dll /tlb: Report.tlb /codebase" (redundant step if I already have the TLB file generated by VS?)
4) Added the TLB file to project references in VB6
The VB6 program builds and executes okay, but when I got to run my report I just get "Automation error: the system cannot find the file specified".
I've gone through the above process for a trivial DLL according to the instructions given here. This worked fine. I suspect that the references used in my DLL (MySQL.Data and Microsoft.ReportViewer.WinForms) may also need to be registered on the VB6 machine. I've been able to do this with MySQL.Data but not the ReportViewer DLL.
If it makes a difference, the DLL was built on a Windows 7 64 bit machine whereas the VB6 machine runs XP 32-bit.
Thanks in advance.
Turned out the problem was that I needed to set the Copy Local property for Microsoft.ReportViewer.Common and copy the relevant DLL files along with my own DLL. Hope this helps anyone with a similar problem.
I have a VB6 app that utilizes a non-activeX DLL (non-registering).
It's declared via the classic Public Declare Function "Function Name" Lib "Library.DLL" syntax.
On my dev machine (XP) it works fine but when I deploy to Vista or Win7 I'm constantly greeted with a Run Time Error 48 - File Not Found for the DLL in question.
I have tried copying that DLL to every directory I can think of including every environment path on the test machine and the app path too.
These are all 32-bit test environments so it's not a SysWow64 issue.
Possibly throwing a wrench into the mix is the fact that the application in question is an Outlook COM Addin.
I managed to install VB6 on Win7 and was able to run a tiny sample app that utilizes this DLL (outside of the Outlook process) so I know it works PROVIDED the DLL is located in App path. If I call App.Path from my DLL when I run it on the test environment it shows, to no surprise, my installation directory however the DLL is there.
I tried turning off UAC. I tried making the App.Path directory permissions open to everyone, still no dice.
According to the details you give, it looks like placing the DLL in the path of standard Add-in locations would help.
I believe the first place a DLL search looks is the directory that the EXE loaded from, so your DLL's App.Path won't be used.
Are you sure that you tried installing this DLL into System32? Into Windows?
Aside from that you should be ble to create a PATH (messy) or an isolation manifest for the calling code (VB6 if I'm following you) that specifies DLL Redirection to a relative path (i.e. a subfolder under the folder with your VB6 code in it).
See Dynamic-Link Library Search Order
You may want to check the DLL's own dependancies. You will get the same error if it couldn't load the DLL in question or some DLL 20 levels deep in the dependancy chain.
I have one problem in vb6. I created a .tlb file in VB.net 2005 by adding Com class to project. I built the project, I got .tlb file and .dll files while building project, i selected "Register for Com interop" from project properties and built. It registered autometically and I can use created .tlb file in that PC in Vb6 working fine. if I deploy application to another PC and run I am getting "Error 429 ActiveX Component Can't create object" run time error. What I need to do? Please help me as soon as possible. I can't deploy the application to client due to above error.
one possible solution is to install .net frame work on client pc i never want to install .net framework any other solution will be most appreciatable.
If you've created a DLL in a .NET language (such as VB.NET), the target computer must have the .NET Framework installed in order to use the DLL.
This a hard and fast requirement, irrelevant of how you're utilizing the DLL, whether from a VB 6 application through COM interop or otherwise. It is also a hurdle you'll have to jump over first, before you worry about things like registering COM components, as Uday's answer suggests.
If you don't want a dependency on .NET, you need to use another environment to create the ActiveX DLL; either C++ or VB 6 are possible choices.
One option may be that, while deployment, you need to register that .tlb file in System Registry using regsvr32 command in command-prompt. Generally static libraries does not work until they are registered with System Registry.
You might have seen many programs register components during installation like 'Registering Type Components' or 'Registering COM Components' (for those who do networking especially). Those components are nothing but native COM dlls and tlbs.
so when creating deployment project, add some scripting login to register thode dlls and tlb to System registry using:
regsvr32 <path to tlb/dll>
you have to recursivey call this command for every dll/tlb you want to register with system. For example, if you have 4 dlls and 2 tlbs then you have to call it 6 times providing the path of dll and tlb one at a time.
I am writing a C# program that interface with COM object through COM interop.
I have a third-party program that register itself as the COM server when I execute the Application. This works fine in 32-bit Windows Vista and I can interface with the interop just fine. (The reference show up in "COM" tab from Visual Studio when you click "Add Reference")
However, the reference does not show up in "COM" tab on my 64-bit Windows 7 machine after I execute the application. Any thoughts, why would this happen? I actually tried using regsvr32.exe to register the application manually but it didn't work either (error message saying "entry-point DllRegisterServer was not found)
You are not going to be able to use it as long as it doesn't show up in the COM tab. The regsvr32.exe utility is for DLLs, this however sounds like an EXE. If it is a DLL then it needs to be registered with the 32-bit version of regsvr32.exe, the one in c:\windows\syswow64. If it is an EXE then the normal way to get it to register itself is by running it with the /regserver command line option.
Mumble.exe /RegServer
Additionally, if this is a DLL or an EXE for which you don't have a 64-bit proxy/stub then you'll have to force your app to run in 32-bit mode. Project + Properties, Build tab, Platform Target = x86.
If all else fails, you really do need support from the vendor of this program. Surely they'll have an update available that is verified to work properly on 64-bit operating systems. If they are no longer around, running this in a virtual machine is always a possibility.
If it is a managed dll then you might try using RegAsm
REGASM AssemblyName.dll /tlb:AssemblyName.tlb
You may find this helpful as I needed to recompiled and build 64 bit proxy stub for the COM server from C++ myself and it kept failing when trying to register the server using /regserver. Here is and thread from miscrosoft that helped me resolved this issue. Basically you need to use this instead /RegServerPerUser, but go through the thread if you get into this situation after the answers from above.
http://social.msdn.microsoft.com/Forums/en/vcprerelease/thread/11f01ceb-52a4-438f-b7ef-727ce7a3e191