I have my contextmenu shell extension dll. I have used Heat.exe to create component for my dll and in install it works completely fine.
But I am not able to register my dll using wix installer.
I have tried various options and nothing is working.
If I try to do manual registration using regasm.exe /codebase Myfile.dll it works.
Regasm /regfile ( and therefore heat or InstallShield ) has a known behavior of not writing out user registration data. In this situations you need to install your software on a VM and use a tool to capture the registry before and after running regasm. Then perform a difference report to see what was changed. Take that and author it into your WXS.
Finally reset the VM and run your new install and verify that it worked.
Related
I'm looking to create a Windows Installer package that will run an exe that runs another Windows Installer.
I'm putting a package together that has to install three files, an EXE, a CONFIG and an empty TXT. In addition, we also need to run the Access Database Engine 2007 as part of this process. However, when setting custom actions to just run it (with the flag /quiet) it fails because it's attempting to run an MSI inside of an MSI.
Is there any way I could somehow have it launch right after/right before or something? I've looked into WIX but honestly I'm clueless on how it would solve the problem.
Thanks.
You should look at the WiX Burn functionality and prerequisites. Some examples are:
WiX - Install Prerequisites and 3rd party applications
http://www.c-sharpcorner.com/UploadFile/cb88b2/installing-prerequisites-using-wix-bootstrapper-project-and/
You could probably just run the setup from the Burn bootstrapper - it will do its own detection if it's already installed.
I created an install shield project for an Excel add-in.
I selected .dll file and the .tlb file to be moved to the GAC (in destination folder) and program files folder
Those files are present in the program files folder
But when I go to Excel, click on tools-> reference, they are not appearing in that list!
I had to manually browse to the location of that .tlb file and select it
What change should i make so that it automatically comes in the references list
This article gives you description of two methods to do the registration with Installshield: Installshield Register.Net DLLs.
I definitely recommend Approach 2 - Run a .bat file to register the files. This approach runs the RegAsm for the install and uninstall processes using a batch file. This will give you control over the registration process, where you know exactly what is done, and you can handle all bitness scenarios 32/64/Wow64. In Approach 1 you don't, as stated in the article:
For some reason, perhaps that I am installing a 32bit component on a 64bit machine, this didn’t work as expected. [...] some DLL’s perform post registration actions the run when you run RegAsm.exe VirtualCam.dll /nologo /codebase but don’t get captured when you run RegAsm.exe VirtualCam.dll /nologo /codebase /regfile
If possible I would recommend switching to a different installation package creator, that supports run operations and gives better control over the process than using a batch.
*As it's not a native COM dll but a dotNet dll exposed to COM, there's no need for regsvr32 registration.
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'd like to create an installer package to install registration-free COM components (with manifest files included). This would be more or less a self-extracting archive to place some files in a target directory given as commandline argument, but it would also need to check or install some other redistributables like VC++ or DirectX.
The package is supposed to be used in another applications's installer as some kind of redistributable package itself. It should not be registered in the "Program and Features" dialog of Windows but has to be removed with the application. Ideally there should be no changes to the Windows registry.
So far I haven't been very successful. Can anyone please provide me with some hints regarding this use case?
You've got about a dozen different questions in that one question. Start with just creating a simple MSI that successfully installs your files and your manifest. Create a COM client to test it. You can also put AppSearch and LaunchConditions in your MSI to detect your dependencies and not allow installation if they are missing.
That's about all you should have to do for this simple question. As for the other questions.... if you are a redistributable and someone else is silently installing you then it's their job to handle the installation of the other redistributables. Also if they don't want you listed in Programs and Features they can pass the ARPSYSTEMCOMPONENT=1 to your installer and you won't be listed. If they want to uninstall you when they uninstall themselves, that's their problem not yours.
If you are really creating a redistributable to be used by other products, sometimes a merge module is the appropriate solution. They build their MSI files and include your merge module.
Otherwise, reg-free COM is in theory an easy install because you're just installing manifest files and Dlls etc. However I don't understand how that could be used by other apps because (IIRC) a client app exe needs your manifest and Dll in their install folder, so how can they do that when they are not installed yet? Or even if they are installed how can you find them? So that goes back to the merge module idea so they include your merge module and install an exe, your manifest and your Dll in the same location. When they uninstall so do your files.
my application requires the microsoft visual c++ redisributable package (vcredist_x86.exe).
i have a custom action to run the vcredist_x86.exe
i want it to run only if it's not already installed. i created a registry search to check it.
the question: how do i run this action with the check? when using the InstallExecuteSequence element, as shown below, the vcredist_x86.exe crashes because you cannot run an msi while running a different msi
thanks,
Uzi
what you need is a bootstrapper that would install the VC++ redistributable before your MSI starts.
i'm using open source dotNetInstaller and it works pretty well.
Don't use the exe at all. To distribute the VC++ runtime in an msi-based install, use a merge module. No custom actions, no conditions to add, it just works.
Aaron Stebner's blog specifically talks about doing this with WiX.
http://blogs.msdn.com/astebner/archive/2007/02/13/building-an-msi-using-wix-v3-0-that-includes-the-vc-8-0-runtime-merge-modules.aspx