I have a VB.net project that builds and registers a COM library that I can open and use in Excel on my development machine. That machine happens to have 32-bit Excel. On my other machine Excel installed in 64-bit and will not open the library, 429.
Other threads have suggested that the code itself is likely fine, as long as I compile under "Any".
Is that correct? Is code compiled for "any" generally able to run on 32 and 64-bit?
The same threads suggest that the only real problem is the tlb/registration, and point to articles that suggest manually calling regasm to avoid this.
Is this correct?
If so, am I supposed to have two tlb files? Or two COM libs? Or just one?
Ok, it's working. I still don't understand why this solution works, but here it is:
compile the DLL using the "Any CPU" setting
turn OFF COM registration, it doesn't hurt but it will just confuse things later
add two lines to your VS project's post-build:
"%Windir%\Microsoft.NET\Framework\v4.0.30319\regasm" "$(TargetPath)" /tlb:DCFPropery32.tlb
"%Windir%\Microsoft.NET\Framework64\v4.0.30319\regasm" "$(TargetPath)" /tlb:DCFPropery64.tlb
copy the DLL and TLB's to the target machine
determine the bit-ed-ness of the target machine's office:
http://www.howtogeek.com/howto/24259/
run the correct version (32 or 64) of regasm on that machine with the following switch:
FOR 32-BIT OFFICE
c:\windows\microsoft.net\frameworks[version number]\regasm [path to dll] /codebase
FOR 64-BIT OFFICE
c:\windows\microsoft.net\frameworks64[version number]\regasm [path to dll] /codebase
open Excel on the target platform and navigate to the VBA editor's References dialog. Browse… to the location of the files, and select the correct bit-edness version of the TLB for your platform.
And hopefully that works for all of you too!
This solution is far from ideal. For one, Microsoft keeps moving the location of regasm, so there's no simple way to script this. For another, I have no idea idea why I need to call /codebase, but it appears to have something to do with the naming of the files. Finally, this means that all such work will require at least a little manual work on each and every machine you want to run it on, or you'll need to go through the trouble of making an installer!
Related
I would like to know when do we need to place a file under
C:\Windows\System32 or C:\Windows\SysWOW64, on a 64-bits windows system.
I had two DLL's, one for 32-bit, one for 64-bit.
Logically, I thought I'd place the 32-bit DLL under C:\Windows\System32, and the 64-bit DLL under C:\Windows\SysWOW64.
To my surprise, it's the other way around! The 32-bit one goes into C:\Windows\SysWOW64, and the 64-bit DLL goes into C:\Windows\System32.
Very confusing stuff. What's the reason behind this?
I believe the intent was to rename System32, but so many applications hard-coded for that path, that it wasn't feasible to remove it.
SysWoW64 wasn't intended for the dlls of 64-bit systems, it's actually something like "Windows on Windows64", meaning the bits you need to run 32bit apps on a 64bit windows.
This article explains a bit:
Windows x64 has a directory System32 that contains 64-bit DLLs (sic!).
Thus native processes with a bitness of 64 find “their” DLLs where
they expect them: in the System32 folder. A second directory,
SysWOW64, contains the 32-bit DLLs. The file system redirector does
the magic of hiding the real System32 directory for 32-bit processes
and showing SysWOW64 under the name of System32.
If you're talking about an installer, you really should not hard-code the path to the system folder. Instead, let Windows take care of it for you based on whether or not your installer is running on the emulation layer.
I should add: You should not be putting your dll's into \system32\ anyway! Modify your code, modify your installer... find a home for your bits that is NOT anywhere under c:\windows\
For example, your installer puts your dlls into:
\program files\<your app dir>\
or
\program files\common files\<your app name>\
(Note: The way you actually do this is to use the environment var: %ProgramFiles% or
%ProgramFiles(x86)% to find where Program Files is.... you do not assume it is c:\program files\ ....)
and then sets a registry tag :
HKLM\software\<your app name>
-- dllLocation
The code that uses your dlls reads the registry, then dynamically links to the dlls in that location.
The above is the smart way to go.
You do not ever install your dlls, or third party dlls into \system32\ or \syswow64. If you have to statically load, you put your dlls in your exe dir (where they will be found). If you cannot predict the exe dir (e.g. some other exe is going to call your dll), you may have to put your dll dir into the search path (avoid this if at all poss!)
system32 and syswow64 are for Windows provided files... not for anyone elses files. The only reason folks got into the bad habit of putting stuff there is because it is always in the search path, and many apps/modules use static linking. (So, if you really get down to it, the real sin is static linking -- this is a sin in native code and managed code -- always always always dynamically link!)
Ran into the same issue and researched this for a few minutes.
I was taught to use Windows 3.1 and DOS, remember those days? Shortly after I worked with Macintosh computers strictly for some time, then began to sway back to Windows after buying a x64-bit machine.
There are actual reasons behind these changes (some would say historical significance), that are necessary for programmers to continue their work.
Most of the changes are mentioned above:
Program Files vs Program Files (x86)
In the beginning the 16/86bit files were written on, '86' Intel processors.
System32 really means System64 (on 64-bit Windows)
When developers first started working with Windows7, there were several compatibility issues where other applications where stored.
SysWOW64 really means SysWOW32
Essentially, in plain english, it means 'Windows on Windows within a 64-bit machine'. Each folder is indicating where the DLLs are located for applications it they wish to use them.
Here are two links with all the basic info you need:
MSDN File System Redirector
SysWow64 Explained
Hope this clears things up!
System32 is where Windows historically placed all 32bit DLLs, and System was for the 16bit DLLs. When microsoft created the 64 bit OS, everyone I know of expected the files to reside under System64, but Microsoft decided it made more sense to put 64bit files under System32. The only reasoning I have been able to find, is that they wanted everything that was 32bit to work in a 64bit Windows w/o having to change anything in the programs -- just recompile, and it's done. The way they solved this, so that 32bit applications could still run, was to create a 32bit windows subsystem called Windows32 On Windows64. As such, the acronym SysWOW64 was created for the System directory of the 32bit subsystem. The Sys is short for System, and WOW64 is short for Windows32OnWindows64.
Since windows 16 is already segregated from Windows 32, there was no need for a Windows 16 On Windows 64 equivalence. Within the 32bit subsystem, when a program goes to use files from the system32 directory, they actually get the files from the SysWOW64 directory. But the process is flawed.
It's a horrible design. And in my experience, I had to do a lot more changes for writing 64bit applications, that simply changing the System32 directory to read System64 would have been a very small change, and one that pre-compiler directives are intended to handle.
Other folks have already done a good job of explaining this ridiculus conundrum ... and I think Chris Hoffman did an even better job here: https://www.howtogeek.com/326509/whats-the-difference-between-the-system32-and-syswow64-folders-in-windows/
My two thoughts:
We all make stupid short-sighted mistakes in life. When Microsoft named their (at the time) Win32 DLL directory "System32", it made sense at the time ... they just didn't take into consideration what would happen if/when a 64-bit (or 128-bit) version of their OS got developed later - and the massive backward compatibility issue such a directory name would cause. Hindsight is always 20-20, so I can't really blame them (too much) for such a mistake. ...HOWEVER... When Microsoft did later develop their 64-bit operating system, even with the benefit of hindsight, why oh why would they make not only the exact same short-sighted mistake AGAIN but make it even worse by PURPOSEFULLY giving it such a misleading name?!? Shame on them!!! Why not AT LEAST actually name the directory "SysWin32OnWin64" to avoid confusion?!? And what happens when they eventually produce a 128-bit OS ... then where are they going to put their 32-bit, 64-bit, and 128-bit DLLs?!?
All of this logic still seems completely flawed to me. On 32-bit versions of Windows, System32 contains 32-bit DLLs; on 64-bit versions of Windows, System32 contains 64-bit DLLs ... so that developers wouldn't have to make code changes, correct? The problem with this logic is that those developers are either now making 64-bit apps needing 64-bit DLLs or they're making 32-bit apps needing 32-bit DLLs ... either way, aren't they still screwed? I mean, if they're still making a 32-bit app, for it to now run on a 64-bit Windows, they'll now need to make a code change to find/reference the same ol' 32-bit DLL they used before (now located in SysWOW64). Or, if they're working on a 64-bit app, they're going to need to re-write their old app for the new OS anyway ... so a recompile/rebuild was going to be needed anyway!!!
Microsoft just hurts me sometimes.
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.
This is driving me crazy. I have developed a .NET COM DLL that is used by a VB6 DLL wrapper in order to update and replace some legacy functions in an application.
I am now trying to remove the requirement to use regasm on client machines so have worked out how to do that on a test DLL which all works fine.
I branched the DLL just in case and added an app.manifest file. Everything else worked out fine and I got it all working. The manifest is embedded and Visual Studio 2012 generates a mydll.dll.manifest file in the release folder.
Then I went back to the original trunk and added an app.manifest file (no point in merging as there were no code changes). I copied the contents of the branch into the app.manifest file and built the release version. The manifest is embedded in the DLL but no mydll.dll.manifest file is generated.
I know that it's not strictly necessary to have the mydll.dll.manifest file but I'd like things to be consistent (and for some reason the test process doesn't produce the same results with the trunk version) so how can I force it to be created?
This is a VB.NET DLL project so it doesn't have (or I can't find) the 'Generate Manifest' property drop down mentioned in the first answer here. How can I set this? Or is there a way to set it by editing the project file directly?
References:
Original walkthrough article and some corrections.
Overview by Junfeng Zhang in two articles plus a useful tool
You are making a fairly common mistake. A reg-free COM manifest helps an application find a COM server without looking in the registry to locate the DLL. Embedding the manifest in the DLL is like trying to solve the chicken and egg problem, Windows cannot possibly find that manifest if it cannot locate the DLL first.
The manifest needs to be part of the client app. Which is tricky since it is VB6, it doesn't support embedding manifests in its executables.
You could tinker with the mt.exe tool, an SDK utility that supports embedding manifests in an executable. You'd have to run it by hand after building the VB6 binaries. That's unfun and very likely to cause trouble when you forget. It is in general not a joyful tool to use, documentation is meager, incomplete and unhelpful, a chronic problem with manifests.
The fall back is a separate app.exe.manifest file, what Windows will look for next when it cannot find a manifest embedded in the executable. Where "app.exe" must be renamed to the name of the VB6 program. The EXE, not the DLL. This now also gives you a chance to avoid having to register the VB6 DLL, presumably what you really want if you truly want to make your program run reg-free. The disadvantage is that it will not work when you debug your VB6 program, wrong EXE. You'd also need a vb6.exe.manifest, located in the VB6 install directory.
Needless to say perhaps, very hard to get ahead with VB6 here. It just wasn't made to help you do this, they didn't have a time machine in 1998.
I have to admit that I don't know VB at all, but in the case of C++ and C# Visual Studio projects I previously had to resort to calling mt.exe in a post-build step in order to get the DLL manifest I wanted. Maybe that workaround would work in your case as well?
I would like to know when do we need to place a file under
C:\Windows\System32 or C:\Windows\SysWOW64, on a 64-bits windows system.
I had two DLL's, one for 32-bit, one for 64-bit.
Logically, I thought I'd place the 32-bit DLL under C:\Windows\System32, and the 64-bit DLL under C:\Windows\SysWOW64.
To my surprise, it's the other way around! The 32-bit one goes into C:\Windows\SysWOW64, and the 64-bit DLL goes into C:\Windows\System32.
Very confusing stuff. What's the reason behind this?
I believe the intent was to rename System32, but so many applications hard-coded for that path, that it wasn't feasible to remove it.
SysWoW64 wasn't intended for the dlls of 64-bit systems, it's actually something like "Windows on Windows64", meaning the bits you need to run 32bit apps on a 64bit windows.
This article explains a bit:
Windows x64 has a directory System32 that contains 64-bit DLLs (sic!).
Thus native processes with a bitness of 64 find “their” DLLs where
they expect them: in the System32 folder. A second directory,
SysWOW64, contains the 32-bit DLLs. The file system redirector does
the magic of hiding the real System32 directory for 32-bit processes
and showing SysWOW64 under the name of System32.
If you're talking about an installer, you really should not hard-code the path to the system folder. Instead, let Windows take care of it for you based on whether or not your installer is running on the emulation layer.
I should add: You should not be putting your dll's into \system32\ anyway! Modify your code, modify your installer... find a home for your bits that is NOT anywhere under c:\windows\
For example, your installer puts your dlls into:
\program files\<your app dir>\
or
\program files\common files\<your app name>\
(Note: The way you actually do this is to use the environment var: %ProgramFiles% or
%ProgramFiles(x86)% to find where Program Files is.... you do not assume it is c:\program files\ ....)
and then sets a registry tag :
HKLM\software\<your app name>
-- dllLocation
The code that uses your dlls reads the registry, then dynamically links to the dlls in that location.
The above is the smart way to go.
You do not ever install your dlls, or third party dlls into \system32\ or \syswow64. If you have to statically load, you put your dlls in your exe dir (where they will be found). If you cannot predict the exe dir (e.g. some other exe is going to call your dll), you may have to put your dll dir into the search path (avoid this if at all poss!)
system32 and syswow64 are for Windows provided files... not for anyone elses files. The only reason folks got into the bad habit of putting stuff there is because it is always in the search path, and many apps/modules use static linking. (So, if you really get down to it, the real sin is static linking -- this is a sin in native code and managed code -- always always always dynamically link!)
Ran into the same issue and researched this for a few minutes.
I was taught to use Windows 3.1 and DOS, remember those days? Shortly after I worked with Macintosh computers strictly for some time, then began to sway back to Windows after buying a x64-bit machine.
There are actual reasons behind these changes (some would say historical significance), that are necessary for programmers to continue their work.
Most of the changes are mentioned above:
Program Files vs Program Files (x86)
In the beginning the 16/86bit files were written on, '86' Intel processors.
System32 really means System64 (on 64-bit Windows)
When developers first started working with Windows7, there were several compatibility issues where other applications where stored.
SysWOW64 really means SysWOW32
Essentially, in plain english, it means 'Windows on Windows within a 64-bit machine'. Each folder is indicating where the DLLs are located for applications it they wish to use them.
Here are two links with all the basic info you need:
MSDN File System Redirector
SysWow64 Explained
Hope this clears things up!
System32 is where Windows historically placed all 32bit DLLs, and System was for the 16bit DLLs. When microsoft created the 64 bit OS, everyone I know of expected the files to reside under System64, but Microsoft decided it made more sense to put 64bit files under System32. The only reasoning I have been able to find, is that they wanted everything that was 32bit to work in a 64bit Windows w/o having to change anything in the programs -- just recompile, and it's done. The way they solved this, so that 32bit applications could still run, was to create a 32bit windows subsystem called Windows32 On Windows64. As such, the acronym SysWOW64 was created for the System directory of the 32bit subsystem. The Sys is short for System, and WOW64 is short for Windows32OnWindows64.
Since windows 16 is already segregated from Windows 32, there was no need for a Windows 16 On Windows 64 equivalence. Within the 32bit subsystem, when a program goes to use files from the system32 directory, they actually get the files from the SysWOW64 directory. But the process is flawed.
It's a horrible design. And in my experience, I had to do a lot more changes for writing 64bit applications, that simply changing the System32 directory to read System64 would have been a very small change, and one that pre-compiler directives are intended to handle.
Other folks have already done a good job of explaining this ridiculus conundrum ... and I think Chris Hoffman did an even better job here: https://www.howtogeek.com/326509/whats-the-difference-between-the-system32-and-syswow64-folders-in-windows/
My two thoughts:
We all make stupid short-sighted mistakes in life. When Microsoft named their (at the time) Win32 DLL directory "System32", it made sense at the time ... they just didn't take into consideration what would happen if/when a 64-bit (or 128-bit) version of their OS got developed later - and the massive backward compatibility issue such a directory name would cause. Hindsight is always 20-20, so I can't really blame them (too much) for such a mistake. ...HOWEVER... When Microsoft did later develop their 64-bit operating system, even with the benefit of hindsight, why oh why would they make not only the exact same short-sighted mistake AGAIN but make it even worse by PURPOSEFULLY giving it such a misleading name?!? Shame on them!!! Why not AT LEAST actually name the directory "SysWin32OnWin64" to avoid confusion?!? And what happens when they eventually produce a 128-bit OS ... then where are they going to put their 32-bit, 64-bit, and 128-bit DLLs?!?
All of this logic still seems completely flawed to me. On 32-bit versions of Windows, System32 contains 32-bit DLLs; on 64-bit versions of Windows, System32 contains 64-bit DLLs ... so that developers wouldn't have to make code changes, correct? The problem with this logic is that those developers are either now making 64-bit apps needing 64-bit DLLs or they're making 32-bit apps needing 32-bit DLLs ... either way, aren't they still screwed? I mean, if they're still making a 32-bit app, for it to now run on a 64-bit Windows, they'll now need to make a code change to find/reference the same ol' 32-bit DLL they used before (now located in SysWOW64). Or, if they're working on a 64-bit app, they're going to need to re-write their old app for the new OS anyway ... so a recompile/rebuild was going to be needed anyway!!!
Microsoft just hurts me sometimes.
I have just installed a third party app on my Windows Server 2008 server
and I get the
ActiveX Component can't create object
message when I try to access using a CreateObject in VBScript.
It is definitely installed and exists under "Programs and Features". Does anyone have a list of things that I can check to figure out what is going on?
I have now tried to register the DLL using regsvr32.exe /i bob.dll as suggested but I get this error:
The Module "Bob.dll" was loaded but the entry-point DllRegisterServer was
not found.
Make sure that "Bob.dll" is valid DLL or OCX file and then try again.
I should note that this is a 32-bit application on a 64-bit machine at
this point. It also works fine on my machine which is Windows XP 32-bit.
It turns out to get this application working under VBScript, I had to do two things.
Run RegAsm.exe to register the DLLs.
Run the C:\Windows\SysWOW64\cscript.exe to run my VBScript.
If these don't work, check out the other answer here about enabling 32-bit applications in IIS.
It's also worth checking that you've got "Enable 32-bit Applications" set to True in the advanced settings of the DefaultAppPool within IIS.
The app is trying to create a COM Object and even if that COM DLL exists, it may depend on another DLL which isn't installed. You can use DependencyWalker to find out if this is the case.
Check your browser settings.
For me, using IE, the fix was to go into Tools/Internet Options, Security tab, for the relevant zone, "custom level" and check the ActiveX settings. Setting "Initialize and script ActiveX controls not marked as safe for scripting" to "Enable" fixed this problem for me.
Also when you register the component make sure you use the 32-bit version of regsvr32.exe.
If you simply run regsvr32.exe in a elevated prompt, it will default take the standard 64-bit version (which oddly enough is located in C:\Windows\System32)
The version I believe you need is located in C:\Windows\SysWow64\regsvr32.exe
It really looks as though the object you are referencing is not registered on the system. I know you said it's installed, but that doesn't necessarily mean it's registered. To confirm this, search for the progID that you used in your registry.
Example for this code:
set objFSO = CreateObject("Scripting.FileSystemObject")
I would search for Scripting.FileSystemObject in the registry. Then I would look at registry key above the found value, for InProcServer32 value. This will give you the path to the ActiveX file that it was registered from (for Scripting.FileSystemObject the file is "c:\windows\system32\scrrun.dll").
If you can't find your progID in the registry, then it's not registered on your system which is your problem. If it's not registered you need to find out what file registers it, which is usually an .ocx or a .dll in the same folder path of your third party app, and then register these file(s). Here is the command to register a file:
regsvr32 /i "c:\windows\system32\scrrun.dll"
Even if you find the progID value in the registry and it references a file that is present on your system, you may still want to try re-registering the file. I have found that sometimes the registration got broken somehow somewhere and it was easier to re-register the files then it was to fix the issue.
If its a 32 bit COM/Active X, use version 32 bit of cscript.exe/wscript.exe located in C:\Windows\SysWOW64\
I know this is an old thread, but has anyone checked if their Antivirus is blocking Win32API and Scripting on their systems? I have CylanceProtect installed on my office system and i found the same issues occurring as listed by others. This can be confirmed if you check the Windows Logs in Event Viewer.
I also meet the same error in vbscript.
Set objFSO = CreateObject("Scripting.FileSystemObject")
Solution:
Open command line, run :
regsvr32 /i "c:\windows\system32\scrrun.dll"
and it works
I've had the same issue in a VB6 program I'm writing, where a Form uses a ScriptControl object to run VBScripts selected by the User.
It worked fine until the other day, when it suddenly started displaying 'Runtime error 429' when the VBScript attempted to create a Scripting.FileSystemObject.
After going mad for an entire day, trying all the solutions proposed here, I began suspecting the problem was in my application.
Fortunately, I had a backup version of that form: I compared their codes, and discovered that inadvertently I had set UseSafeSubset property of my ScriptControl object to True.
It was the only difference in the form, and after restoring the backup copy it worked like a charm.
Hope this can be useful to someone. Up with VB6! :-)
Max - Italy
I had the same issue with Excel, I was trying to use a 32 COM DLL with an Excel 64 bits version and I got this error. I rebuild the COM dll to a 64 bits version and the error disappears. So be sure that your COM dll has the same architecture (x86 vs x64) than your application.
I had this problem too. I was trying to run an old 32-bit dll in a 64 bit system. I got it working by copying the .dll to the C:\Windows\SysWoW64\ directory and running this:
%systemroot%\SysWoW64\regsvr32 "C:\Windows\SysWoW64\thenameofyourdll.dll"
And also enabling IIS to run 32 bit apps