[wix-users] Weird and unwanted advertising behavior

[Benjamin Zuill-Smith]

Actually I found later in the log, the assemblies ARE published (see below)
so I'm not sure how to figure out what is being installed as an advertised
component and triggered on application load. Any ideas how to diagnose this?

This log seems to show the details of MsiPublishAssemblies (there is more
to this, this is just the start of it).

MSI (s) (00:38) [10:45:02:972]: Executing op:
ActionStart(Name=MsiPublishAssemblies,Description=Publishing assembly
information,Template=Application Context:[1], Assembly Name:[2])
Action 10:45:02: MsiPublishAssemblies. Publishing assembly information
MSI (s) (00:38) [10:45:02:972]: Executing op:
AssemblyPublish(Feature=ProductFeature,Component={1CAFFD75-22D5-A83A-EBA0-19D68B7A76E7}[~]2,AssemblyType=1,,AssemblyName=stdole,Version="7.0.3300.0",Culture="neutral",PublicKeyToken="B03F5F7F11D50A3A",ProcessorArchitecture="MSIL",)
MsiPublishAssemblies: Application Context:Global, Assembly
Name:stdole,Version="7.0.3300.0",Culture="neutral",PublicKeyToken="B03F5F7F11D50A3A",ProcessorArchitecture="MSIL"
MSI (s) (00:38) [10:45:02:972]: Note: 1: 1402 2:
UNKNOWN\Installer\Assemblies\Global 3: 2
MSI (s) (00:38) [10:45:02:972]: Executing op:
AssemblyPublish(Feature=ProductFeature,Component={C2DDED36-C8E0-8CCF-B00E-97D23E655B44}[~]2,AssemblyType=3,AppCtx=C:\Program
Files
(x86)\VectorDraw\Common\vdRegTLB.exe,AssemblyName=vdRegTLB,Version="7.7005.1.1",Culture="neutral",PublicKeyToken="54EAC14E23C9EE53",ProcessorArchitecture="x86",)

Ben Zuill-Smith

On Wed, Aug 24, 2016 at 10:41 PM, Benjamin Zuill-Smith <
bzuillsmith at gmail.com> wrote:

> I'm on Wix 3.10.3 using Visual Studio 15 with Update 1.
>
> I am adding a merge module from a third party. Clearly it has some issues
> because I have to add the following in order for the installer to compile:
>
> <EnsureTable Id="Error"/>
> <AdvertiseExecuteSequence>
>   <MsiPublishAssemblies></MsiPublishAssemblies>
> </AdvertiseExecuteSequence>
> <InstallExecuteSequence>
>   <MsiUnpublishAssemblies></MsiUnpublishAssemblies>
>   <MsiPublishAssemblies></MsiPublishAssemblies>
> </InstallExecuteSequence>
>
> I also had to add some other things to InstallExecuteSequence, but I don't
> think that matters.
>
> The issue I have is that there are advertise steps that happen when I run
> the program. I think the installer pops up and publishes some .NET
> assemblies but it's not exactly clear because it doesn't give much info as
> it performs the operation. The installer pops up multiple times while using
> the program (different assemblies being loaded I think). Is this because I
> add that action to the advertise sequence? Without it, Wix says it MUST be
> there and errors out. The most odd part here is the merge module I am
> adding does not contain anything in it's ModuleAdvtExecuteSequence, so why
> would I need that there?
>
> Just to help narrow things down, I checked the log of my installer and it
> showed the following for the MsiPublishAssemblies step:
>
> MSI (s) (00:38) [10:44:55:437]: Doing action: MsiPublishAssemblies
> MSI (s) (00:38) [10:44:55:437]: Note: 1: 2205 2:  3: ActionText
> Action 10:44:55: MsiPublishAssemblies. Publishing assembly information
> Action start 10:44:55: MsiPublishAssemblies.
> MsiPublishAssemblies: Application Context:Publishing assembly information,
> Assembly Name:
> Action ended 10:44:55: MsiPublishAssemblies. Return value 1.
>
> It looks to me like no assemblies were published and I expect a couple
> dozen or more to be published because they are listed in the merge module
> table MsiAssembly and MsiAssemblyName. After running the program and
> letting the installer do it's thing, the program seems to work properly.
>
> So finally, my questions:
>
>    1. Can I completely turn off the ability to advertise anything in the
>    install process? I don't want anything to be advertised at all.
>    2. What can I do to remove these advertising sequence actions?
>    3. If I haven't provided enough info, what more do I need to provide
>    and what can I do to further diagnose the issue?
>
>
>
>
>
> Ben Zuill-Smith
>