Thanks, Nilesh. Let me know if you have any questions or issues.
My only regret is that this guide was not available when i was making our WIX installer. I would have saved so much time! Great Guide!
Thank you, Deepak and Taus
Thank you, Artem
this would be awesome tool as I know many here have trouble to share addin
I don't think I will ever use anything other than Microsoft Installer Projects Extension since its free and simple to use, but there is one limitation that might be possible to overcome in one of the other options. Perhaps you have tackled this. It has not been a high enough priority for me but would be very useful.
As you know, the function in your COM visible class tagged with [ComRegisterFunction] will run with regasm.exe registers the DLL. However, the MSI does not run this function! Consequently, in the Installer Projects Extension it is necessary to still tediously fill out of the registry information need by SOLIDWORKS in the Installer Projects Extension registry tab.
The convenient solution would be to create a custom action that can locate the path to regasm.exe and run it on the installed DLL (e.g., the command below), but no luck. Nevertheless in my time studying custom actions it did not seem possible through Installer Projects Extension.
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\RegAsm.exe /codebase "%~dp0\MyAddin.dll"
Thank you for your comment. I assume Microsoft Installer Projects Extension is the same as Visual Studio Installer (VSI).
There are few things which I do not like about this type of the installer:
- There is no much control of what is actually happening when wizard is used so I cannot tweak anything if that doesn't suit me.
- It can only be compiled via Visual Studio which would not work well for Continues Deployment and Continues Integration (CD & CI).
- There might be troubles when Visual Studio version is changed or even worse if there are different Visual Studio versions used by Team Members.
- Althought the project file is in ASCII format it is unknown, so merging of changes is very problematic
- It is extremely hard to do any custom dialogs in the installer.
- No support for patches
- No support for auto-version increment which again might be the issue for CD
- No support for more complex components installation such as Windows Service
- No ways to create templates
Consequently, in the Installer Projects Extension it is necessary to still tediously fill out of the registry information need by SOLIDWORKS in the Installer Projects Extension registry tab
Yes, this is another thing which I do not like. In WiX or NSIS all of these keys are defined in the plain text or XML so can be easily copied. Basically once first WiX project is setup (and some sort of template is created) it will be way quicker to setup new installer for new project rather than using Visual Studio Installer as registry keys, icons, banners etc. will be already linked and it will be only required to change few variable values.
The convenient solution would be to create a custom action that can locate the path to regasm.exe and run it on the installed DLL (e.g., the command below), but no luck
It is not recommended to use custom actions for COM components registrations. Basically you will also need to implement custom actions for uninstallation, rollback, repair actions. And if on any of these steps COM dll is corrupted there is virtually no way to clearly remove the COM component.
And I usually use [ComRegisterFunction] in debug mode only by pretty much the reasons described above. And it is not transparent what keys have been added while registering an assembly. So if it wasn't unregistered properly all those keys are hanging in the registry, but this probably not that big deal - might be just a bit annoying.
Thanks for sharing. This is indeed a good option.
Not sure that I understand and agree with this point
All of the configuring and editing each time I created a new version.
You can get the version dynamically with something like this !(bind.FileVersion.FileId) and you can also setup your CD to populate this version - basically no need for any manual changes.
And WiX also supports defining of the variables, so to make an installer equivalent to the one in your example would be pretty much the same one-page Product.wxs of similar number of lines
I can see that InnoSetup is basically .exe file (not really an .msi) which in some cases may be a limitation (e.g. admin image, privileges etc.). And it seems like there is also no way to harvest the COM information for the dll (which is required for registering of the add-in) and the only option to use the regasm utility directly which is not a best way to go as I have explained in the previous post.
And as far as I can see the custom actions must be written in Pascal while WiX can do C# as well. This information might be obsolete though - not sure.
Artem, thank you for the thoughtful post. If we ever do continuous deployment then we will consider WiX. I just wish WiX wasn't so time-consuming to learn and tedious to use. Of course, you're correct that once you do have everything set up, the flexibility is unparalleled.