I have read a few solutions for this problem but none of them have worked for me. One of the main problems is that I am fairly sure I have a 32-bit dll that I am trying to use and I am trying to run it on a 64-bit server. Also I do not have the source code for the Interop dll. Most of the solutions I found involved making changes to the DLL and recompiling.
I have registered this dll using RegAsm.exe. The dll resides in the C:\Windows\SysWOW64 folder. It appeared to have registered fine, there were no errors.
I am trying to migrate a classic ASP web site from Windows Server 2003 (IIS 6) to Windows Server 2008 R2 (IIS 7.5).
One solution I found mentioned something about creating a VBS script and running that in the SysWOW64 folder. I'm not sure why running the script in the SysWOW64 folder was important but I did it anyway. I still cannot create the object.
I just copied and pasted code from my classic ASP page into the VBS script and added the Wscript.echo command.
Below is my VBS script.
Dim objCrypt, Key, UID, Pwd
Set objCrypt = CreateObject("MyEncryptionTool.Crypt")
Key = "1234" ' Encryption Key
UID = "äRŸê¬ÈH"
Pwd = "á#‰ë•ÆW¬"
Wscript.echo "UID: " & objCrypt.Decrypt(UID, Key) & vbCrLf & "Pwd: " & objCrypt.Decrypt(Pwd, Key)
The error message that CScript.exe produces is:
C:\Windows\SysWOW64\CryptTest.vbs(2, 1) Microsoft VBScript runtime error: ActiveX component can't create object: 'MyEncryptionTool.Crypt'
This is essentially the same error I am getting in my classic ASP page.
I am fairly sure it was compiled 32-bit and Windows Server 2008 is 64-bit and that may be the source of my problem right there.
Is it possible to use a 32-bit dll on Windows Server 2008 R2?
I should have posted the answer to this back in December 2014 when I figured it out. It was a stupid operator error. There are two dll files for the company's encryption tool. One has the prefix "interop." and the other doesn't.
I was using the one with the "interop." prefix because at the time that was the only dll I knew about. I found the version without the prefix and registered it with no problem and everything works. This came about when I finally found some documentation on the company's encryption tool and it never mentioned the dll with the prefix.
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 have a Visual Studio 2008 solution with two projects (a Word-Template project and a VB.Net console application for testing). Both projects reference a database project which opens a connection to an MS-Access 2007 database file and have references to System.Data.OleDb. In the database project I have a function which retrieves a data table as follows
private class AdminDatabase
' stores the connection string which is set in the New() method
dim strAdminConnection as string
public sub New()
...
adminName = dlgopen.FileName
conAdminDB = New OleDbConnection
conAdminDB.ConnectionString = "Data Source='" + adminName + "';" + _
"Provider=Microsoft.ACE.OLEDB.12.0"
' store the connection string in strAdminConnection
strAdminConnection = conAdminDB.ConnectionString.ToString()
My.Settings.SetUserOverride("AdminConnectionString", strAdminConnection)
...
End Sub
' retrieves data from the database
Public Function getDataTable(ByVal sqlStatement As String) As DataTable
Dim ds As New DataSet
Dim dt As New DataTable
Dim da As New OleDbDataAdapter
Dim localCon As New OleDbConnection
localCon.ConnectionString = strAdminConnection
Using localCon
Dim command As OleDbCommand = localCon.CreateCommand()
command.CommandText = sqlStatement
localCon.Open()
da.SelectCommand = command
da.Fill(dt)
getDataTable = dt
End Using
End Function
End Class
When I call this function from my Word 2007 Template project everything works fine; no errors. But when I run it from the console application it throws the following exception
ex = {"The 'Microsoft.ACE.OLEDB.12.0'
provider is not registered on the
local machine."}
Both projects have the same reference and the console application did work when I first wrote it (a while ago) but now it has stopped work. I must be missing something but I don't know what. Any ideas?
Basically, if you're on a 64-bit machine, IIS 7 is not (by default) serving 32-bit apps, which the database engine operates on. So here is exactly what you do:
1) ensure that the 2007 database engine is installed, this can be downloaded at:
http://www.microsoft.com/downloads/details.aspx?FamilyID=7554F536-8C28-4598-9B72-EF94E038C891&displaylang=en
2) open IIS7 manager, and open the Application Pools area. On the right sidebar, you will see an option that says "Set application pool defaults". Click it, and a window will pop up with the options.
3) the second field down, which says 'Enable 32-bit applications' is probably set to FALSE by default. Simply click where it says 'false' to change it to 'true'.
4) Restart your app pool (you can do this by hitting RECYCLE instead of STOP then START, which will also work).
5) done, and your error message will go away.
I have a visual Basic program with Visual Studio 2008 that uses an Access 2007 database and was receiving the same error. I found some threads that advised changing the advanced compile configuration to x86 found in the programs properties if you're running a 64 bit system. So far I haven't had any problems with my program since.
Are you running a 64 bit system with the database running 32 bit but the console running 64 bit? There are no MS Access drivers that run 64 bit and would report an error identical to the one your reported.
Solution:
That's it! Thanks Arjun Paudel for the link. Here's the solution as found on XNA Creator's Club Online. It's by Stephen Styrchak.
The following error suggests me to believe that you are compiling for 64bit:
The 'Microsoft .ACE.OELDB.12.0' provider is not registered on the local machine
I dont have express edition but are following steps valid in 2008 express?
http://forums.xna.com/forums/t/4377.aspx#22601
http://social.msdn.microsoft.com/Forums/en-US/vbgeneral/thread/ed374d4f-5677-41cb-bfe0-198e68810805/?prof=required
- Arjun Paudel
In VC# Express, this property is missing, but you can still create an x86 configuration if you know where to look.
It looks like a long list of steps, but once you know where these things are it's a lot easier. Anyone who only has VC# Express will probably find this useful. Once you know about Configuration Manager, it'll be much more intuitive the next time.
1.In VC# Express 2005, go to Tools -> Options.
2.In the bottom-left corner of the Options dialog, check the box that says, "Show all settings".
3.In the tree-view on the left hand side, select "Projects and Solutions".
4.In the options on the right, check the box that says, "Show advanced build configuraions."
5.Click OK.
6.Go to Build -> Configuration Manager...
7.In the Platform column next to your project, click the combobox and select "<New...>".
8.In the "New platform" setting, choose "x86".
9.Click OK.
10.Click Close.
There, now you have an x86 configuration! Easy as pie! :-)
I also recommend using Configuration Manager to delete the Any CPU platform. You really don't want that if you ever have depedencies on 32-bit native DLLs (even indirect dependencies).
Stephen Styrchak | XNA Game Studio Developer
http://forums.xna.com/forums/p/4377/22601.aspx#22601
I thought I'd chime in because I found this question when facing a slightly different context of the problem and thought it might help other tormented souls in the future:
I had an ASP.NET app hosted on IIS 7.0 running on Windows Server 2008 64-bit.
Since IIS is in control of the process bitness, the solution in my case was to set the Enable32bitAppOnWin64 setting to true:
http://blogs.msdn.com/vijaysk/archive/2009/03/06/iis-7-tip-2-you-can-now-run-32-bit-and-64-bit-applications-on-the-same-server.aspx
It works slightly differently in IIS 6.0 (You cannot set Enable32bitAppOnWin64 at application-pool level)
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/0aafb9a0-1b1c-4a39-ac9a-994adc902485.mspx?mfr=true
I'm having same problem. I try to install office 2010 64bit on windows 7 64 bit and then install 2007 Office System Driver : Data Connectivity Components.
after that, visual studio 2008 can opens a connection to an MS-Access 2007 database file.
See my post on a similar Stack Exchange thread https://stackoverflow.com/a/21455677/1368849
I had version 15, not 12 installed, which I found out by running this PowerShell code...
(New-Object system.data.oledb.oledbenumerator).GetElements() | select SOURCES_NAME, SOURCES_DESCRIPTION
...which gave me this result (I've removed other data sources for brevity)...
SOURCES_NAME SOURCES_DESCRIPTION
------------ -------------------
Microsoft.ACE.OLEDB.15.0 Microsoft Office 15.0 Access Database Engine OLE DB Provider
I've got the same error on a fully updated Windows Vista Family 64bit with a .NET application that I've compiled to 32 bit only - the program is installed in the programx86 folder on 64 bit machines. It fails with this error message even with 2007 access database provider installed, with/wiothout the SP2 of the same installed, IIS installed and app pool set for 32bit app support... yes I've tried every solution everywhere and still no success.
I switched my app to ACE OLE DB.12.0 because JET4.0 was failing on 64bit machines - and it's no better :-/ The most promising thread I've found was this:
http://ellisweb.net/2010/01/connecting-to-excel-and-access-files-using-net-on-a-64-bit-server/
but when you try to install the 64 bit "2010 Office System Driver Beta: Data Connectivity Components" it tells you that you can't install the 64 bit version without uninstalling all 32bit office applications... and installing the 32 bit version of 2010 Office System Driver Beta: Data Connectivity Components doesn't solve the initial problem, even with "Microsoft.ACE.OLEDB.12.0" as provider instead of "Microsoft.ACE.OLEDB.14.0" which that page (and others) recommend.
My next attempt will be to follow this post:
The issue is due to the wrong flavor of OLEDB32.DLL and OLEDB32r.DLL being registered on the server. If the 64 bit versions are registered, they need to be unregistered, and then the 32 bit versions registered instead. To fix this, unregister the versions located in %Program Files%/Common Files/System/OLE DB. Then register the versions at the same path but in the %Program Files (x86)% directory.
Has anyone else had so much trouble with both JET4.0 and OLEDB ACE providers on 64 bit machines? Has anyone found a solution if none of the others work?
I am assuming that if you are running a 64 bit system with a 32 bit database and trying to run a 64 bit console, the following packages need to be installed on the machine.
Install the Microsoft Access Database Engine 2010 x86
Redistributable, this installation is available at:
http://www.microsoft.com/download/en/details.aspx?id=13255 .
Data Connectivity Components of Office 2007, this installation is
available at:
http://www.microsoft.com/download/en/confirmation.aspx?id=23734 .
Microsoft Access Database Engine 2010 x64 Redistributable. You will
need to download the package locally and run it with a passive flag.
You can download the installation here:
http://www.microsoft.com/en-us/download/details.aspx?id=13255
Installing using the command prompt with the '/passive' flag. In the
command prompt run the following command:
'AccessDatabaseEngine_x64.exe /passive'
Note: The order seems to matter - so if you have anything installed already, uninstall and follow the steps above.
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.
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'm moving a Dll (built in c++) from windows 2000 server to a 2008 server but im have some trouble registering it. In 2000 all you normaly have to do is a "regsrv32 name.dll" but this will not work in 2008 because you get a pointer error, iv also tried to use "gacutil /i name.dll" because someone told me this might work, but it didnt. So, I'm kind of desperate, is there anyone that have some solution to how i can get this c++ dll to work in 2000 server so that i can access it from an old classic asp page.
EDIT:
This is the error when running regsrv:
"
The module "name.dll" was loaded but the entry-point DllRegisterServer was not found.
Make sure that "name.dll" is a valid DLL or OCX file and then try again.
"
Note that I cant edit the dll file in anyway.
If UAC is enabled, are you running an elevated command prompt when you call regsvr32? If not, you'll probably get an access denied error in the registration function (which could manifest itself in all sorts of bad ways for something that old).
You have to be logged in as an admin, then run Command Prompt with right-click, "Run as administrator".