I have a COM dll I want to register while installing the application. I am using Install4j. Is there any way Install4j to register the COM component? It maybe possible to use a batch file that includes statement such as "RegSvr32 abc.dll". But It would be nice if install4j has built in support for registering COM components as most of the install makers support them.
As of install4j 5.1, there is no support for registering COM components. You would indeed have to put the regsvr32 invocation into a batch file and call it with a "Run executable or batch file" action.
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 have an InstallShield Basic MSI project which builds both 32-bit and 64-bit installers using Release Flags mechanism to build the different packages with the correct Template Summary, etc. One of my Components is an explorer.exe shell extension, so in order for this to work it needs to be registered in the 64-bit node in the registry when installed on windows 64-bit, NOT in the Wow6432Node. However, because this is a 32-bit Component to Windows Installer it will get registered as such and go down the Wow6432Node. I am told by InstallShield that this is native Windows Installer behavior and there is really no way around this other than Custom Actions (which I have already resorted to).
Do I have to resort to running regasm? This is what I currently do however I would rather not use Custom Actions for something like this. Also, it appears that other products have the same pattern: a 64-bit shell extension, however installed down program files (x86). I see TFS Power Tools and WinZip doing this for example. For these products, I do NOT see regasm.exe running so I assume they have some other mechanism for this.
Any ideas?
Did you try to set msidbComponentAttributesDisableRegistryReflection (Component table) attribute for that component?
I have a couple of COM components which i register during installation. These COM components are part of a Merge Module which I include in my WIX project. I used used the below code for registering
<InstallExecuteSequence>
<RegisterClassInfo/>
<RegisterProgIdInfo/>
<RegisterTypeLibraries/>
<WriteRegistryValues/>
</InstallExecuteSequence>
The components were registered successfully. However, during uninstallation, these COM components were not un-registered. How do I make sure that these components are un-registred when the SharedDLL Count is 1 before un-installation?
Ugh, I just went through a whole bunch of hoops in regards to COM.
Really, you shouldn't be registering COM components on the system anymore. It causes way more problems than it solves. When you register COM components, you register them globally, potentially hi-jacking the component registration for that COM library from other applications. Hopefully, that won't happen, but you can't know that for sure.
Since Windows XP onwards, there has been something called registry-free COM registration. In order for this to work, you need to provide manifest files for each of the COM libraries in use by your application. You will also need to provide a manifest file for your application that states the app's dependencies on those COM libraries.
The beauty of this, is that you can deploy the COM libraries in your application's installation folder and no system registration is needed.
The following URLs can help you create the manifest files you'll need:
Registration-Free Activation of COM Components: A Walkthrough
Simplify App Deployment with ClickOnce and Registration-Free COM
Manifest Files Reference
MSI Writing Guidelines
Let me know if you need any further information. I was able to successfully deploy my application with old VB6 COM components without registering them globally in the Windows registry and deploying the COM libraries in my application's installation folder (as opposed to %windir%\system32 or %windir%\SysWow64 (on 64-bit windows).
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