I am a .NET Developer. I have a good understanding of how references work in .NET i.e. if you want to use AssemblyA.ClassA.MethodA in AssemblyB.classB.MethodB then you add a reference in Assembly A to Assembly B.
I am looking at a VB6 app and I get an error when I open it i.e. Errors during load. Refer to frmMain.log. I open frmMain.log and it says: "2142: Class MSComDlg.CommonDialog of control CommonDialog1 was not a loaded control class.". I have used WinMerge to compare the source code in the faulty project to a previous version of the project (which does not have the problem). The only difference is that the faulty project contains the following line in the client.vdp file:
Reference=*\G{08DBEFD7-6A19-4DCE-A533-5BDBB93683C8}#1.2#0#..\..\..\..\..\Windows\SysWOW64\Comdlg32.oca#Microsoft Common Dialog Control 6.0 (SP3)
Removing this line seems to resolve the problem. Why does this resolve the problem?
I have used Winmerge to compare yesterdays revision of the project (which does not have the problem) to todays revision of the project (which does have the problem). The only difference is the reference in the original post in the VBP file.
I would assume that someone installed the development version of this control on a different machine and then set a reference to it. When you try to open the project on your machine the reference fails. Or the control was uninstalled. It seems that the project was not using the reference and that it can be safely removed as it will still compile without the reference.
However, I have seen vb6 actually remove non-licensed controls from the form in question in this situation. So it may be that you can now compile because the form is missing a component that was there previously. Have you checked that frmMain has not changed, both the .frm and .frx files?
Related
I have a project with a custom control overriding a default control from the system.windows.forms namespace. This works fine, but I discovered I needed to modify a DLL this project depends on with some code that needs to know about the existence of this custom class; this code uses the class name of the control to do various things.
As the project depends on the DLL, and circular dependencies are not-a-good-idea, I moved the custom class to a third DLL which is a new project by cut-and-paste, and set the project and library to depend on this new lib, and set this new library to be built first, before the two other projects, and added an assembly reference.
So far so good; I can now import this new namespace and use it in my code. But, now the existing uses of the custom control are broken in any 'designer' based code, as they still point to the default namespace. I've tried adding a reference under Project Properties > Imported namespaces, yet this is insufficient: the code likely needs to contain the explicit line imports <myNamespace>. And while this is no-problem for regular files, when you have a designer file it's important to not manually modify it.
What's the easiest proper way of informing visual studio that any custom control named say X should now be accessed as myNamespace.X?
The procedure as done in the question is correct, with one caveat: Check the .NET version, and if different set the target version to the lowest common denominator. If you use a newer Visual Studio than the original that was used to make the solution, it's likely there's a newer .NET out as well. By default, the latest .NET will be used for new projects. Visual studio will also happily attempt to build the projects with disparate .NET versions, and complain that it can't find references, then surreptitiously hide the version mismatch as a "Warning", even though linking assemblies with different targets is by default impossible.
The designer will then happily accept the custom class even if it's defined in another project.
I've got a program with three projects. One of them called businessCode, is a Application type Class Library, and the other two businessAuto and businessManual are windows forms.
I should be able to call businessCode from both the other projects. I've added my dll to both the Auto and Manual bins and added references. I've set my dependencies so both the windows for are dependent on the businessCode project. I've checked and made all my modules in businessCode to Public Module.
However, when I try to build my code, every reference to the dll businessCode comes back with "businessCode" is not declared. It may be inaccessible due to its protection level. Error occurs during the build.
Snip- it
'*****Will return error****
'businessCode' is not declared. It may be inaccessible due to its protection level.
businessCode.basMain.Main(true)
Why does the error have 'BussinessCode' and BussienssCode?
I would check to make sure that you are spelling the class names correctly.
I had to start over.
I made a new empty project and copied code. Once I copied everything over, I built the new businessCode. It built correctly then I added the Auto project. I had to manually copy my dll from the businessCode folder to the auto bin then I set added a reference to the dll in the Auto bin. Otherwise it would give me the same reference did not exist error. I did the same with manual.
I don't know why the same steps didn't work in my old solution but starting a new solution seems to of resolved my issues.
I just got a new PC (Win 7) with VS 2010 (same version as my old PC). I got a VB.NET solution from source control that contains two projects. One of the projects builds fine. The other project flags every non-MS Imports statement with:
Namespace or type specified in the Imports &1 doesn't contain any public members or cannot be found. Make sure the namespace or the type is defined and contains at least one public member. Make sure the imported element name doesn't use any aliases.
The ironic thing is that the working project within the same solution references all the same DLL's. I've removed and re-added the DLL's so I know they're there, and I can expand them in Object Browser, so I know they contain public methods.
I've ran out of ideas of things to try. Can someone throw me a bone, plz?
I had the same problem which I fixed by changing the Project Properties->Compile->Advanced Compile Options->Target Framework value from .Net Framework 4.0 Client Profile to .Net Framework 4.0
I had this happen. For me, the new DLL was targeting Dot Net 4.5, while the project which referenced it was only targeting 4.0. Switching the new dll to match fixed the issue.
I've had a similar issue as this before. In my case the problem was that the dll's were located on a network share drive (which in my system showed as q:) so when I referenced them the file path was q:\folder structure\file.dll. Upon switching machines, my system no longer referenced that share drive as q:\ but by another drive letter, causing my program to error out similarly.
In my case, I was able to correct this issue and prevent it from happening again by changing the way I referenced the dll from the drive letter it was assigned by my local system to the network path (\SERVER NAME\Drive Letter\file path\file.dll).
I was experiencing the same issue. The DLL I was referencing was built in framework 3.5. The project I was referencing the DLL was being built in 2.0. I switched the referring project to 3.5 and it built perfectly.
I had this problem with projects which were referencing the same version of the framework. I solved it with the following steps.
Remove reference to DLL
Clean and ReBuild DLL
Clean and ReBuild Project
ReAdd Reference.
This happened to me in a Visual Studio 2019 VB project with System.Data.SqlClient . Since the Import of System.Data.SqlClient was failing, all of my Sql classes used in declarations on the page -- SqlConnection, SqlCommand, SqlDataReader -- were undefined.
To fix it, I just had to use a full reference to System.Data.SqlClient.SqlConnection when declaring my very first variable for one of those classes on the page:
Using conn As System.Data.SqlClient.SqlConnection = New SqlConnection(GetConnectionString())
By changing just that first declaration on the page, it fixed the compilation error on the Imports line and all subsequent declarations on the page. (Even stranger, after building the project once like that, I was able to revert the declaration back to just referencing SqlConnection, and the Import worked and the page is compiling fine. So it may have been a temporary issue unrelated to my temporary fix)
I had already fixed this problem once I got to the point of googling this, and all I had to do was delete and re-add the reference in the solution explorer
I have a visual studio solution written using VB.net.
The solution contains 4 projects.
A GUI
A Service
A Settings library
A WiX Setup project
Here's how it used to work.
Last week, I had no shared settings library, and all was fine. But, because both the GUI and the Service contained an identical class named ConfigXML.vb (for serializing and deserializing settings), which I was regularly making changes to and copying and pasting between projects, I decided to extract the class into a library project of it's own (3 above).
This week, nothing works!
I added project references to 1. and 2. and things do work the same as they ever did. When I "start debugging" I can see and use the GUI as normal.
However, the problem I have is that when I create and install a new Setup of the solution, both the GUI and the Service fail to start.
I presume that the problem is the settings library is no longer where it was expected to be / hasn't been registered properly, needs to be placed in a directory by the Setup.msi or something similar.
This is my first time doing something like this, so I expect it's an obvious fix that I need.
I gather from the name of that class "...XML.vb" that there is an XML file that lives along side this class on disc. If there is such a file, then you need to add that file to the project and then right click on it go to "Properties" and set the "Copy to Output Directory" to "Copy if Newer"
I have been trying to load a OCX file into one of my VB6 projects for most of the day today. I've tried checking the COM registration in the registry the best that I know how, and have attempted several times using REGSVR32 on the file to no avail. All I keep getting from VB6 when I try to load the component (Under Project --> Components) is 'FilePath\FileName.ocx' could not be loaded. Has anyone else seen this before, and if so, any ideas how to fix it?
Just a couple of tips to help isolate the problem....
Look at the control with OleView
Examine the name: if it is one of the reserved words such as 'Menu', vb6 will fail to load it. (Although vb6 will happily let you create (and use) one with a bad name until it is saved and reloaded)
Examine the interface: does it describe the functionality? You may have a damaged or unlicensed ocx.
Attempt to load it with the ActiveX Control Test Container...
If you can, the problem is with VB6 and not the ocx.
This it may be a dependency issue -- some other component needed by the OCX is not present. Dependency Walker will find any static dependencies.
We fixed similar error recently. In our case the error was in the Visual Basic project (.vbp) file. Project file had been edited outside standardized build machine and contained references to OCX components - including workstation specific paths & versions of the components.
You can either edit the the project file in text editor or get a working version from version control.
Un-registering and registering again worked for me too.
Please note that you need to register this component using this syntax:
regsvr32 /i:design olch2x8.ocx
When you say you have used "REGSVR32 on the file to no avail" do you mean that you get a file name succeeded message, or an error message? If registering the file succeeds CMB is likely right about the ocx being unlicensed.
Licensing aside, there are a couple of other trip points with vb6. Especially if the OCX was developed in VB6.
If so, the 'officially' system registered version may conflict with the specific ocx you're using. In other words, both of them might have the same proper name (or classid) but the one you're attempting to use may not implement all the functionality described in the system registered one (i.e. you have a less evolved version). This arises when the author desires to maintain binary compatibility while enhancing the functionality of a control. As long as the public interfaces remain compatible, vb will not recalculate the classid.
You can fix this by forcibly unregistering the specific control (actually unregister all instances of the control). (regsvr32 /u control.ocx ) Then re-register the one you intend to use. Be certain that no running instance of VB6 exists when you do this or the results might not work. (Check your task list)
Hope that helps...
The control may be reliant on another DLL or OCX that may be missing or not registered and this could manifest itself as VB reporting that the control you're trying to use is missing. However, I'm not sure how you would identify the dependencies. As far as I know, dependency walker identifies static dependencies; I'm not sure if it can identify COM dependencies.
Un register the Ocx
re register the ocx
then loaded the project again in VB6, it worked for me.
Thanks everyone