I'm having troubles registering windows script file. When I'm trying to do so it says "Cannot find the type library for this reference Some.Reference"
Basically, behaviour is very similar to one described in this question Windows Scripting can't find reference but I can't figure out what to use instead of c:\path\to\control.dll.
In my case Some.Reference is Msxml2.FreeThreadedDOMDocument.4.0. so what should I actually do? I tried to use different kinds of msxml.dll, but it didn't seem to help.
Or maybe there are other ways to solve this issue?
One more detail: I managed to register this script on Windows7 but I get described error in Windows Server 2008 sp 2
Hans, thanks for your comment, because what I did is I used this tool
http://www.nirsoft.net/utils/registered_dll_view.html to view registered dlls and I found that the only abailable object I had is Msxml2.FreeThreadedDOMDocument.6.0 so I just changed my script to use this version, and as I can see from your comment it was not the worst decision
Related
I'm trying to recreate a program that uses javascript to open a connection to a PLC and then display all sorts of information on a web page. I'd rather have it in a form in MS Access for various reasons, and have spent forever trying to find the right dll to use (Jet32X.dll, if anyone is curious). I finally tracked the CLSID called out in the javascript back to a registered class for the PLC, and I'm trying to create that object in VB code. It won't get any further than the Dim As New line, however, throwing runtime error 429: "Active X Component Cannot Create Object." Really wish I had some more information about why.
I know the class is registered, since that's how I found it in the first place. I know the DLL file isn't corrupted, since the program runs fine from the JS version. I have a sneaky suspicion that there's some sort of incompatibility going on here, since the PLC and supporting software is pretty old, and I'm working in Microsoft Access 2013 (and its associated VBA). I can't really think of a good way to verify this, however. Does anyone have any other ideas? Could anything else be causing this problem?
Figured it out; in case anyone else runs into this sort of issue:
32bit COM dlls will not run in 64bit applications. If you don't want to go back and reinstall 32bit versions of whichever application you're using, one of the easiest workarounds is using dllhost.exe as a surrogate.
You can read a little about it here, but I found this tutorial easier to follow.
I send a new reply just to recap the information and avoid anyone that stumbles in the same problem again after me wasting precious time. All the steps involved assume that you already correctly registered the dll you are trying to use.
How to make a 32bit COM Dll work in a 64bit application
The "easy" solutions involve using the Dll Surrogate method, which runs dllhost.exe and as an intermediary process in 64bit to expose the underlying 32bit dll. When done correctly this works seamlessly without any special measure needing to be taken in neither in the 32bit dll nor in the 64bit application.
There are two main approaches to this:
Using Oleview.exe (i.e. using a GUI)
Oleview can be obtained downloading the Window 10 SDK.
In order to use Oleview it you have to:
Download the Window 10 SDK at the following link:
https://developer.microsoft.com/en-us/windows/downloads/windows-sdk/
Go to C:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\x86 to find the 32bit version of oleview.exe
ONLY THE FIRST TIME: run it as administrator to avoid see the message related to the impossibility to load iviewer.dll
In the left pane, Object Classes -> All Objects and find your dll name.
WARNING: you may find many entries for your dll. In particular each class has got its own entry such as YourProjectName.YourClassName
In the right pane, go to Implementation -> Inproc Server, and tick Use Surrogate Process. Leave the Path to Custom Surrogate empty to use the system default surrogate, that is dllhost.exe.
You can check the procedure went correctly by returning to the Registry tab, always in the right pane of the Oleviewer and make sure that now under CLSID = {yourAppIdHere} [DllSurrogate] = is listed among the entries.
Edit manually the Windows Registry
The Oleview method is recommended, but the manual method may be ok if you need to do this only once. The tutorial that NickGlowsinDark mentions was moved to https://techtalk.gfi.com/32bit-object-64bit-environment/ .
In order to avoid problems in the future with the page going offline I copy and paste here the most important steps involved. All credit goes to Emmanuel Carabott that is the original author of the tutorial, I added the first two steps in order to facilitate you in the process.
Open the Registry Editor (Windows+R -> regedit), and follow the following steps:
You first need to find your dll GUIDs. You will probably have many GUIDs, one for each of the classes that your dll exports. I find it's easier to find the GUIDs if you go to HKEY_CLASSES_ROOT\YourProjectName.YouClassName. It is the (Default) String Value you find under the Clsid key.
I recommend you find all the GUIDs first and make a note of them in order to have an easier time with the steps after this one.
Then, as Emmanuel Carabott kindly explains in his article, you have to do the following for each of the GUIDs you found:
Locate your COM object GUID under the HKey_Classes_Root\Wow6432Node\CLSID\[GUID]
Once located add a new REG_SZ (string) Value. Name should be AppID and data should be the same COM object GUID you have just searched for.
Add a new key under HKey_Classes_Root\Wow6432Node\AppID\
The new key should be called the same as the com object GUID
Under the new key you just added, add a new REG_SZ (string) Value, and call it DllSurrogate. Leave the value empty.
Create a new Key under HKey_Local_Machine\Software\Classes\AppID\
Again the new key should be called the same as the COM object’s GUID. No values are necessary to be added under this key.
That’s it, your COM Object should now be accessible from a 64bit environment and can be used like a regular COM Object.
Could somebody please explain what cob32api does?
I have the task of migrating a batch cobol system from 32 bit Windows to 64 bit Linux. A large number of programs call 'cob32api' which belongs to Net Express. The Linux equivalent to Net Express is Server Express, but I'm not at all clear on what this particular call actually does. There don't appear to be any parameters required. Sadly, there are also no comments explaining what it's for.
Naturally I get an error when I try to build:
Load error : file 'cob32api'
error code: 173, pc=0, call=1, seg=0 173
Called program file not found in drive/directory
Can anybody help me out here?
Thanks in advance.
OK, I tracked down a colleague who has worked on this stuff and knew what it meant. The call to cob32api is required so that the cobol program in question, as well as any sub-modules, can call Windows APIs. This explains why the corresponding library (cob32api.dll) has no Linux equivalent.
The simple solution to my problem: Remove the call altogether.
I hope this helps anybody who runs into a similar problem.
Thanks for the comments.
Additional information:
The removal of the "cob32api" call had consequences for the sub-modules I mentioned. Ther were a number of calls of the form
CALL WINAPI "windows-function-name" ...
These resulted in later compile errors and therefore needed to be replaced.
When ever I start a blank WPF project in Visual Basic 2010 (SP1) I get the following error:
Type
'Microsoft.VisualBasic.CompilerServices.DesignerGenerated'
is not defined.
The error comes from the auto-generated code in MainWindow.g.i.vb - when I try to add a reference to Microsoft.VisualBasic, it says I can't because it will be added at runtime.
I search of the MSDN forums found nothing, a workaround on MS Connect was to install SP1 (which I have done).
Anyone else have this prob or know how to fix it?
I have got the same Problem and fix it with this:
(I have the German-Version of VS, so i do not know the correct description of the buttons.)
Advanced Compile->Change your framework and say OK. After this change is back. Then go to clean your project(find under build) and rebuild it new.
If VS when it breaks down later, you have the problem-again. The Downloads have only change my memory-space.
I had this problem and found it was due to adding a namespace of Microsoft.MapPoint (in fact any namespace starting "Microsoft" caused it). This was a class from a Microsoft article: http://msdn.microsoft.com/en-us/library/bb259689.aspx
Renaming the namespace to something without Microsoft in it fixed the problem.
Try to install the file from Microsoft
VBWP7SetupENU.msi
See the instructions and the required files in:
http://msdn.microsoft.com/en-us/library/ff402530(v=vs.92).aspx#BKMK_Installing
Good luck
I have a VB.Net solution that another developer created and I'm trying to compile it on our build machine (it compiles on their machine) but with one of the projects I get an error saying something along the lines of:
Imyinterface is ambiguous in the namespace anamespaceassembly.
I have tried with no success:
examined the references to see any obvious errors
removed and re-added the assembly in question
searched the system for the same dll
attempted to compile the original deve's src (.v the source control version)
examined the assembly with ildasm.exe
I usually code in C# and have not seen this error before (in this form at least), not that it is VB.Net specific but the UI for adding/viewing references is slightly different so I thought maybe VB.Net might do something different with references.
I also tried to compile on another machine, and it compiles ok. So I assume it is something with the build machine but I'm not sure what. Other conflicting assemblies somehow not referenced by the project, is that possible??
Any ideas?
Check your references if you have two versions of the same reference (eg. Microsoft.ReportViewer.Webforms version 10.0.0.0 and Microsoft.ReportViewer.Webforms 8.0.0.0) You will get this error. Delete the oldest and you should be good. I do this to myself all of the time.
There can be a few causes for this error. In VB, you should be aware that more names then you're used to from C# are available without class specification. Also, case does not matter in VB, which can further liken the chances on collisions.
Even in the event that you don't find the actual conflicting issue, you can resolve this in the same way you would in C#: rename it in the Imports statement:
Imports IM = yourAssembly.Imyinterface
Then change the code such that uses of Imyinterface are replace with IM.
NOTE: If the error does not point to a particular line, the conflict may be out of your hand. Normally, a full Clean Solution and Rebuild helps a lot, but occasionally a misbehaving file (i.e., another error) causes this error to popup first without clear source. Try to rollback recent changes to the place where it did work.
You also say it worked on another machine. Chances are that your machine is having a different version of MS Visual Studio or .NET. Check and compare the exact versions.
I was facing same issue. I upgraded my application from vb6 to vb.net and when i change the build configuration from DEBUG to RELEASE then i got AMBIGUOUS errors.
I found dulicate references folder in solution Explorer. I removed those duplicate referecnces and Build sucessfully. I Hope it may help others.
Thanks for the responses! I tried each but still was having issues.
One point of info I left out of the original question was that the VB.net projects are upgrades from VB6 projects. At the time I did not think that was relevant.
After investigating further the build machine was used to build the VB6 projects also. So I ran 'reg32 /u' on the vb6 dlls and that seemed to fix the VB.net issue.
Not exactly sure why this fixed it since I was not referencing the VB6 dlls, I'm guessing something to do with ambiguous entries in the registry confusing the vb.net project.
I've got a really strange error and any light that anyone can shed on this would be greatly appreciated.
I made some changes to some VB6 source which builds a COM object. The automated build which builds our app returned an error. No problem I thought--I'll just back out my changes. Well backing out my changes isn't making the problem go away.
Specifically when I attempt to build the app via a .vbg file, with a command line like path\to\vb6\vb6 ProjectFile.vbg /make
I get a message
"Compile Error in File '', Line : Object library
invalid or contains references to object definitions that could not be
found."
As I said, I reverted the source code so I'm really stumped as to why this error is still occurring. Any VB6 gurus around who might be able to point me at an answer?
I can post the exact code in question but the fact that it was building correctly, stopped building correctly and now refuses to build correctly makes me think this is not a problem with my code but rather some problem in the environment. Like something got put in the registry as a result of the previous build error.
Any tips, hints, or suggestions greatly welcome. I realize my question is a bit sketchy but I'm not even sure what's important to include and what isn't.
EDIT 1:
Thanks for the excellent suggestions guys. I think it is something to do with VB6 doing some sort of auto-registration.
Just to add a bit more detail: this problem does not occur when I build the referenced vbp file from the IDE. It only happens on the make on the .vbg which contains the vbp. Also the build tool in question automatically pulls latest source and the error happens on both my local box and the dedicated build box.
EDIT 2:
Hi again all,
The release engineering fellow figured out how to get this to build in his build environment so it's currently ok. Once we're past this crunch, I'll try to interrogate him about what he did and share the details with everyone.
Thanks again for all the great suggestions. This is what's so great about SO; that is, I asked about a 10-year-old technology and I got several great and on-point ideas.
Make sure that the VBG and all the VBP's got rolled back as well. That error is consistent with a project trying to reference a CLSID that is no longer valid for the dependency. Have you tried loading up the project group and building from the IDE, if that works and you save and check in all the changes to the group and project files, you might be fixed up.
I'm guessing the fact that you mention that it was a COM component might be the source of the problem. If any of the public method's or properties have changed then I seem to remember that VB6 will change the interface GUIDs and auto register the new ones.
My suggestion would be to check the registry to look for any mention of the component name, make a note of any associated CLSIDs, back up the registry, and then delete the references.
As cmsjr mentions it could also be a bad CLSID reference in your .vbp files.
The other option is that the failure has caused a problem with some .tlb (type library) or olb (object library) files.
The best thing to do is move all your compatibility DLL to a separate and combined directory. The reason for this is control over what VB6 is using to check for binary compatibility. In addition the Typelibs that are generated IMPORT the references. So if you using Binary DLL Ver 10 for compatibility however the import is pulling in Binary DLL Ver 9 you will have issues. By keeping all the libraries in a single folder and pointing your projects to the DLLs in that folder you ensure that the respective TypeLib Import the correct version.
Finally if you have multiple levels of DLL reference each other. You may run into mysterious error where the VB6 is unable to compile using binary compatibility. In such cases you need to compile the lowest DLL in the hierarchy (Utility DLL perhaps) copy it over into the compatibility folders. Work your way up the chain until everything compiles in one shot again.
This is because if have DLL A reference DLL B which Reference DLL C. VB6 will get sometimes get confused if you make a change to A and C. will compile fine but A will not until the compatibility libraries are updated.
Hunt down and delete any .obj and .exp files that may be lying around from the previous failed build.
You will have to open the project & re-type in the lines that you changed.
Save the project alongwith VBG and re-compile after that.
I think that will fix it.
EDIT: The idea is that the cls/bas file remember the class (CLSID) that you used. So, if you change the references but don't change the lines in the cls/bas - it is a mismatch of type (what was referenced vs what is typed in cls/bas file).