I'm responsible for maintaining legacy VB6 code, and have encountered an annoying problem with regard to the locking of a project's COM DLL. (We'll call it MyProject and MyProject.dll)
When I load MyProject into the VB6 IDE, I am able to compile the resulting binary-compatible DLL MyProject.dll. I can then run my (Classic ASP) web application that hooks into the DLL (or anything else for that matter).
So, when I try to recompile the COM DLL, I get a 'permission denied' error. I then find myself having to carry out the following steps in order for the DLL to be unlocked:
Check I have no dependant projects open in other VB6 IDEs
Recycle IIS
Check the file isn't read only (sometimes it will be if I have checked it in to source control)
Close the project and reopen it.
Often it is the last step that fixes the issue, and allows me to recompile, which means that the VB6 IDE is actually locking the DLL of the loaded project!
My colleague explained to me that it was to do with the way a VB6 project works with binary compatibility upon the DLL, but was unable to suggest a resolution.
My searches elsewhere have yielded very little in the way of answers. Search queries that are related to this tend to return a lot of unrelated answers (maybe I'm asking the wrong thing of search engines).
The closest thing I could find on Stackoverflow was this question from a couple of years ago, but it doesn't really fit the bill.
Does anyone have any other suggestions that might ameliorate this?
Keep a copy of MyProject.dll named MyProject.cmp and point binary compatible setting to your .cmp file. This way you won't need reopening project file (step 4).
During check-in you can mark keep checked-out to skip step 3 too.
Related
I've searched far an wide for this specific problem, but I only find separate solutions for each problem individually. I basically want to know what the name of the environment variable should be. My assumption is that the name of the variable should be the name of the component and that it should be User variable and not System variable, for example:
name -> "mydll.dll"
path -> "c:\myCustomPath\mydll.dll"
The reason why I want to do this is because of two reasons. First, I often run my custom made tools either directly from the source code in a VM (which is sort of a pain), or I compile it and run it in W10. However, I just cannot do that with more complex apps that have dependencies because then I would have to register tons of DLLs onto the system root, and I know that I would lose track of it easily. The second reason is because I read this reply the guy says it's not recommended to use the system root for private libraries and he also suggests using an environment variable which sounded like a good solution to my problem.
The reason why I have not tested this myself through trial and error is because I'm afraid of leaving my only computer unusable if I put something wrong in the variable. Also all the libraries and exe files that I'm using are written and compiled in VB6, so I have no easy way around it since I already tried merging the multiple projects into one on a rather small project. I ended up rewriting almost the whole thing because VB6 doesn't like public types enums, etc in private Object Classes.
Finally, I am not sure if my question should be here since it doesn't involve programming, but I just felt it would be better understood here.
If I understand your question correctly, you are asking where you can place COM DLLs so that you can register them on your computer.
The answer is - fundamentally - that it does not matter where they are located because registration has a "global" effect. (Simplifying a little).
Now of course there are standards or conventions for where system-wide registered DLLs should go - e.g., Windows\SysWOW64 folder. But the point is that if you register the wrong thing, or leave out dependencies, or remove a registered DLL without unregistering it - etc. etc. - you will cause problems.
I am not aware of any environment variable that has anything to do with this basic function of COM DLLs. (I may be ignorant of something).
If you are actually using an application manifest (as maybe implied in the question) then you don't need to and should not register any DLL which is manifested.
I'm hoping I just missed something in the README somewhere, but...
I have a library of VB.net code that I'm trying to package into a PCL, ultimately for use under Xamarin. The code is relatively straightforward, there's a lot of File I/O using streams and some SQL client code, and a smaller amount of UI and control related code.
So I made a new PCL project, but I was confused what to select, so I chose Windows Store and .Net 4.5. I then Add...ed the source files from an existing project. Now I'm getting errors on the most basic things - ArrayList does not appear to exist in spite of importing System.Collections, and StackTrace doesn't exist in Diagnostics. Even simple things like StringFormat and SortedDictionary aren't there.
Did I skip a step somewhere? Perhaps I didn't download the right libs from MS? Or maybe I have to manually include a Reference to something? Any ideas?
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?
Ì have had this problem in a number of projects and I have almost given up. I am sure there is a solution though. When I insert a Flash object in a VB.Net Windows Forms application, it works fine for a little while and then I see this error in the Design Screen. I am using Visual Studio 2010
Could not load file or assembly 'Interop.ShockwaveFlashObjects, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
I have read several descriptions of why this happens, and apparently it has something to do with strong naming (or lack thereof), but have not found a solution yet. I used Add Reference->COM->Shockwave Flash (C:\Windows\SysWOW64\Macromed\Flash\Flash32_11_2_202_235.ocx) If I ignore the error it appears to work fine, but I don't want my users to have a problem.
I know I can use a browser control and play the Flash in that, but for reasons I won't get into, I have to use a Flash control. Any ideas would help.
Okay. I can't promise this to work for you, but it worked for me.
First, you have to locate a file on your computer titled AxImp.exe. You have to run it from the command prompt. This file is located (for me at least) here:
C:\Program Files\Microsoft SDKs\Windows\v7.0\Bin\x64
Once you do find and run it, you have to point it to the correct Flash.ocx file you're using, like so:
AxImp.exe <path>\Flash.ocx
Once you've done that you should end up with 2 DLL files in the same directory as the .ocx file. One called AxShockwaveFlashObjects.dll and another called ShockwaveFlashObjects.dll.
You don't care about ShockwaveFlashObjects.dll, just AxShockwaveFlashObjects.dll.
Grab that file and the Flash*.ocx file and paste them into the project directory.
Then include them into your references. This should open up two new references, AxShockwaveObjects and ShockwaveObjects.
Make sure you're Using both of them.
After this, you have to register the Flash*.ocx using RegSvr32 from your command prompt (make sure to run CMD in admin mode). That is done like so:
C:\RegSvr32 <path>\Flash.ocx
This worked for me. I was having the exact same problem (which is what led me here). It could be a half backed hack workaround but for now, that's how it worked for me.
Let me know if it works for you or not.
Hope it goes well for you.
I know this is an old post but I had this issue yesterday and the solution, at least in my case, was very simple. All I had to do was to change the Platform and Platform Target to x86 (Build tab of project property).
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