Is the MSMQ Extension used?

[djohnst10]

I was the user that created #8628. I was very happy that @bevanweiss did the work to fix the issue. Thanks.

For our application, we use use our installer to create an MSMQ queue because we also use Hangfire to run long-running jobs in a Windows service and use Hangfire’s Hangfire.SqlServer.MSMQ NuGet package to be notified of new jobs without polling.

I was just watching the WiX Online Meeting 286 https://youtu.be/Blq4hqcVkfg?si=D2prskSUdnolWi4A and @robmen mentioned telemetry in order to determine which extensions are actually used.

We never upgraded to WiX 4 for reasons unrelated to WiX itself (too much other work, too small of a team) but if we had we would have discovered the bug sooner. The fact that the wasn’t reported by anyone else since version 4 was released may be indicating that the MSMQ extension isn’t used much at all.

When I explained to my manager why we couldn’t move to WiX 5 yet because of the bug, I actually remarked that we must be one of the few WiX users that uses the MSMQ extension because otherwise the bug would have been reported previously.

All of this is to say that I would understand if the MSMQ Extension were removed from WiX.

P.S. we also use the COMPlus extension. It’s a very old application.

[barnson]

Or, it's used, but because of the nature of those projects, there's no rush to move to newer versions of WiX. The release candidate phase is when we hope to find bugs like this...else it waits until another release.

Of course, if you're a FireGiant customer, you don't have to wait. :)

[djohnst10]

Or, it's used, but because of the nature of those projects, there's no rush to move to newer versions of WiX. The release candidate phase is when we hope to find bugs like this...else it waits until another release.

Very true. We are sort of in that category but WiX 4 and WiX 5 improvements have tempted me to try to upgrade.

Keep up the good work.

[bevanweiss]

P.S. we also use the COMPlus extension. It’s a very old application.

It would be great if you could have a look at the PR that I've got that should get COMPlus back and working under WiX5+
wixtoolset/wix#550
If there's additional COMPlus functionality that you think should be added to the tests and have an example of how to configure that part it would be great to hear about it. It would be ideal to have it all working fully so that others don't have to trip over it later.

[djohnst10]

I will take a look at your pull request.

I downloaded a nightly build of WiX with the MSMQ fixes but I never had a chance to make an installer build with that nightly build and so I never saw the COM+ issues that you’ve identified. I will try that as soon as I can.

We use COM+ with legacy VB6 and C++ COM components to make COM+ applications that are then used by a legacy Classic ASP application. We use Heat to harvest the COM registry stuff and then add our custom COM+ stuff to the same Component in WiX.

We are definitely not using all COM+ features. We don’t use partitions or register .NET classes in COM+. One feature we needed that the extension has never supported was running COM+ applications as a Windows service. We worked around that missing feature by configuring the COM+ applications using PowerShell and the scripting objects for COM+ after the installer is finished.

[bevanweiss]

We use COM+ with legacy VB6 and C++ COM components to make COM+ applications that are then used by a legacy Classic ASP application. We use Heat to harvest the COM registry stuff and then add our custom COM+ stuff to the same Component in WiX.

I haven't created a VB COM+ DLL to test with, if it triggers a different registration method than is currently already supported by the COMPlus Extension, I'd be happy for an example component to try to add in support for it however.

We are definitely not using all COM+ features. We don’t use partitions or register .NET classes in COM+. One feature we needed that the extension has never supported was running COM+ applications as a Windows service. We worked around that missing feature by configuring the COM+ applications using PowerShell and the scripting objects for COM+ after the installer is finished.

From my quick reading, it looks like this 'running as service' is really just a configuration tick box against a component already registered as a server application (rather than a library). I'm probably missing tests for the entire 'server application' registration thus far, I've only tested library I think... although not sure if there's a significant difference in the registration process.