How to register a dll in Wix 4?

[TheDarkDefenderr]

Hello,

recently I've switched from InstallSgield to Wix v4. I would like to know how to register a dll (.NET and COM) the easiest way in my WiX project.

In InstallShield it was options set for component:
COM Extract at Build (for COM file)
.NET COM Interop (for .NET dll)
The extraction of registries was performed during build time.

And is there something like those options to use in WiX? I haven't found clear answer on the web.

[chrpai]

Does your COM metadata change frequently from build to build? If not, in InstallShield I would use the right click | COM extract on the component keyfile. This scans the file one time and authors it statically. It's more reliable and faster because it's tested metadata and the build doesn't have to scan it. I personally have an aversion to anything dynamic at build time unless there's a really good reason for it.

That said, if it does change frequently, A LOT of WiX users use harvesting in their build process. This is like using dynamic files in InstallShield and can scan native COM libraries and COMVisible assemblies. Check out:

https://wixtoolset.org/docs/tools/heat/

About 15 years ago I did a huge migration from InstallShield to WiX for a product line that had a lot of COM. In wix v3 Heat was an EXE you could call. I wrote a simple utility that put a file system watcher on a directory and every time the directory changed it ran heat and displayed the XML in a colorized and formatted way. Sometimes Foo.dll will fail to register if Bar.dll was missing. But maybe Bar.dll wasn't COM. So you'd drop Foo.dll in the folder, then drop Bar.dll in the folder and cherry pick the Foo.dll component out and integrate it into your source. I did hundreds of DLLs this way and it worked really well. I've always meant to recreate that tool but I rarely touch COM these days to be honest.

[TheDarkDefenderr]

Yes, unfortunately metadata changes, interfaces and other entries also. When we've kept all dependencies on the machine where installer was builded all was fine with extracting during build-time.

You are right then, when something was missing registries were broken. It is tough to verify if registries after installation are correct for a file. You can do it manually but it's a lot of work for large number of files.

But I'll learn more about Heat for sure, maybe it's a good way.

[chrpai]

FYI... I recently discovered that Heat is going away. In v3 heat.exe was installed with WiX but in v4 it's not installed when you install wix using dotnet install tool. They have greated a wixtoolsetsdk.heat (think thats the right name) that provides a way to do it via msbuild and if you really really want to use heat.exe you'll find it in your nuget package cache when you install that. I read an issue where they basically said they don't want to encourage that.

I would also add that outside of WiX, FireGiant has invested in some proprietary tech that's more advanced then Heat called HeatWave. Votive was long in the tooth with lots of technical debt so when they rewrote it they kept it proprietary but released it free as HeatWave Community Edition. The writing is on the wall that there will be a paid version of HeatWave some day in the future that will probably have the advanced capabilities that you are looking for. I don't know your budget but it might be worth checking out.

It sould also be noted that you could also do something like author those components as merge modules using InstallShield limited edition and then merging those modules into a WiX v4 built package. Merge modules get a bad rap but IMO (20 years worth) merge modules are fine if you control them and don't share with others or use modules provided by others. They are heavier weight then fragments and libraries but enable you to use multiple tools to accomplish things that neither tool excel at.

[chrpai]

Sorry, my coffee hasn't kicked in yet. InstallShield Limited edition doesn't support authoring merge modules. But it could author a micropackage MSI that you then bundle along with your WiX MSI using Burn. Assuming you need a bootstrapper...

Did I mention that I really don't miss COM? :) We used to have 50 snapshotted virual machines. They were pooled together based on various configurations so that we could get a clean reproducible build every time. These days we have ephemeral servers but to be honest I sometimes question the value as we just don't have the pain points that we had back in the day.

[TheDarkDefenderr]

We are getting away from COM also. But it doesn't matter because we still have .NET assemblies that have to be registered. So far I've found that Heat nuget like you've wrote probably have some capability to extract such registries. But I have to give it a try first.

[chrpai]

You probably already know this but for the benefit of all COM and COM Visible are two different things. COM are WinPE Dlls with exported functions DllRegisterServer() and DllUnRegisterServer() that can be registered using RegSvr32.exe and COM Visible are .NET Framework DLLs that lack these functions and are registered using RegAsm.exe. You can also use RegAsm.exe /regfile to sniff out the COM registry entries and write them to a reg file and migrate them to wxs code.

Now the important trivia that some may not be aware of. If you have custom registration code in your assembly RegAsm.exe /regfile will not capture them.

https://learn.microsoft.com/en-us/dotnet/framework/tools/regasm-exe-assembly-registration-tool

Remarks
You can use the /regfile option to generate a .reg file that contains the registry entries instead of making the changes directly to the registry. You can update the registry on a computer by importing the .reg file with the Registry Editor tool (Regedit.exe). The .reg file does not contain any registry updates that can be made by user-defined register functions. The /regfile option only emits registry entries for managed classes. This option does not emit entries for TypeLibIDs or InterfaceIDs.

[TheDarkDefenderr]

Yes, I knew it already, but I didn't want to just added some registries created by me or regasm.exe. I just want to find a way to set registration of a file in the project and for every new version of installer won't think about it again. Right now I am fighting with Heat harvesting, especially HarvestFile. I seems that it might work but I have some warnings now when I am trying to build the installer. Also Deployment Dojo that @robmen is posting on youtube is helpful.

[chrpai]

I'd ask Rob/FireGiant what tools they have outside of WiXToolset for this for sale.

[TheDarkDefenderr]

I see that there is HeatWave Build Tools available for sale. But to be honest, my company migrated from InstallShield to WiX to reduce costs, so for now only good old Heat for me :)
https://www.firegiant.com/products/heatwave-build-tools/

[robmen]

If the only reason your company is migrating from InstallShield to WiX is because the OSS tools can be downloaded for free, that means your company doesn't value your time, and it doesn't value our time either. That sort of behavior does not surprise me, but it still makes me sad.

[TheDarkDefenderr]

We are just started discovering WiX Toolset and it's usage. If I'll see that version that we have to pay is a lot better and flexible (I see already benefits using HeatWave Build Tools rather that Heat) we consider investing in it.

[TheDarkDefenderr]

So I am back. Now I know how to harvest a file to extract registries using HarvestFile, how to set it in my wixproj file. But I would like to build my installer from command line. Is there a way to do it? Do you know a syntax how heat can be used during build of WiX project? I am still talking about WiX v4. So far my command is:
wix build *.wxs -ext WixToolset.Ui.wixext -loc *.wxl -culture en-US -arch x64 -o "test.msi"

[Stroniax]

Were you able to see the WiX source code extracted from the dll? I am trying to pack a .NET 8 project that is COM visible into an MSI using WiX and I'm having trouble figuring out how to do so.

[TheDarkDefenderr]

In my case it's 2 folders up to project folder. Inside wixobj should be .wxs file with strange name of mix dll, directory and there you should find your information. SO:
your_project.wixproj/../../wixobi/_yourDLL_INSTALLDIR.wxs

[chrpai]

.wixproj files are msbuild files. You can build them using MSBuild. Just specify the platform and configuration you want ( Release|x64) and the rest is automatic.

[TheDarkDefenderr]

And do you know if MSBuild can be added into machine NOT from Visual Studio?

[chrpai]

Sure, it's always been possible. If you want the latest MSBuild just install the VS Build Tools. If you want an older one it's probably on your machine already as it used to ship with .NET Framework. Search your harddrive for msbuild.exe and you are likely to find various versions of x86 and x64 bitness.

[TheDarkDefenderr]

It's exactly like you've wrote. I wonder if I should build my installers via MSBuild or from command line with wix command. Because we have automatic platform that is building your products.

[chrpai]

MSBuild all the way IMO.

[wittiw]

Hello,
I have a similar issue. I can handle MSBuild.exe to simple extraction of COM registries. But component items are always dynamically generated with new random ids and guids.
Is it a way to use previously specified guid?
Or better, components are previously specified and heat harvesting only adds COM registry entries to them?
It's important to me to keep the same guid for specific libraries.

[TheDarkDefenderr]

It's a good question. I am interested in this solution also, to keep GUID always the same.

[wittiw]

Another related question: is it possible to harvest registry entries from 64bit libraries?
I get from msbuild:

Severity	Code	Description	Project	File	Line	Suppression State
Warning	HEAT5150	Could not harvest data from a file that was expected to be a SelfReg DLL: [path]. If this file does not support SelfReg you can ignore this warning. Otherwise, this error detail may be helpful to diagnose the failure: Unable to load file: [path], error: 193

Has this issue already been resolved?