I'm trying to move a classing ASP site to a 64-bit Windows 2008 server. The problem I have right now (there may be others if/when I get past this one) is that the site depends on an old VB6 DLL (32-bit), and I get the notorious "ActiveX component can't create object" error.
I tried taking IIS7 out of the equation by trying to get it to work with a simple VBS script file, and that's giving me the same thing.
The only dependency this DLL has is ADO 2.6, and from what I've read, this isn't supported and isn't needed for Windows 2008, as WDAC is included and has replaced MDAC.
I use the following to register my component:
C:\Windows\SysWOW64\regsvr32.exe "C:\MyVb6Com.dll"
I checked the registry, and everything appears correct there. My VBS file is also simple:
CreateObject("MyVb6Com.Session")
And it throws the error immediately:
ActiveX component can't create object: 'MyVb6Com.Session'
On the IIS end, I've already tried changing the application pool's settings to enable 32-bit applications, and that didn't help either (of course, if I can't get it to work w/ VBS file, this wouldn't make a difference either way).
Any help would be very much appreciated.
Make sure you use the 32-bit WScript to test your VB Script as well. Double-clicking it will use 64-bit - that will help go to diagnosing your issue.
In the app pool driving your IIS7 website, choose Advanced Settings and near the top, set Enable 32-Bit Applications to True.
IIS7 on a 64-bit machine will not use 32-bit DLLs unless this is set.
Related
I have migrated my website from Windows Server 32 bit to Windows Server 2008R2 64 bit. The website has a VB6 dll that is being used for all the funcitons.
I have registered the 32bit dll by placing it in SysWOW64 folder. Also, I am able to see the classed registerd using regedit.exe in SysWOW64 folder.
But, when I tried creating instance in VB "Server.CreateObject('myclass')", I am getting error
"Error:429 ActiveX Component Cant create object"
The same works in the existing 32bit server.
Am I missing anything here. Or should I use a different line on creating instance for the class I registerd. Please let me know.
finally did it.. needed to install vb 6 runtime, copy ishims.dll from Program files-> Internet Explorer to syswow 64 ( weird my dll had dependency on that) and lastbut not the least change Data Execution Prevention settings...
You need to run your website in 32 bit mode in IIS 7.5 manager.
I developed this software application with VB.net and Microsoft Access. The software works fine. publishing this applciation has been a huge problem for me. even though it seem to have published fine, it does not seem to recognise my access Database and props up error everytime and everywhere the database is called and used within the program. How can i overcome this problem please.
I just got back from somewhere, anyways... I actually had problems with Microsoft.Jet.OLEDB.4.0 especially in a 64 bit machine. This is because Microsoft.Jet.OLEDB.4.0 is designed as a 32 bit component. If you compile your solution as AnyCpu, it shouldn't work since an x64 process cannot load x86 component. So you have 2 options.
1) Change the compiling to 32 bit mode.
2) Use Microsoft.ACE.OLEDB.12.0 provider instead of Microsoft.Jet.OLEDB.4.0. This uses .accdb instead of .mdb. This is more future proof since the last time I heard, 2003 office won't be supported anymore :)
I'm having some compatibility issues with a legacy VB5 program I inherited.
Specifically, the DBCombo control.
Where does this control come from? I think it might be from the Microsoft DAO Object Library but I want to make sure.
It is, well, was, an ActiveX control last seen in VB6. The DLL that supported it was named "DBList32.ocx". If you have a really old machine on which it was installed then you could copy that file from the c:\windows\system32 directory and register it with regsvr32.exe.
I can still add it to the VS2008 .NET toolbox by right-clicking it and selecting Choose Items, COM tab and ticking "Microsoft DBCombo Control" (got VB6 installed on the machine). Didn't actually try to use it, odds are low after the Windows 7 SP1 update for ADO that broke backwards compatibility.
My company has a VB6 application using Crystal Reports 7 which a client has asked to be installed on Windows 7 32 bit. It is currently installed on Windows XP 32bit SP2 machines at the client. Connection to the DB is done via ODBC to SQL Server 2000 instance on another server.
On Windows 7, the installation works fine, however when you try to open the application, the error is given.
I have looked at the following:
Registering all the dll's and ocx files using regsvr32. Some will not register as they either are registered already or the following message is given "Make sure that "[name].dll" is valid DLL or OCX file and then try again." I read this forum thread regarding this: http://social.msdn.microsoft.com/forums/en-US/vblanguage/thread/0653f685-4526-45d9-89f3-8c479a6b4c62
Monitored the opening of the application using a ProcessMonitor application to try and spot if there is a missing dll or ocx file - this does not seem to be the case.
Reviewed the application according to this list and nothing seems to be against these guidelines
I've noticed two items in the knowledge base that relate to this
http://support.microsoft.com/kb/281848 - the comdlg32.ocx bundled with the application is version 6.0.81.69 and the one in the system32 folder on the dev machine (WinXP 32 bit) is 6.1.97.82. However if this was the issue then surely it would not work currently?
http://support.microsoft.com/kb/184898 - I'm not sure how to confirm that this is the issue
Finally, due to complexities, I am not allowed to make code changes to this application. Even if I was, I'm not a VB6 programmer, just the guy who got the terribly support project! If code changes are required, then I'll have to investigate using WinXP mode.
Update: I get the same error in XP Mode. That's a Win XP with SP3 VM. This runs on a Win XP SP2 VM, is there potentially something in SP3 that would have caused this to occur? Or is it just a fact of it being XP Mode?
I got the same error but I solved by using regsvr32.exe in C:\Windows\SysWOW64.
Because we use x64 system. So if your machine is also x64, the ocx/dll must registered also with regsvr32 x64 version
The file msrdo20.dll is missing from the installation.
According to the Support Statement for Visual Basic 6.0 on Windows Vista, Windows Server 2008 and Windows 7 this file should be distributed with the application.
I'm not sure why it isn't, but my solution is to place the file somewhere on the machine, and register it using regsvr32 in the command line, eg:
regsvr32 c:\windows\system32\msrdo20.dll
In an ideal world you would package this up with the redistributable.
This download fixed my VB6 EXE and Access 2016 (using ACEDAO.DLL) run-time error 429. Took me 2 long days to get it resolved because there are so many causes of 429.
http://www.microsoft.com/en-ca/download/details.aspx?id=13255
QUOTE from link:
"This download will install a set of components that can be used to facilitate transfer of data between 2010 Microsoft Office System files and non-Microsoft Office applications"
You say it works once you install the VB6 IDE so the problem is likely to be that the components you are trying to use depend on the VB6 runtime being installed.
The VB6 runtime isn't installed on Windows by default.
Installing the IDE is one way to get the runtime. For non-developer machines, a "redistributable" installer package from Microsoft should be used instead.
Here is one VB6 runtime installer from Microsoft. I'm not sure if it will be the right version for your components:
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=7b9ba261-7a9c-43e7-9117-f673077ffb3c
i get a HRESULT 0x80131047 exception in Microsoft Visual Basic 2008 express when debug my application. this happens whenever i click "start debugging" and it doesn't matter what application i load. this is a brand new vista x64 bit machine with a fresh install of VB2008 express.
This MSDN forum post says that you need to take "special" characters such as slashes, commas, or apostrophes out of your assembly name to avoid that error.
If that doesn't fix it, another suggestion there is to uncheck "Enable the Visual Studio Hosting Process" in the Debug tab.
It may not necessarily be special character as in my case...
This was a hard issue to troubleshoot as there may be many variables leading non-functioning assemblies.
So I was working on an Outlook Add-In 2010 targeting the 32-bit version of Office. Everything was working fine until one day out of the blues, the add-in wouldn't load anymore and I was presented with error "HRESULT: 0x80131047". After searching almost half-a-day I found a nice article:
http://blogs.msdn.com/b/astebner/archive/2007/05/06/2457576.aspx
I tried adding the assembly to the global cache but was unable to. Luckily, I had an almost identical project which ran just fine and I had already done comparison checks but all references and settings were the same, but on this pass I found something different ... as it turned out the platform target CPU was set to 64-bit so I changed it to "Any" and voila'! - problem fixed!
I was then able to run the project in Debug mode, Outlook launched and loaded with Add-in without a hitch.