Re: [WiX-users] Calling a managed custom action from a UI control
Whenever Windows Installer launches a DLL-type custom action, it does so from a separate msiexec.exe process instance (sandboxing the custom action code, if you will). However, because this sandbox process may be reused, and because loading pre-4.x CLR runtimes marks the process preventing a different runtime from ever being loaded, DTF runs the assemblies in their own child process. When you build a DTF custom action assembly, a native stub is built/modified that contains an entry point for each method with a CustomActionAttribute, along with being packed with your assembly, config, and dependencies. This stub sends a copy of itself to RunDll.exe after creating a two-way communications pipe to communicate with its child process (which allows for querying the session for properties, running queries, etc.). The stub in the (grandchild) process establishes communication with its parent (the stub in the sandbox), extracts its payload, loads the indicated CLR, loads your assembly into an AppDomain, and finally calls your code (this is where the transition into managed code finally occurs). You seem to be hanging somewhere in this paragraph (at least until you kill the rundll.exe process). Are there any System or Application event log entries that may explain/describe some failure with the CLR spinup? Unfortunately calling MsiProcessMessage is documented to not work from a DoAction so any error or progress logging performed by the stub won't show up. -Original Message- From: McKinnon, Chris [mailto:cmckin...@atb.com] Sent: Monday, October 18, 2010 10:52 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Calling a managed custom action from a UI control Thanks for the ideas Steve. I tried running my code in a separate thread, like yours, but it still hangs. I'm running on Windows Vista Business 32-bit. I noticed, by accident, that in Process Explorer when the custom action starts up that a new process tree is spawned: 1. msiexec.exe 2. msiexec.exe 3. rundll.exe (DTF Self-Extracting Custom Action) The custom action is run when I click the next button on the ServiceOptionsDlg in my installer. The 1st time I click the button it hangs. If I kill the process tree above and click the next button again, it runs my custom action. Every time after that, if I click next, my custom action works fine. I'm baffled why. Here's the log from me, killing the process tree the 1st time (the one at 11:11:06:126), then running my custom action (Directory.Exists()) on a path of t and then on a path of C:\: Action 11:08:53: ServiceOptionsDlg. Dialog created MSI (c) (CC:24) [11:08:58:414]: PROPERTY CHANGE: Adding ARCHIVE_PATH property. Its value is 't'. MSI (c) (CC:24) [11:08:58:543]: PROPERTY CHANGE: Adding _DirectoryExists_Path property. Its value is 't'. MSI (c) (CC:24) [11:08:58:543]: Doing action: CheckArchiveDirectory Action 11:08:58: CheckArchiveDirectory. Action start 11:08:58: CheckArchiveDirectory. MSI (c) (CC:80) [11:08:58:573]: Invoking remote custom action. DLL: C:\Users\e25735\AppData\Local\Temp\MSIF23D.tmp, Entrypoint: DirectoryExists MSI (c) (CC:A8) [11:08:58:574]: Cloaking enabled. MSI (c) (CC:A8) [11:08:58:574]: Attempting to enable all disabled privileges before calling Install on Server MSI (c) (CC:A8) [11:08:58:575]: Connected to service for CA interface. Action ended 11:11:02: CheckArchiveDirectory. Return value 1. MSI (c) (CC:24) [11:11:06:126]: Doing action: CheckArchiveDirectory Action 11:11:06: CheckArchiveDirectory. Action start 11:11:06: CheckArchiveDirectory. MSI (c) (CC:A0) [11:11:06:184]: Invoking remote custom action. DLL: C:\Users\e25735\AppData\Local\Temp\MSIE4A7.tmp, Entrypoint: DirectoryExists MSI (c) (CC:A0) [11:11:06:184]: Lost connection to custom action server process. Attempting to regenerate. MSI (c) (CC:A8) [11:11:06:259]: Cloaking enabled. MSI (c) (CC:A8) [11:11:06:259]: Attempting to enable all disabled privileges before calling Install on Server MSI (c) (CC:A8) [11:11:06:259]: Connected to service for CA interface. MSI (c) (CC!8C) [11:11:31:366]: PROPERTY CHANGE: Adding _DirectoryExists_Result property. Its value is 'no'. Action ended 11:11:47: CheckArchiveDirectory. Return value 1. MSI (c) (CC:24) [11:11:47:571]: PROPERTY CHANGE: Adding VErr_Text property. Its value is 'The archive path specified does not exist.'. Action 11:11:47: ValidationErrDlg. Dialog created MSI (c) (CC:24) [11:11:57:555]: PROPERTY CHANGE: Modifying ARCHIVE_PATH property. Its current value is 't'. Its new value: 'c:\'. MSI (c) (CC:24) [11:11:57:731]: PROPERTY CHANGE: Modifying _DirectoryExists_Path property. Its current value is 't'. Its new value: 'c:\'. MSI (c) (CC:24) [11:11:57:731]: Doing action: CheckArchiveDirectory Action 11:11:57: CheckArchiveDirectory. Action start 11:11:57: CheckArchiveDirectory. MSI (c) (CC:14) [11:11:57:745]: Invoking remote custom action. DLL: C:\Users\e25735\AppData\Local\Temp\MSIAE3D.tmp, Entrypoint: DirectoryExists MSI
Re: [WiX-users] Prerequisite check for per-user vs per-machine installation
Does product B always install a particular component guid (or at least a
narrow set)?
-Original Message-
From: Lisa Gracias [mailto:lisathelugubri...@gmail.com]
Sent: Monday, October 18, 2010 10:38 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Prerequisite check for per-user vs per-machine
installation
I am building an installer for Product A. Product A should not be installed
unless Product B is already installed. There are multiple versions of
Product B that are supported by Product A. Product B does not create any
registry entries. So instead I am checking for the upgrade code of Product B
in the Product A installer. This worked fine until the latest release of
Product B came out. Now Product B supports both per-user and per-machine
installation, whereas it previously supported only per-user installation.
Product A supports only per-user installation, so the upgrade code search
fails if Product B was installed per-machine.
How do I create a check for Product B that will work for the existing
version and future versions as well?
Here is the relevant portion of the log:
MSI (c) (84:D0) [18:56:01:143]: Doing action: FindRelatedProducts
Action 18:56:01: FindRelatedProducts. Searching for related applications
Action start 18:56:01: FindRelatedProducts.
MSI (c) (84:D0) [18:56:01:143]: FindRelatedProducts: current install is
per-user. Related install for product
'{7124DD21-022E-4868-B9B3-B139C6BD8F77}' is per-machine. Skipping...
Action ended 18:56:01: FindRelatedProducts. Return value 1.
--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Merge Module
Thanks for reply I am using same machine for both projects the merge module as well as main project. There is no OS difference or any other configuration change if i do merge module with only language 1033 it works properly, but when i tried to do it with localization just i tried to do the things with foreach loop but it doesn't seems working for me can you please suggest me properway to achive localization with merge module Thank's Sagar S. -- Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Wix Mailing list
Can you please unsubscribe me from Wix mailing list? DubleG -- Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Wix Mailing list
On Tue, 19 Oct 2010 10:29:50 +0200 Ino Murko ino.mu...@uni-mb.si wrote: Can you please unsubscribe me from Wix mailing list? Your syntax was wrong: List-Unsubscribe: https://lists.sourceforge.net/lists/listinfo/wix-users, mailto:wix-users-requ...@lists.sourceforge.net?subject=unsubscribe So your subject should have been unsubscribe (not Wix Mailing list) and sent only to wix-users-request@, not wix-users@ . Alternatively, visit the sourceforge page. -- Bruce Cran -- Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Include question.
Good catch, I didn't even notice he was creating a merge module. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Include-question-tp5631284p5650417.html Sent from the wix-users mailing list archive at Nabble.com. -- Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Include question.
Just add ur merg module in ur main project directory where you want to put files after installation, and don't furget to add module referance in feature of your main project, i hope this will work. -- Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] MSI upgrade remove old registries
Hi Nick I've just found out about your book and I'll buy it soon Point1) I am using WIX to write registries, an example is provided Component Id='SPRegChange' Guid='51a1f782-f0f7-4798-82c4-723596a8c140' KeyPath=yes ... RegistryKey Root=HKLM Key=SOFTWARE\DOT\EasyScreen Action=create RegistryValue Name=RootDir Value=[DIREASYSCREEN] Type=string / RegistryValue Name=RootDirEasyTrade Value=[DIREASYSCREEN][ETNAME] Type=string / RegistryValue Value= Type=string / /RegistryKey ... /Component And is then referenced in the product.wxs Feature Id='Registry' Title='Update Registry' Description='Configure Registry Settings' Level='1' ... ComponentRef Id='SPRegChange' / /Feature Point2) I think I am a bit confused about major and minor/small upgrade My first installer installs some files and registry My second installer then updates the files (90%) to new versions With some addition, edition to registry But I expect the registry values added by first installer to remain if I have not touched them by second installer. In this scenario, should I not do major upgrade? My impression of what you said is that major upgrade will remove registry values from first installer not touched by second When I tried to do a minor upgrade, I remember I kept the upgrade and product code the same And I had to run from in command line with REINSTALL=ALL REINSTALLMODE=vomus The problem was that it puts the registry values back to what the installer default had, but we need to have them unchanged. Point3) Please let me know if I should do a major and minor upgrade. At this point, both ways don't work and I am stuck Regards Brian -Original Message- From: Nick Ramirez [mailto:nickra...@hotmail.com] Sent: 18 October 2010 17:46 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] MSI upgrade remove old registries A major upgrade, as you probably know, will completely remove the old version. So, if your second installer does not write to the registry, it makes sense that the value will be removed but not replaced. You shouldn't change the UpgradeCode for the lifetime of the product, across all upgrade scenarios. Are you using WiX to write to the Registry? What does that code look like then? How have you got the minor upgrade set up? Is it a patch? Or a full install? Does it use WiX elements to write to the Registry? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/MSI-upgrad e-remove-old-registries-tp5639349p5647762.html Sent from the wix-users mailing list archive at Nabble.com. -- Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users _ This e-mail was sent to you by EASYSCREEN LIMITED (EASYSCREEN). We are incorporated under the laws of England and Wales (company no. 05677531 and VAT registration no. 872810613). Our registered office is at 155 Bishopsgate, London EC2M 3TQ. This e-mail and/or any attached documents may contain privileged and confidential information and should only be read by those persons to whom this e-mail is addressed. Use by other than intended recipients is prohibited. If you are not the addressee, you must not copy, distribute, disclose or use any of the information in it. If you have received it in error, please delete it and immediately notify the sender. EASYSCREEN reserves the right to monitor all e-mail messages passing through its network. As we cannot guarantee the genuineness, accuracy or completeness of the information contained in this message, the statements set forth are not legally binding. -- Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] SharedDllRefCount on Upgrade
Well! That's exactly what's going on here. The overlapping keyfile thing is the problem - After fixing this (by puttting keyfile on the right file (NOT the component)), the problem is solved! Phil and Blair: you've both been a big help. Thanks again for looking at this weird problem (that I caused all by myself...ugh)... Greg -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/SharedDllRefCount-on-Upgrade-tp5639450p5651089.html Sent from the wix-users mailing list archive at Nabble.com. -- Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Calling a managed custom action from a UI control
Hi Blair, No log entries, unfortunately. I've let my installer sit spinning for about 20-30 minutes. I could let it sit longer but I don't think that would help. I'm going to try my installer on a Windows 2000 Professional workstation when I have a chance today. Let me know if there's anything else I can do to track down this issue. Thanks, Chris McKinnon -Original Message- From: Blair [mailto:os...@live.com] Sent: Tuesday, October 19, 2010 12:06 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Calling a managed custom action from a UI control Whenever Windows Installer launches a DLL-type custom action, it does so from a separate msiexec.exe process instance (sandboxing the custom action code, if you will). However, because this sandbox process may be reused, and because loading pre-4.x CLR runtimes marks the process preventing a different runtime from ever being loaded, DTF runs the assemblies in their own child process. When you build a DTF custom action assembly, a native stub is built/modified that contains an entry point for each method with a CustomActionAttribute, along with being packed with your assembly, config, and dependencies. This stub sends a copy of itself to RunDll.exe after creating a two-way communications pipe to communicate with its child process (which allows for querying the session for properties, running queries, etc.). The stub in the (grandchild) process establishes communication with its parent (the stub in the sandbox), extracts its payload, loads the indicated CLR, loads your assembly into an AppDomain, and finally calls your code (this is where the transition into managed code finally occurs). You seem to be hanging somewhere in this paragraph (at least until you kill the rundll.exe process). Are there any System or Application event log entries that may explain/describe some failure with the CLR spinup? Unfortunately calling MsiProcessMessage is documented to not work from a DoAction so any error or progress logging performed by the stub won't show up. -Original Message- From: McKinnon, Chris [mailto:cmckin...@atb.com] Sent: Monday, October 18, 2010 10:52 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Calling a managed custom action from a UI control Thanks for the ideas Steve. I tried running my code in a separate thread, like yours, but it still hangs. I'm running on Windows Vista Business 32-bit. I noticed, by accident, that in Process Explorer when the custom action starts up that a new process tree is spawned: 1. msiexec.exe 2. msiexec.exe 3. rundll.exe (DTF Self-Extracting Custom Action) The custom action is run when I click the next button on the ServiceOptionsDlg in my installer. The 1st time I click the button it hangs. If I kill the process tree above and click the next button again, it runs my custom action. Every time after that, if I click next, my custom action works fine. I'm baffled why. Here's the log from me, killing the process tree the 1st time (the one at 11:11:06:126), then running my custom action (Directory.Exists()) on a path of t and then on a path of C:\: Action 11:08:53: ServiceOptionsDlg. Dialog created MSI (c) (CC:24) [11:08:58:414]: PROPERTY CHANGE: Adding ARCHIVE_PATH property. Its value is 't'. MSI (c) (CC:24) [11:08:58:543]: PROPERTY CHANGE: Adding _DirectoryExists_Path property. Its value is 't'. MSI (c) (CC:24) [11:08:58:543]: Doing action: CheckArchiveDirectory Action 11:08:58: CheckArchiveDirectory. Action start 11:08:58: CheckArchiveDirectory. MSI (c) (CC:80) [11:08:58:573]: Invoking remote custom action. DLL: C:\Users\e25735\AppData\Local\Temp\MSIF23D.tmp, Entrypoint: DirectoryExists MSI (c) (CC:A8) [11:08:58:574]: Cloaking enabled. MSI (c) (CC:A8) [11:08:58:574]: Attempting to enable all disabled privileges before calling Install on Server MSI (c) (CC:A8) [11:08:58:575]: Connected to service for CA interface. Action ended 11:11:02: CheckArchiveDirectory. Return value 1. MSI (c) (CC:24) [11:11:06:126]: Doing action: CheckArchiveDirectory Action 11:11:06: CheckArchiveDirectory. Action start 11:11:06: CheckArchiveDirectory. MSI (c) (CC:A0) [11:11:06:184]: Invoking remote custom action. DLL: C:\Users\e25735\AppData\Local\Temp\MSIE4A7.tmp, Entrypoint: DirectoryExists MSI (c) (CC:A0) [11:11:06:184]: Lost connection to custom action server process. Attempting to regenerate. MSI (c) (CC:A8) [11:11:06:259]: Cloaking enabled. MSI (c) (CC:A8) [11:11:06:259]: Attempting to enable all disabled privileges before calling Install on Server MSI (c) (CC:A8) [11:11:06:259]: Connected to service for CA interface. MSI (c) (CC!8C) [11:11:31:366]: PROPERTY CHANGE: Adding _DirectoryExists_Result property. Its value is 'no'. Action ended 11:11:47: CheckArchiveDirectory. Return value 1. MSI (c) (CC:24) [11:11:47:571]: PROPERTY CHANGE: Adding VErr_Text property. Its value is 'The archive path specified does not exist.'. Action 11:11:47:
Re: [WiX-users] Prerequisite check for per-user vs per-machine installation
Does product B always install a particular component guid (or at least a narrow set)? I went through the installers for the last couple of versions and it looks like the component GUIDs stay the same. To be safe I posted a question on the Product B message board asking about their GUIDs. They said they are using Visual Studio to create their installer so they don't know how the GUIDs are generated or whether they'll change later on. Any idea what makes an auto-generated GUID change? -- Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX 3.5 C# Custom Action Project
I ran into the same issue and also solved it by setting the useLegacyV2RuntimeActivationPolicy attribute to true. However, I was (and still am) unable to see msi log entries about custom action assembly loads. For instance, my logs do not contain the text Hello, I'm your xxbit Impersonated custom action server. I'm logging via /lvx. Any suggestions on how to enable the assembly load logging? Thanks Ryan -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/WiX-3-5-C-Custom-Action-Project-tp5320937p5651686.html Sent from the wix-users mailing list archive at Nabble.com. -- Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Do WiX 3.0 link times improve using .wixlib files?
Hi Blair, Thanks for the tips... I'll see what happens when I get rid of the merge modules first. I am using cab reuse, but it seems that I have to be careful, especially if I build in parallel - one build will trash another build's cached cab. - Brian Brian Gillespie Rhinoceros Development Robert McNeel Associates On 10/18/2010 8:03 PM, Blair wrote: In any given build, most of the time is typically taken doing three things: moving files, building cabs, and embedding. For the scenario you describe, I would recommend each MSI end up with (at least) three cabs (1. the 70 MB common cab, 2. the 50 MB locale cab, and 3. the 3MB platform cab). Make sure you are using the cab reuse feature of light (on by default in more recent builds). Making non-bound wixlibs may (or may not) help light's cab reuse algorithm (it's been some time since I looked at it) but it could certainly help organize your build activity, so I would recommend looking at it for its code organizational aspects. Making merge modules will likely slow down your builds, since they have to embed the files, then extract them and (possibly) embed them again. You may see a speed increase by getting rid of your locale merge modules (especially if you do NOT make them binary/bound). The typical projects I work on tend to take between 15 and 65 minutes to link, and at most 1 minute of that is spent processing the XML, generating/populating/importing the tables, and other related tasks. All the rest is spent copying file content around. -Blair -Original Message- From: Brian Gillespie [mailto:br...@mcneel.com] Sent: Monday, October 18, 2010 12:10 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Do WiX 3.0 link times improve using .wixlib files? Hi, I have a project that builds 88 different flavors - the cross product of these three variables: Platform: x86 | x64 Configuration: Beta | Retail | Evaluation | Another Evaluation Locale: cs, en-us, es-es, de-de, fr-fr, it-it, ja, ko, pl, zh-cn, zh-tw A core exe (3MB) changes with both Platform and Configuration, and locale-related stuff changes with each local (50MB). The rest of the content of each installer is identical (70MB). A merge module is built for each locale. A big wix project then is built to make each flavor. It takes 3-5 minutes each. Would moving the shared contents from the core installer to a .wixlib or merge module make any difference in link times? It will take some effort to rearrange the code, and I don't want to bother if it will make no difference in the final build times. Do you have any things I should watch out for that could adversely affect performance? Thanks in advance, - Brian Brian Gillespie Rhinoceros Development Robert McNeel Associates -- Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Calling a managed custom action from a UI control
Are you really cranking up all this infrastructure just to see if a directory exists? There's got to be a simpler way, even if it's only a horrible little VBScript 10 line custom action. At least that is natively supported by Windows Installer. Phil Wilson -Original Message- From: McKinnon, Chris [mailto:cmckin...@atb.com] Sent: Tuesday, October 19, 2010 8:58 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Calling a managed custom action from a UI control Hi Blair, No log entries, unfortunately. I've let my installer sit spinning for about 20-30 minutes. I could let it sit longer but I don't think that would help. I'm going to try my installer on a Windows 2000 Professional workstation when I have a chance today. Let me know if there's anything else I can do to track down this issue. Thanks, Chris McKinnon -Original Message- From: Blair [mailto:os...@live.com] Sent: Tuesday, October 19, 2010 12:06 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Calling a managed custom action from a UI control Whenever Windows Installer launches a DLL-type custom action, it does so from a separate msiexec.exe process instance (sandboxing the custom action code, if you will). However, because this sandbox process may be reused, and because loading pre-4.x CLR runtimes marks the process preventing a different runtime from ever being loaded, DTF runs the assemblies in their own child process. When you build a DTF custom action assembly, a native stub is built/modified that contains an entry point for each method with a CustomActionAttribute, along with being packed with your assembly, config, and dependencies. This stub sends a copy of itself to RunDll.exe after creating a two-way communications pipe to communicate with its child process (which allows for querying the session for properties, running queries, etc.). The stub in the (grandchild) process establishes communication with its parent (the stub in the sandbox), extracts its payload, loads the indicated CLR, loads your assembly into an AppDomain, and finally calls your code (this is where the transition into managed code finally occurs). You seem to be hanging somewhere in this paragraph (at least until you kill the rundll.exe process). Are there any System or Application event log entries that may explain/describe some failure with the CLR spinup? Unfortunately calling MsiProcessMessage is documented to not work from a DoAction so any error or progress logging performed by the stub won't show up. -Original Message- From: McKinnon, Chris [mailto:cmckin...@atb.com] Sent: Monday, October 18, 2010 10:52 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Calling a managed custom action from a UI control Thanks for the ideas Steve. I tried running my code in a separate thread, like yours, but it still hangs. I'm running on Windows Vista Business 32-bit. I noticed, by accident, that in Process Explorer when the custom action starts up that a new process tree is spawned: 1. msiexec.exe 2. msiexec.exe 3. rundll.exe (DTF Self-Extracting Custom Action) The custom action is run when I click the next button on the ServiceOptionsDlg in my installer. The 1st time I click the button it hangs. If I kill the process tree above and click the next button again, it runs my custom action. Every time after that, if I click next, my custom action works fine. I'm baffled why. Here's the log from me, killing the process tree the 1st time (the one at 11:11:06:126), then running my custom action (Directory.Exists()) on a path of t and then on a path of C:\: Action 11:08:53: ServiceOptionsDlg. Dialog created MSI (c) (CC:24) [11:08:58:414]: PROPERTY CHANGE: Adding ARCHIVE_PATH property. Its value is 't'. MSI (c) (CC:24) [11:08:58:543]: PROPERTY CHANGE: Adding _DirectoryExists_Path property. Its value is 't'. MSI (c) (CC:24) [11:08:58:543]: Doing action: CheckArchiveDirectory Action 11:08:58: CheckArchiveDirectory. Action start 11:08:58: CheckArchiveDirectory. MSI (c) (CC:80) [11:08:58:573]: Invoking remote custom action. DLL: C:\Users\e25735\AppData\Local\Temp\MSIF23D.tmp, Entrypoint: DirectoryExists MSI (c) (CC:A8) [11:08:58:574]: Cloaking enabled. MSI (c) (CC:A8) [11:08:58:574]: Attempting to enable all disabled privileges before calling Install on Server MSI (c) (CC:A8) [11:08:58:575]: Connected to service for CA interface. Action ended 11:11:02: CheckArchiveDirectory. Return value 1. MSI (c) (CC:24) [11:11:06:126]: Doing action: CheckArchiveDirectory Action 11:11:06: CheckArchiveDirectory. Action start 11:11:06: CheckArchiveDirectory. MSI (c) (CC:A0) [11:11:06:184]: Invoking remote custom action. DLL: C:\Users\e25735\AppData\Local\Temp\MSIE4A7.tmp, Entrypoint: DirectoryExists MSI (c) (CC:A0) [11:11:06:184]: Lost connection to custom action server process. Attempting to regenerate. MSI (c) (CC:A8) [11:11:06:259]: Cloaking
Re: [WiX-users] Calling a managed custom action from a UI control
You are absolutely right. I just wanted to keep all my custom actions in the same DLL. I have two other actions for encrypting and decrypting the .config files. I switched my code to a VBScript and it works nicely. Here's the script if anyone is interested: Function DirectoryExists() Dim path, fso path = Session.Property(_DirectoryExists_Path) Set fso = CreateObject(Scripting.FileSystemObject) If (fso.FolderExists(path)) Then Session.Property(_DirectoryExists_Result) = yes Else Session.Property(_DirectoryExists_Result) = no End If DirectoryExists = ERROR_SUCCESS End Function It's still frustrating that the DLL approach didn't work. Thanks, Chris McKinnon -Original Message- From: Wilson, Phil [mailto:phil.wil...@invensys.com] Sent: Tuesday, October 19, 2010 11:38 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Calling a managed custom action from a UI control Are you really cranking up all this infrastructure just to see if a directory exists? There's got to be a simpler way, even if it's only a horrible little VBScript 10 line custom action. At least that is natively supported by Windows Installer. Phil Wilson -Original Message- From: McKinnon, Chris [mailto:cmckin...@atb.com] Sent: Tuesday, October 19, 2010 8:58 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Calling a managed custom action from a UI control Hi Blair, No log entries, unfortunately. I've let my installer sit spinning for about 20-30 minutes. I could let it sit longer but I don't think that would help. I'm going to try my installer on a Windows 2000 Professional workstation when I have a chance today. Let me know if there's anything else I can do to track down this issue. Thanks, Chris McKinnon -Original Message- From: Blair [mailto:os...@live.com] Sent: Tuesday, October 19, 2010 12:06 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Calling a managed custom action from a UI control Whenever Windows Installer launches a DLL-type custom action, it does so from a separate msiexec.exe process instance (sandboxing the custom action code, if you will). However, because this sandbox process may be reused, and because loading pre-4.x CLR runtimes marks the process preventing a different runtime from ever being loaded, DTF runs the assemblies in their own child process. When you build a DTF custom action assembly, a native stub is built/modified that contains an entry point for each method with a CustomActionAttribute, along with being packed with your assembly, config, and dependencies. This stub sends a copy of itself to RunDll.exe after creating a two-way communications pipe to communicate with its child process (which allows for querying the session for properties, running queries, etc.). The stub in the (grandchild) process establishes communication with its parent (the stub in the sandbox), extracts its payload, loads the indicated CLR, loads your assembly into an AppDomain, and finally calls your code (this is where the transition into managed code finally occurs). You seem to be hanging somewhere in this paragraph (at least until you kill the rundll.exe process). Are there any System or Application event log entries that may explain/describe some failure with the CLR spinup? Unfortunately calling MsiProcessMessage is documented to not work from a DoAction so any error or progress logging performed by the stub won't show up. -Original Message- From: McKinnon, Chris [mailto:cmckin...@atb.com] Sent: Monday, October 18, 2010 10:52 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Calling a managed custom action from a UI control Thanks for the ideas Steve. I tried running my code in a separate thread, like yours, but it still hangs. I'm running on Windows Vista Business 32-bit. I noticed, by accident, that in Process Explorer when the custom action starts up that a new process tree is spawned: 1. msiexec.exe 2. msiexec.exe 3. rundll.exe (DTF Self-Extracting Custom Action) The custom action is run when I click the next button on the ServiceOptionsDlg in my installer. The 1st time I click the button it hangs. If I kill the process tree above and click the next button again, it runs my custom action. Every time after that, if I click next, my custom action works fine. I'm baffled why. Here's the log from me, killing the process tree the 1st time (the one at 11:11:06:126), then running my custom action (Directory.Exists()) on a path of t and then on a path of C:\: Action 11:08:53: ServiceOptionsDlg. Dialog created MSI (c) (CC:24) [11:08:58:414]: PROPERTY CHANGE: Adding ARCHIVE_PATH property. Its value is 't'. MSI (c) (CC:24) [11:08:58:543]: PROPERTY CHANGE: Adding _DirectoryExists_Path property. Its value is 't'. MSI (c) (CC:24) [11:08:58:543]: Doing action: CheckArchiveDirectory Action 11:08:58:
Re: [WiX-users] Merge Module
Are you trying to build localized merge modules, or a multiple language merge module? What language(s) besides 1033 are you trying to use? You still haven't told me what OS you are using. -Original Message- From: sagar shinde [mailto:sagar.i...@gmail.com] Sent: Tuesday, October 19, 2010 12:31 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Merge Module Thanks for reply I am using same machine for both projects the merge module as well as main project. There is no OS difference or any other configuration change if i do merge module with only language 1033 it works properly, but when i tried to do it with localization just i tried to do the things with foreach loop but it doesn't seems working for me can you please suggest me properway to achive localization with merge module Thank's Sagar S. -- Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX 3.5 C# Custom Action Project
Are you including verbose in your logging? -Original Message- From: Ryan [mailto:rgrim...@gmail.com] Sent: Tuesday, October 19, 2010 9:59 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] WiX 3.5 C# Custom Action Project I ran into the same issue and also solved it by setting the useLegacyV2RuntimeActivationPolicy attribute to true. However, I was (and still am) unable to see msi log entries about custom action assembly loads. For instance, my logs do not contain the text Hello, I'm your xxbit Impersonated custom action server. I'm logging via /lvx. Any suggestions on how to enable the assembly load logging? Thanks Ryan -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/WiX-3-5-C-Cust om-Action-Project-tp5320937p5651686.html Sent from the wix-users mailing list archive at Nabble.com. -- Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX 3.5 C# Custom Action Project
Let me amend that. I'm not sure if it is a or i. Most of the time people mention /l*vx or simply /l*v. Skipping the rest of the selections (o, i, c, e, w, a, r, m, u, p) leaves a lot of logging out. -Original Message- From: Blair [mailto:os...@live.com] Sent: Tuesday, October 19, 2010 9:37 PM To: 'General discussion for Windows Installer XML toolset.' Subject: RE: [WiX-users] WiX 3.5 C# Custom Action Project Are you including verbose in your logging? -Original Message- From: Ryan [mailto:rgrim...@gmail.com] Sent: Tuesday, October 19, 2010 9:59 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] WiX 3.5 C# Custom Action Project I ran into the same issue and also solved it by setting the useLegacyV2RuntimeActivationPolicy attribute to true. However, I was (and still am) unable to see msi log entries about custom action assembly loads. For instance, my logs do not contain the text Hello, I'm your xxbit Impersonated custom action server. I'm logging via /lvx. Any suggestions on how to enable the assembly load logging? Thanks Ryan -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/WiX-3-5-C-Cust om-Action-Project-tp5320937p5651686.html Sent from the wix-users mailing list archive at Nabble.com. -- Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
