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.
Related
I have a few add-ins for Excel and Word 2007-2016. And I don't understand a few things. My project use some dlls, like Microsoft.Office.Tools.Common, Office.dll, some excel, word and common interop's. And these files can be found in a few places at the same time, different versions of them (like program files, windows/assembly, windows/Microsoft.Net/assembly). So I don't know which version to use. And also, if user has VSTO installed, I suppose he has these files. So why do I need to provide them? What do we install exactly when we install VSTO? Which part is for what and which installation place is from which component? I think I don't do it right, because I found out that Excel loads two different versions of the same file at the same time.
Those are a lot of questions, and many of them depend very much on exactly what you provide with your solution...
The case of the PIAs ("Office dlls") is relatively clear cut:
You do NOT need to (and should not) distribute the Office PIAs with a VSTO solution, with the possible exceptions of 2007 and 2010. In these versions, installing .NET support was optional and not default. That's why there are redistributables for these versions, and not for others. Your installer needs to check whether they're present (same as with the VSTO runtime and the version of the .NET Framework) and install only when necessary.
Office always installs the PIAs into the GAC and your solution will find them there. It makes no difference where you referenced them on your developer machine.
The PIAs in the GAC are only available via the COM tab in the Visual Studio dialog box for inserting references. Many .NET developers didn't find them there, so Microsoft delivers a (ONE) single set of PIAs with VSTO and copies them to a Visual Studio folder so that they'll show up in the .NET tab of the dialog box. The only problem with this is that you get only the set of PIAs for the version of Office that was "current" when that version of Visual Studio was released, meaning you may get the impression you can't develop against any other version because you don't find the PIAs in the .NET tab (but they will be in the COM tab).
Rule of thumb: Always, always develop your code using the earliest version of Office you plan to support. There are two reasons for this: 1) You can only use functionality that will be available to all versions of the Office application (Office is generally backwards compatible); 2) Office is designed to migrate references to older sets of PIAs to newer sets, but not the other way around.
There's a good article on deployment pinned at the top of the VSTO forum on MSDN that "sorts" a lot of requirements for various versions of VSTO and Office: https://social.msdn.microsoft.com/Forums/vstudio/en-US/1666d2b0-a4d0-41e8-ad86-5eab3542de1e/deploying-office-solutions-to-end-user-computers?forum=vsto for add-ins targeting 2007-2010. For later versions, see the MSDN documentation: https://msdn.microsoft.com/en-us/library/bb386179.aspx
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 experimenting with writing ActiveX controls and noticed that I can't seem to create an ActiveX control in Visual Basic (6.0) which features slightly more sophisticated controls. Simple controls like labels, buttons and check boxes seem to work fine, but as soon as I try to add e.g. a tree control to my form, the ActiveX control stays entirely blank as soon as I embed it into some host application on another computer. It works fine on my development box though.
While going through the Projects->Components (Ctrl+T) list, I found two libraries which apparently contain a tree control:
Microsoft Windows Common Controls 5.0 (SP2)
Microsoft Windows Common Controls 6.0 (SP6)
As soon as I add any of the controls from these libraries to my form, the form stays entirely gray when embedded on another computer. The other computer is a Windows XP system, so I hoped that missing redistributables wouldn't be an issue, given how old Visual Basic 6 is. To be sure, I installed the VB6 redistributables, but unfortunately that didn't make a difference.
Does anybody know why my ActiveX control would stay gray on other computers, but not on mine, as soon as I add any of the controls from the above libraries to me form? FWIW I just need a tree control so if there is some other, more appropriate, library available - that's fine with me.
UPDATE:
As it turned out, it helps to download MSCOMCTL.OCX into C:\WINDOWS\SYSTEM32 on the other computer and then registering it via regsvr32 C:\WINDOWS\SYSTEM32\MSCOMCTL.OCX. However, I didn't find an official source for this file, and running the COM registration by hand looks cumbersome to me. Is there really no redistributable I could use?
VB6 runtime is preinstalled on XP and above but the Common Controls component you are referencing is not.
Try installing Microsoft Visual Basic 6.0 Common Controls redistributable on the client machines or event better make a setup for your application.
Edit:
Opps, the link is for an update that does not install the OCXs if not already present. The only redistributable I find is a merge module for Windows Installer.
To solve this problem, I developed a .msi package. The source files (WiX) and stake posted here:
https://github.com/IT-Service/ITG.VB6CommonControlsRedist
My VB.NET application uses Microsoft Flex Grid Control 6.0. This is a legacy application which has been ported from VB6 with the Visual Studio conversion wizard. Although I can compile the assembly, I get a COMException because some class is not registered. I've found out that this class is the Microsoft Flex Grid Control 6.0.
Where can I find the control and how can I register it on machines so that the application will run?
Best Regards,
Oliver Hanappi
The "Microsoft FlexGrid Control" MSFlxGrd.ocx shipped with Visual Basic 6. It is an ActiveX control. The easiest way to get the control is to install Visual Basic 6. If you have an MSDN subscription, VB6 is available as a free download. But I am surprised you can compile your application if the control is not already installed on your development machine.
Once you have found the control, you need to register it on the machines where you need your program to run. The easiest way is just to create a deployment project. If you want to do it manually, use regsvr32 from the command line.