I am working for a company that registers a lot of COM DLLs in the System32 folder/SYSWOW64 folder. I recall a question some time ago where Hans Passent said that this is wrong as the folders specified are for Windows DLLs. I cannot find the post so I want to check that this is correct?
Also if I want to register a COM DLL or a TypeLibrary in a foreign folder then can I just use the following command (for COM):
regsvr32 app.dll
Finally I was reading about the CODEBASE flag of Regasm: http://www.vbforums.com/showthread.php?597928-RESOLVED-How-to-delete-a-VB6-Reference. Do you have to use this flag if you want to register a TypeLibrary (.TLB)? What happens if you .NET assembly uses a third party library that is not signed?
If you are talking about installing COM DLLs in the System folder, then you are correct. All applications, and their support libraries, should be installed under the Program Files folders, or the Common Program Files folders.
You are also correct that REGSVR32.EXE can be used to manually register DLLs and OCX. "Foreign folder" is not a Windows concept - you can register a component anywhere in the file system, including the Windows and Windows System folders. By the way, if you use an installer, then you shouldn't have to use REGSVR32.EXE.
However, TLB files cannot be registered with REGSVR32.EXE, because that application basically loads the DLL/OCX, and calls an exported function on the library, so effectively the library registers itself. Instead, you need another tool, e.g. REGTLIB.
You don't use /CODEBASE to register a raw type library, because REGASM is used for registering .NET DLLs as COM components, not TLB files.
Related
I have a general question. If I need to deploy an assembly as part of my product, which needs to be registered on a client machine and the tlb file created, people suggest to use WiX toolset's heat harvesting tool.
However, do I need to register (regasm) that assembly initially on my PC in order first to run the heat tool on that file and get all necessary data (registries) related to it and then when the final msi package will be ready including that data for the file when installing it will put all that back on client's machine? Or perhaps I don't need to register that assembly on my developer's machine, and I just run heat on the regular assembly file, but heat knows auto-magically and generates the necessary registry data for the file later to be installed on client's machine and be registered as regasm?
Can you confirm that the same idea and technique applies on when registering COM component using the regsvr32.exe? Again do I need to register the COM component on my developers machine first before including the heat's generated data related to that component into my installation package, or there is no need to register the component on my PC prior to run the heat on it?
do I need to register (regasm) that assembly initially on my PC
NO. I tested this. You don't need to run regasm if you checked "Register for COM Interop" setting in your .NET build settings, which will create TLB for you.
Otherwise, you could run REGASM /TLB to create the TLB.
but heat knows auto-magically
YES. You must run HEAT on the TLB and DLL.
Can you confirm that the same idea and technique applies on when registering COM component using the regsvr32.exe?
YES
Again do I need to register the COM component on my developers machine first
No. I didn't test this.
I am trying to make a program that works on every operating system by forcing it to load and use the DLL's in the current directory, not the windows directory, but it don't works. I tried to enable "copy local" and change the refference path, but without any success, the program tries to load the DLL's from the windows directory.
My question is: how can I fix this?
The Search Order for DLL's is documented here on MSDN. It also includes instructions on how you can modify the search order so that the local bin directory is searched first, instead of the GAC.
The directory %windir%\assembly is called the GAC. Assemblies are not copied there, but installed typically using gacutil /i or by installation packages.
GAC is a suitable folder for libraries referenced by lots of other libraries and applications in build versions that are not centrally coordinated. Using GAC allows you to have multiple versions of the same library, all of which might be indirectly required even by a single application, installed side by side on the system. Case in point is the .NET framework itself.
The assemblies that you build are probably not that kind. Application assemblies and libraries that are basically part of a single application should never make it to the GAC or you can get into trouble. There is a variety of possible trouble:
one accidentally or intentionally creates different (incompatible) builds of the same library with the same version number.
assembly in GAC references an assembly not in GAC
one app installs the same assembly into GAC, but another app wants to load it from its local folder (where application binaries reside).
Code in the GAC gets a preference when assemblies are loaded. To remove an assembly from the GAC, use gacutil /u.
I'm constructing new classes in Visual Studio. These ultimately produce DLL files which are automatically registered via the VS IDE.
These same DLLs (and only the DLLs no TLBs) are shipped to the client where they are registered via the REGASM tool.
How can I identify which DLLs the client has registered, what versions these DLLs are and where these DLLs reside on a client machine?
I presume all of this is held within the registry, I just don't know where.
Thanks,
Keith
I think that the following page might give you a hint: http://msdn.microsoft.com/en-us/library/tzat5yw6(v=vs.100).aspx
All registered COM class
objects are listed under HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID. If you register your COM+ in Component Services through an MSI, then search under Program Files\ComPlus Applications and you will find your dlls there.
Regarding the file properties please refer to Read/Write 'Extended' file properties (C#)
I have one problem in vb6. I created a .tlb file in VB.net 2005 by adding Com class to project. I built the project, I got .tlb file and .dll files while building project, i selected "Register for Com interop" from project properties and built. It registered autometically and I can use created .tlb file in that PC in Vb6 working fine. if I deploy application to another PC and run I am getting "Error 429 ActiveX Component Can't create object" run time error. What I need to do? Please help me as soon as possible. I can't deploy the application to client due to above error.
one possible solution is to install .net frame work on client pc i never want to install .net framework any other solution will be most appreciatable.
If you've created a DLL in a .NET language (such as VB.NET), the target computer must have the .NET Framework installed in order to use the DLL.
This a hard and fast requirement, irrelevant of how you're utilizing the DLL, whether from a VB 6 application through COM interop or otherwise. It is also a hurdle you'll have to jump over first, before you worry about things like registering COM components, as Uday's answer suggests.
If you don't want a dependency on .NET, you need to use another environment to create the ActiveX DLL; either C++ or VB 6 are possible choices.
One option may be that, while deployment, you need to register that .tlb file in System Registry using regsvr32 command in command-prompt. Generally static libraries does not work until they are registered with System Registry.
You might have seen many programs register components during installation like 'Registering Type Components' or 'Registering COM Components' (for those who do networking especially). Those components are nothing but native COM dlls and tlbs.
so when creating deployment project, add some scripting login to register thode dlls and tlb to System registry using:
regsvr32 <path to tlb/dll>
you have to recursivey call this command for every dll/tlb you want to register with system. For example, if you have 4 dlls and 2 tlbs then you have to call it 6 times providing the path of dll and tlb one at a time.
In an attempt to keep my build machine clean can .local files be used during the compile of an application or is there a better way to keep the bloat off the machine.
.local is used to force Windows to use the COM DLLs in the VB6 application directory in preference to the most recent version stored in the registry. It doesn't replace the necessity of registering the DLL as Windows need to look in the registry for the CLSIDs of the older version.
Registry free COM DLLs is explained here and involves the creation of a manifest file. Similar in principle to what .NET goes through with it's assemblies except .NET handles this issue automatically and with ActiveX DLL it is more of a manual process.