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.
Related
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.
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#)
Background to Question
I am currently in the process of trying to put together a means of distributing a new project I am working on which requires that a COM exposed .NET DLL be registered on the user's system and as I am new to WiX and making the move to it for this I am trying to keep things as simple as possible.
The Problem
The big issue with my DLL registration is that regasm sets the default value of the InProcServer32 key to "mscoree.dll", but my DLL can only seem to be instantiated when the full path to it is used, e.g. "C:\Windows\SysWow64\mscoree.dll"
Currently I have a custom action in my setup project (which I want to abandon to use WiX) which will call the SearchPath API to find the full path to mscoree.dll and overwrite the default value with the full path, so that the DLL can be instantiated without any issues.
Proposed Solution / Question
As I am new to WiX I have had the idea of preparing a .reg file that will contain all the necessary information to go into the CLSID tree and then having WiX execute that some how.
My question is:
Are there any inherent flaws by registering a DLL this way?
As the main reason I am trying to find work arounds here is the mscoree.dll issue, is there any native means of doing this in WiX?
Take a look at the WiX program called "Heat". This can "harvest" your DLL including registry information related to the RegAsm / COMVisible parts. You can then snip this code and work it into your wxs file.
You can also use Regasm /regfile and then manually transform that information into RegistryValue elements.
With regard to your path problem, use the SystemFolder property.
[SystemFolder]mscoree.dll
If you mark your install as 32bit (x86) this will automatically resolve to the SysWow64 folder when run on a 64bit OS and the System32 folder when run on a 32bit OS.
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.
I'm trying to reference a COM dll in visual studio by using the Browse tab and selecting the DLL. I noticed that if the DLL is registered on the system with regsvr32 I can reference it, but if it's not registered I receive an error selecting the dll file "A reference to 'file.DLL' could not be added. Please make sure that the file is accessible, and that it is a valid assembly or COM component."
We would like to keep the DLL not registered, so that we have less configuration needed on other development machines and on the development environments.
Is it too much to ask?
Thanks!
you need to register dll. you can set registration in your setup project or create a batch file for all these type of processes.
Note: Don't forget to unregister dll on uninstallation.
You'll need to register the dll because otherwise it would not be able to find the type library.
Adding the dll afterwards as a reference to you project will create the interop.XXXXmethod.dll assembly.
You need to have the COM server registered, period. You could take some measures to automate the process though and to unregister the COM server when it is not needed.
The same applies to daily builds. If you build a COM server and a .NET based client during the build you have to register the server prior to building the client. And you better unregister it as soon as the client is built. Adding these steps to the build sequence is not a problem at all.
You might be able to use Registration Free Com