Unintuitive error in msi log when DTF is misconfigured

Took me a little headscratching to figure this one out. I was getting an error from my installer with the following text:

MSI (s) (A8:50) [14:27:03:446]: Product: MyProduct -- Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action CA_ConfigFile_Install_Immediate, entry: CA_ConfigFile_Install_Immediate, library: C:\WINDOWS\Installer\MSI51BF.tmp

The problem was not really that a DLL was missing, but that I had a typo in my <CustomAction DllEntry="xxx"> declaration. The typo caused a mismatch between the DllEntry value and the actual name of the .NET method implementing the [CustomAction].

Comments

Post a Comment

Popular posts from this blog

Web Deployment Projects targeting x64

I am working on an ASP.NET web application which has mixed-mode C++/CLI dependencies that call out to pure unmanaged DLLs. A new requirement is a 64-bit version of the application (it runs fine on Win64 in a IIS 32-bit app pool, but since 32-bit mode is an all-or-nothing proposition, it was decided we need a true 64 bit app.) I ran into a problem getting the Visual Studio Web Deployment Project to compile my app. It seems that aspnet_compiler.exe loads all of the dependencies during compilation, and the 32 bit compiler cannot load the 64 bit images (you get a "bad image format" error.) This is true even on Win64 build machines that have the .NET Framework64 (and therefore the 64-bit aspnet_compiler.exe) After a bit of spelunking through the .wdproj, I found that a relatively simple change to the MSBUILD file shipped with the WD project will allow this to work out. It simply forces MSBUILD to use the 64 bit compiler if the $(Platform) variable is set to "x64" Here is...
Read more

NServiceBus distributor configuration

Technical notes from figuring out how to deploy NServiceBus in a distributed environment, beyond the simple development setups: 1. In a pub-sub scenario, distributors do not need any configuration specific to the publisher they are distributing for, or the subscribers they are distributing to. The configuration they do need is to mainly to define unique queue names for the queues that the distributor owns: NServiceBus.Distributor.dll.config: <add key="DataInputQueue" value="MyDistributorDataInputQueue" /> <add key="ControlInputQueue" value="MyDistributorControlQueue" /> <add key="ErrorQueue" value="MyEnterpriseErrorQueue@machine" /> <add key="StorageQueue" value="MyDistributorStorageQueue" /> At runtime, the subscriber contacts the distributor, sending it a subscription message that includes the publisher's address and the subscription message type. This makes the distribu...
Read more