Search code examples
.netwpfdeploymentinstallationpublisher-policy

Slow wpf startup due to publish policy... maybe

I have deployed my .NET assemblies with x-copy for years, without any issue. From last week, we have a small team that wich has the task of build a setup that includes .NET assemblies and exe and c++ legacy exe and dll (more tha 200 files). After the first installation, I have an issue on my wpf application: the startup time is very huge. I have profiled one of my wpf application (ps: .NET assemblies are both GACed and NGened) with procmon and I have see that the process makes multiples operations (see attached screenshot) on all others unrelated (> 200) files and I think that this the main cause of slow application startup time. It's this related to .NET publisher policy? How I can disable this behavior to makes my applicaion again fast? Thanks in advance!

enter image description here

Solution

  • That set of traces appears to be related to COM instantiation based on "advertised" COM classes. Without knowing anything about how your MSI is organised into features, components and COM registration it's hard to be completely sure.

    But anyway, if the COM classes are registered using the Class table in the MSI file then they have an InprocServer32 registry value (NOT a key) called a Darwin descriptor. It refers to the target of the COM instantiation through feature name, product code and component code, and that could be why you're seeing references to Windows Installer feature and component keys in the registry. There's typically a call to MsiProvideComponent with that descriptor, resulting a resilience check and a repair if anything is broken.

    You don't say what tool you're using, but if you have a lot of COM registration and it's all advertised via registration in the MSIs Class table that could be the issue. Without knowing what tool you use to the build the MSI and seeing the MSI file it's hard to be sure. But WiX, for example, lets you use the Class table for registration but use Advertise=no, and that results in the registration being done using registry entries, which is the fairly obvious other way to create COM registration while avoiding advertising/resilience checks.

    Also, perhaps most importantly, you need to make sure that your product install is not in fact repairing itself when it starts up - that would slow it down a lot! If, for example, any files or registry items are deleted after being installed a repair could kick in. Look for MsiInstaller event log entries, in the Application event log referring to missing components.