Re: [WiX-users] How does Torch decide which files changed?!
Hi, After all your help :) I think I have a solution to my problem, please let me know what you think: My product is already installed on customers machines, I didn't save the wixpdb nor the files.wxs (the Heat harvest file) of those releases, since I didn't know I'll need them to issue a patch, I also don't have the product Id since it's * (auto generated). So, I need to rebuild my code and create the MSIs again with the same code as the released product making sure I hard code the Original Product Id I take from the released MSI. Then I make my changes (fix the bug or whatever) and rebuild my code and create the MSIs again MAKING SURE to use the same files.wxs created by the previous HEAT harvest (so the GUIDS will be the same). Now I have both wixpdb files without the change and with the change. I torch them to get the diff.wixmst. (using the -xi and -p flags) And then I pyro. (pyro.exe patch\patch.wixmsp -out patch.msp -t RTM patch\diff.wixmst -v) The customer needs to install the msp with this command: MSIEXEC /update \\tomer-c-d3\Share\patch.msp REINSTALL=ALL REINSTALLMODE=a It seems a bit cumbersome, will it work? :) Thanks again. -Original Message- From: Blair [mailto:os...@live.com] Sent: Monday, January 30, 2012 9:51 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] How does Torch decide which files changed?! One way to see what the transforms in a patch actually contain WRT any particular MSI, open the MSI in Orca, then open the MSP file using the Transform menu item View a patch. It will highlight the database changes, and in the case of files, you can look at the two file-related tables to see which files it thinks have been changed. -Original Message- From: tome...@qualisystems.com [mailto:tome...@qualisystems.com] Sent: Saturday, January 28, 2012 10:59 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] How does Torch decide which files changed?! One more thing, I opened the msp file with z7, there are only: exe dll (.net assemblies) and one txt file!? there. -Original Message- From: Blair [mailto:os...@live.com] Sent: Friday, January 27, 2012 10:24 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] How does Torch decide which files changed?! Torch marks up the database changes. Including -p causes it to leave the unchanged portions of the database intact so they will be present for Pyro to use in its processing. It is Pyro that looks at the two files and determines if they are the same or not, and it promotes files that compare as different to be considered as changed and thus be included with the other marked database changes. If you use WIXOUT or WIXPDB files then fragment boundaries are considered in the comparisons, so if you specify references to things to include in your patch family/families, things that are not in any referenced fragments are ignored (by design). Look for the files you are concerned with in the WIXMST file. You should find either paths or references to cabinet-ids for both the updated and the previous versions of the files. Blair -Original Message- From: tome...@qualisystems.com [mailto:tome...@qualisystems.com] Sent: Thursday, January 26, 2012 7:19 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] How does Torch decide which files changed?! I'm creating a patch, I'm not sure that the patch includes all of my files even though I'm passing the -p flag to the torch.exe. Can someone please explain to me the logic that torch uses to determine what files are included in the patch. Thanks. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro
[WiX-users] Bootstrapper logo in wrong location
Hi, The WIX manual says, The WiX Standard Bootstrapper Application displays a generic logo in the bottom left corner of the user interface. WixVariable Id=WixStdbaLogo Value=path\to\customlogo.png / I used this last year (the version was 3.6.1608.0), and yes, the log showed up in the bottom left corner of the dialog. Now I am using v3.6.2221.0 and it doesn't behave that way any more. The logo is always in the top left corner and it only displays the square shape, so that if my image is rectangle, it is clipped. I strongly believe this is a regression. If not, can anyone point me what I am missing? TIA. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Visual C++ 2010 Merge Module
Hi Blair, Thanks for your reply. Let me explain the reason why we're using the registry search inside the MSM. We have a product containing a COM object, let's call this product A. We also have a product which is using the COM object of product A, let's call this one product B. We've made both an installer and a MSM of product A. And the installer of product B embeds the MSM of product A. Then we released product B, and later decided to change the installation directory for product A. When someone installs product B, the COM object is registered in the old path. When he installs product A afterwards, the old registration is overwritten with the new location of the product A binaries. If he uninstalls product A, the registry gets corrupted because the COM registration still points to the new location, while the binaries installed by product B are located in the old location. To overcome this problem, we wanted to let both the installer and MSM of product A write a registry key containing the install directory. When either the installer, or MSM, gets installed, it will first try to retrieve the install directory from the registry to make sure it will install the binaries to the same directory when the product is already installed. As it seems, this registry search is not working very well inside the MSM. Given our problem, does someone have an idea on how to deal with this? We also thought about stopping using MSM's, but the disadvantage of embedding the product A installer inside the product B installer is that product A is not refcounted. So when product B gets uninstalled, it cannot tell whether or not it should remove product A as well. All ideas are appreciated! Thanks! -Original Message- From: Blair [mailto:os...@live.com] Sent: Tuesday, January 31, 2012 4:38 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Visual C++ 2010 Merge Module Several action don't seem to be intended to be found in MSMs. Maybe AppSearch is one of them. Do you distribute your MSM publically? If not, I've got a couple of ideas. 1) Run a couple of SQL queries against the MSM to remove them from the two Module*Sequence tables. 2) Change from using MSMs and instead generate/consume WixLibs instead. If you do distribute MSMs publically then each idea I have has limitations. -Original Message- From: Joost van Zoest [mailto:jzo...@siqura.com] Sent: Tuesday, January 31, 2012 6:41 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Visual C++ 2010 Merge Module I've validated my MSM in Orca. At first, I got a lot of ICE33 warnings because of some COM registration logic. To rule out that this was causing my problems, I removed this registration logic and validated the MSM again. Now the validation completes, but ends with: Execution ERROR 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. I'm using Orca with the darice.cub of WIX 3.6 BETA Looking further in Orca, I saw 2 tables (ModuleInstallExecuteSequence and ModuleInstallUISequence) which both contained an action called AppSearch with a Sequence of 50. I guess the actions of these tables are moved to the InstallExecuteSequence and InstallUISequence tables when you embed this merge module into an installer. So could this be the cause of the warnings I see when I build my installer? Somewhere in my merge module I perform a registry search to get a directory from the registry: Property Id=MYDIRECTORY RegistrySearch Id=REG_DirectorySearch Type=raw Root=HKLM Key=Software\MyApplication Name=InstallDir/ /Property *MYDIRECTORY is the ID of a Directory element. When I remove this registry search, the AppSearch actions are also removed from the 2 tables. And I don't get the warnings anymore when I build the installer containing this merge module. The original problem, that a registry key was not written when you run the installer, is also gone now. Am I using the RegistrySearch in a correct way? Or is there another way to fill the Directory element with a value from the registry? This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list
Re: [WiX-users] Burn - Moving payload to Cache Directory
I faced the same problem with the .Net 4.0 prerequisite. It seems that the
package is actually downloaded, even though it is not uninstalled.
Here is my package declaration:
ExePackage
Id=Netfx4Full
Cache=no
Compressed=no
PerMachine=yes
Permanent=yes
Vital=yes
SourceFile=$(var.PrerequisiteLocation)\dotNetFramework\dotNetFx40_Full_x86_x64.exe
DownloadUrl=http://go.microsoft.com/fwlink/?LinkId=164193;
DetectCondition=Netfx4FullVersion AND (NOT VersionNT64 OR
Netfx4x64FullVersion) /
And here is an excerpt from the log file:
[166C:1BB0][2012-02-01T14:44:03]: Detect 24 packages
[166C:1BB0][2012-02-01T14:44:03]: Setting string variable
'Netfx4x64FullVersion' to value '4.0.30319'
[166C:1BB0][2012-02-01T14:44:03]: Setting string variable
'Netfx4FullVersion' to value '4.0.30319'
...
[166C:1BB0][2012-02-01T14:44:03]: Condition 'Netfx4FullVersion AND (NOT
VersionNT64 OR Netfx4x64FullVersion)' evaluates to true.
[166C:1BB0][2012-02-01T14:44:03]: Detected package: Netfx4Full, state:
Present, cached: No
[166C:1BB0][2012-02-01T14:44:03]: Detect complete, result: 0x0
[166C:1BB0][2012-02-01T14:44:03]: Plan 24 packages, action: Uninstall
...
[166C:1BB0][2012-02-01T14:44:03]: Planned package: Netfx4Full, state:
Present, default requested: Absent, ux requested: Absent, execute: None,
rollback: Install, cache: Yes, uncache: Yes, dependency: Register
...
[166C:1BB0][2012-02-01T14:44:03]: Plan complete, result: 0x0
[166C:1BB0][2012-02-01T14:44:03]: Apply begin
[166C:198C][2012-02-01T14:44:04]: Download engine HTTP 200 HEAD to
http://go.microsoft.com/fwlink/?LinkId=164193
[166C:198C][2012-02-01T14:44:10]: Download engine HTTP 200 GET to
http://go.microsoft.com/fwlink/?LinkId=164193
[1BC4:2A2C][2012-02-01T14:48:28]: Moving payload from working path
'C:\Users\ADMINI~1\AppData\Local\Temp\2\{c2fb7e96-b16a-4628-8d82-a939c450ac29}\Netfx4Full'
to path 'C:\ProgramData\Package
Cache\58DA3D74DB353AAD03588CBB5CEA8234166D8B99\dotNetFx40_Full_x86_x64.exe'
...
[1BC4:1E7C][2012-02-01T14:48:32]: Removing cached package:
58DA3D74DB353AAD03588CBB5CEA8234166D8B99, from path: C:\ProgramData\Package
Cache\58DA3D74DB353AAD03588CBB5CEA8234166D8B99\
[1BC4:1E7C][2012-02-01T14:48:32]: Removing cached package:
{E824C6A7-F3B1-4CB0-B820-2CC14C9F86DA}v2.4.9.5, from path:
C:\ProgramData\Package Cache\{E824C6A7-F3B1-4CB0-B820-2CC14C9F86DA}v2.4.9.5\
[1BC4:1E7C][2012-02-01T14:48:32]: Removing bundle dependency key:
{c2fb7e96-b16a-4628-8d82-a939c450ac29}
[1BC4:1E7C][2012-02-01T14:48:32]: Removing cached bundle:
{c2fb7e96-b16a-4628-8d82-a939c450ac29}, from path: C:\ProgramData\Package
Cache\{c2fb7e96-b16a-4628-8d82-a939c450ac29}\
[166C:1BB0][2012-02-01T14:48:32]: Apply complete, result: 0x0 restart: No
[166C:1BB0][2012-02-01T14:48:55]: Shutting down, exit code: 0x0
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-Moving-payload-to-Cache-Directory-tp7237441p7243219.html
Sent from the wix-users mailing list archive at Nabble.com.
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] msp patch does not update one of files
With the very same base MSI view installed with the very same options, and the very same patch applied to it, variations of application would most likely then be due to the file versioning rules (usually non-versioned files that are written/touched outside of the InstallFiles action). Everything done to an installation is significant when trying to reproduce behavior. That is part of the reason verbose logging every time during developmenttesting is so important ... to help with the forensics of what's happening. Blair -Original Message- From: Sergey [mailto:sh0...@gmail.com] Sent: Tuesday, January 31, 2012 10:40 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] msp patch does not update one of files This behaviour is not stable. When I removed everything and repeated test again - file patched. This makes me frightened that on some clients' machines patch will work ok, but on some will fail. It is the worst variant, when I can not reproduce bug on my PC. 30.01.2012 21:46, Wilson, Phil пишет: And in the verbose log, see if there are any SELMGR entries. They indicate that you've broken component rules during a patch by deleting a component. Otherwise look at the log to see what it says about that particular file and why it didn't replace it. Phil W -Original Message- From: Fyodor Koryazhkin [mailto:fyodor...@gmail.com] Sent: Sunday, January 29, 2012 12:11 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] msp patch does not update one of files Hi, To find out why file is not being updated you can do the following: 1. Examine log file. 2. Apply patch to the target image at design time: a. Open target image in ORCA b. Open Transforms - View Patch c. All changed tables, rows and columns will be marked in green rectangle d. Check version, sequence and language for suspicious file. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How does Torch decide which files changed?!
If the only changes in your bug fix are files in the file table, that should work. To rebuild your code you may consider using dark on your released MSI to get your base WIXPDB and to get your starting point for your bug fix. The REINSTALL property will be autoselected to be the smallest section of already installed features that cover all of the database changes contained in the patch if you don't override it (as you are proposing). Normally the default value should suffice, unless you have a complex feature/component tree or if you have files that don't lend themselves well to the file versioning rules. Your overridden value for REINSTALLMODE property will prevent application of registry and shortcuts from the patched view. If you don't have a requirement for the a flag, the default should suffice. Blair -Original Message- From: tome...@qualisystems.com [mailto:tome...@qualisystems.com] Sent: Wednesday, February 01, 2012 12:26 AM To: wix-users@lists.sourceforge.net Cc: alex...@qualisystems.com; rone...@qualisystems.com Subject: Re: [WiX-users] How does Torch decide which files changed?! Hi, After all your help :) I think I have a solution to my problem, please let me know what you think: My product is already installed on customers machines, I didn't save the wixpdb nor the files.wxs (the Heat harvest file) of those releases, since I didn't know I'll need them to issue a patch, I also don't have the product Id since it's * (auto generated). So, I need to rebuild my code and create the MSIs again with the same code as the released product making sure I hard code the Original Product Id I take from the released MSI. Then I make my changes (fix the bug or whatever) and rebuild my code and create the MSIs again MAKING SURE to use the same files.wxs created by the previous HEAT harvest (so the GUIDS will be the same). Now I have both wixpdb files without the change and with the change. I torch them to get the diff.wixmst. (using the -xi and -p flags) And then I pyro. (pyro.exe patch\patch.wixmsp -out patch.msp -t RTM patch\diff.wixmst -v) The customer needs to install the msp with this command: MSIEXEC /update \\tomer-c-d3\Share\patch.msp REINSTALL=ALL REINSTALLMODE=a It seems a bit cumbersome, will it work? :) Thanks again. -Original Message- From: Blair [mailto:os...@live.com] Sent: Monday, January 30, 2012 9:51 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] How does Torch decide which files changed?! One way to see what the transforms in a patch actually contain WRT any particular MSI, open the MSI in Orca, then open the MSP file using the Transform menu item View a patch. It will highlight the database changes, and in the case of files, you can look at the two file-related tables to see which files it thinks have been changed. -Original Message- From: tome...@qualisystems.com [mailto:tome...@qualisystems.com] Sent: Saturday, January 28, 2012 10:59 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] How does Torch decide which files changed?! One more thing, I opened the msp file with z7, there are only: exe dll (.net assemblies) and one txt file!? there. -Original Message- From: Blair [mailto:os...@live.com] Sent: Friday, January 27, 2012 10:24 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] How does Torch decide which files changed?! Torch marks up the database changes. Including -p causes it to leave the unchanged portions of the database intact so they will be present for Pyro to use in its processing. It is Pyro that looks at the two files and determines if they are the same or not, and it promotes files that compare as different to be considered as changed and thus be included with the other marked database changes. If you use WIXOUT or WIXPDB files then fragment boundaries are considered in the comparisons, so if you specify references to things to include in your patch family/families, things that are not in any referenced fragments are ignored (by design). Look for the files you are concerned with in the WIXMST file. You should find either paths or references to cabinet-ids for both the updated and the previous versions of the files. Blair -Original Message- From: tome...@qualisystems.com [mailto:tome...@qualisystems.com] Sent: Thursday, January 26, 2012 7:19 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] How does Torch decide which files changed?! I'm creating a patch, I'm not sure that the patch includes all of my files even though I'm passing the -p flag to the torch.exe. Can someone please explain to me the logic that torch uses to determine what files are included in the patch. Thanks. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio,
[WiX-users] Install issue - wix2010.target line 761
I'm setting up a new build machine. VS2010, Wix3.5, etc. Everything the same as the old machine. (both are x64 Win7 Pro) When I try to build the installer on the new machine, I get an odd error which I don't understand. Nothing on the web seems to match it. The error isn't in my code, its on line 761 of wix2010.targets The line is Exec WorkingDirectory=$(OutDir) Command=$(ExpandedPreBuildEvent) / I haven't edited this file at all. The error I get is this: Error 3 The command %WIX%\bin\heat dir D:\Code\products\LE\bin\Debug\Help -dr HelpFolder -cg HelpComponentGroup -var var.HelpDir -srd -gg -sfrag -suid -template:fragment -out D:\Code\products\LE\Setup\help.wxs.sample exited with code 3. C:\Program Files (x86)\MSBuild\Microsoft\WiX\v3.x\wix2010.targets 761 6 Setup But the exact same code compiles fine on the old machine. Is there some setting I need to change maybe? -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Visual C++ 2010 Merge Module
That is what the Common Program Files directory was created for smile/. You use it similarly to the non-Common directory, except that components shared between simultaneously installed products live there. Then there is never any need to keep track of or even care about a COM object's installation directory. Do you build both Product A and Product B with the same (or at least similar) builds of WiX? If so, your problem as you have designed it would probably be easier to solve using WIXLIBs instead of MSMs. Create a WixLib project (instead of a module) of Product A. Even better than the registry search would be a component search to get the component's installation directory, but a registry search can be used as well (as long as you write the registry key). Place that search in the WixLib. Create two WiX-MSI projects, one for A and the other for B. Both consume (and depend on) the WixLib for A. The linker (which is not heavily involved in the the incorporation of MSM content) will be able to arbitrate the various actions needed between the different parts the installation much more easily than the binder can, and you will also avoid the issues you are seeing with trying to force the AppSearch from an MSM. Blair -Original Message- From: Joost van Zoest [mailto:jzo...@siqura.com] Sent: Wednesday, February 01, 2012 5:11 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Visual C++ 2010 Merge Module Hi Blair, Thanks for your reply. Let me explain the reason why we're using the registry search inside the MSM. We have a product containing a COM object, let's call this product A. We also have a product which is using the COM object of product A, let's call this one product B. We've made both an installer and a MSM of product A. And the installer of product B embeds the MSM of product A. Then we released product B, and later decided to change the installation directory for product A. When someone installs product B, the COM object is registered in the old path. When he installs product A afterwards, the old registration is overwritten with the new location of the product A binaries. If he uninstalls product A, the registry gets corrupted because the COM registration still points to the new location, while the binaries installed by product B are located in the old location. To overcome this problem, we wanted to let both the installer and MSM of product A write a registry key containing the install directory. When either the installer, or MSM, gets installed, it will first try to retrieve the install directory from the registry to make sure it will install the binaries to the same directory when the product is already installed. As it seems, this registry search is not working very well inside the MSM. Given our problem, does someone have an idea on how to deal with this? We also thought about stopping using MSM's, but the disadvantage of embedding the product A installer inside the product B installer is that product A is not refcounted. So when product B gets uninstalled, it cannot tell whether or not it should remove product A as well. All ideas are appreciated! Thanks! -Original Message- From: Blair [mailto:os...@live.com] Sent: Tuesday, January 31, 2012 4:38 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Visual C++ 2010 Merge Module Several action don't seem to be intended to be found in MSMs. Maybe AppSearch is one of them. Do you distribute your MSM publically? If not, I've got a couple of ideas. 1) Run a couple of SQL queries against the MSM to remove them from the two Module*Sequence tables. 2) Change from using MSMs and instead generate/consume WixLibs instead. If you do distribute MSMs publically then each idea I have has limitations. -Original Message- From: Joost van Zoest [mailto:jzo...@siqura.com] Sent: Tuesday, January 31, 2012 6:41 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Visual C++ 2010 Merge Module I've validated my MSM in Orca. At first, I got a lot of ICE33 warnings because of some COM registration logic. To rule out that this was causing my problems, I removed this registration logic and validated the MSM again. Now the validation completes, but ends with: Execution ERROR 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. I'm using Orca with the darice.cub of WIX 3.6 BETA Looking further in Orca, I saw 2 tables (ModuleInstallExecuteSequence and ModuleInstallUISequence) which both contained an action called AppSearch with a Sequence of 50. I guess the actions of these tables are moved to the InstallExecuteSequence and InstallUISequence tables when you embed this merge module into an installer. So could this be the cause of the warnings I see when I build my installer? Somewhere in my merge module I perform
Re: [WiX-users] Burn - Moving payload to Cache Directory
It seems it has been fixed on latest build. I just reproduced it on the Beta but not in 3.6.2527.0 Cheers, Romeo -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-Moving-payload-to-Cache-Directory-tp7237441p7243773.html Sent from the wix-users mailing list archive at Nabble.com. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Install issue - wix2010.target line 761
I don't know. Is the %WIX% environment variable set? I use the HarvestDirectory items instead of the PreBuildEvent property to use the harvester in 3.5 myself. -Original Message- From: Mark Sugrue [mailto:mark.sug...@gmail.com] Sent: Wednesday, February 01, 2012 8:57 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Install issue - wix2010.target line 761 I'm setting up a new build machine. VS2010, Wix3.5, etc. Everything the same as the old machine. (both are x64 Win7 Pro) When I try to build the installer on the new machine, I get an odd error which I don't understand. Nothing on the web seems to match it. The error isn't in my code, its on line 761 of wix2010.targets The line is Exec WorkingDirectory=$(OutDir) Command=$(ExpandedPreBuildEvent) / I haven't edited this file at all. The error I get is this: Error 3 The command %WIX%\bin\heat dir D:\Code\products\LE\bin\Debug\Help -dr HelpFolder -cg HelpComponentGroup -var var.HelpDir -srd -gg -sfrag -suid -template:fragment -out D:\Code\products\LE\Setup\help.wxs.sample exited with code 3. C:\Program Files (x86)\MSBuild\Microsoft\WiX\v3.x\wix2010.targets 761 6 Setup But the exact same code compiles fine on the old machine. Is there some setting I need to change maybe? -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers section for DirProp
I'm getting an install time error during IIS7 Configuration: WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers for DirProp. This is with Wix 3.5 RTM. An extract of the verbose log looks like: Action 12:37:38: WriteIIS7ConfigChanges. Installing Config Keys and Values MSI (s) (F4:74) [12:37:38:134]: Executing op: CustomActionSchedule(Action=WriteIIS7ConfigChanges,ActionType=11265,Source=BinaryData,Target=**,CustomActionData=**) MSI (s) (F4:CC) [12:37:38:137]: Invoking remote custom action. DLL: C:\Windows\Installer\MSID717.tmp, Entrypoint: WriteIIS7ConfigChanges WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers section for DirProp WriteIIS7ConfigChanges: Error 0x80070057: Failed to configure IIS DirProperties. WriteIIS7ConfigChanges: Error 0x80070057: WriteIIS7ConfigChanges Failed. CustomAction WriteIIS7ConfigChanges returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox) Action ended 12:37:41: InstallFinalize. Return value 3. The relevant source looks like: Fragment PropertyRef Id=WEBSITE_NAME / iis:WebSite Id=TargetWebSite Description=[WEBSITE_NAME] Directory=WebsiteFolder iis:WebAddress Id=AllUnassigned Port=80 IP=* / iis:WebAddress Id=AllUnassignedSsl Port=443 IP=* Secure=yes / /iis:WebSite /Fragment Fragment Property Id=XHSAlias Value=/XperienceHelpSystem / DirectoryRef Id=WebsiteFolder Component Id=CmpXHSIis Guid=SOME-GUID-HERE KeyPath=yes Win64=yes CreateFolder / iis:WebVirtualDir Id=XHSRoot Directory=WebsiteFolder Alias=[XHSAlias] WebSite=TargetWebSite iis:WebDirProperties Id=XHSDirProperties AnonymousAccess=no BasicAuthentication=yes Index=yes Read=yes WindowsAuthentication=yes / iis:WebApplication Id=XHSWebApp Name=[XHSAlias] WebAppPool=XHSAppPool / /iis:WebVirtualDir util:User Id=XHSAppPoolUser CreateUser=no Name=ApplicationPoolIdentity / iis:WebAppPool Id=XHSAppPool Name=XperienceHelpSystem Identity=other User=XHSAppPoolUser ManagedPipelineMode=integrated ManagedRuntimeVersion=v4.0 / /Component /DirectoryRef /Fragment I'm at a loss how to work around this. -- John Merryweather Cooper Build Install Engineer - ESA Jack Henry Associates, Inc.(r) Shawnee Mission, KS 66227 Office: 913-341-3434 x791011 jocoo...@jackhenry.commailto:jocoo...@jackhenry.com www.jackhenry.comhttp://www.jackhenry.com/ NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patch building with Torch, all .NET assemblies changed
We are handling this scenario via automated query against a source control repository, rather than at a binary level of the compiled output. We investigated compiled output comparison as well, and it just was not a feasible solution for us. We handled this with a service account that checks-in the version # into the notes in SVN when a build is performed on our build server. We keep our build server locked-down to contain our binding between the compiled output and the source code changes. We use standard naming conventions (project Namesp.Assem outputs Namesp.Assem.dll) to make it easy to see which .dlls have changed since release X. It's not perfect, but it works for us. The keys are locking-down the build server, using a service account, and keeping track of source-code to binary output mappings (or enforcing a naming convention to do this). We are using SVN as source control and Jenkins as our build server. Good luck! -Original Message- From: John Cooper [mailto:jocoo...@jackhenry.com] Sent: Thursday, January 26, 2012 3:34 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Patch building with Torch, all .NET assemblies changed When I was at SCX (Microsoft), we went so far as to investigate tools to compare only the code parts of an assembly--but in the end, that proved too cumbersome and unreliable, and so we just lived with the diff's between build. At ESA-JHA, a significant number of assemblies are checked into source control when they are updated using special, manual promote builds. These assemblies are thus not rebuilt except when they change--reducing the diff's in builds. But, an all-up complete rebuild is also sacrificed by this technique. There are always compromises. -- John Merryweather Cooper Build Install Engineer - ESA Jack Henry Associates, Inc.(r) Shawnee Mission, KS 66227 Office: 913-341-3434 x791011 jocoo...@jackhenry.com www.jackhenry.com -Original Message- From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] Sent: Thursday, January 26, 2012 3:14 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Patch building with Torch, all .NET assemblies changed My initial guess is that your assembly's versions are changing between builds. I'm very interested in a proposed approach to this as we have a build that results in changed versions on every build. I haven't personally investigated an approach to handle this yet. I haven't had the time yet to do it. Edwin G. Castro Software Developer - Staff Digital Channels Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com P Please consider the environment before printing this e-mail -Original Message- From: john.burak [mailto:john.bu...@telvent.com] Sent: Thursday, January 26, 2012 11:00 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Patch building with Torch, all .NET assemblies changed We recently implemented patch building using Torch/Pyro. We are keeping the old MSI and totally rebuilding a new one for Torch to diff with. The problem is that Torch sees all of our .NET assemblies as changed even though the source code only changed in a few. We did some digging and it turns out that if we recompile an assembly with the same source code, the binary result (DLL or EXE) is different from the first build. Perhaps it's putting a date stamp inside. Our guess is that Torch is doing a binary comparison and sees the file as changed. We need a patch with only the few files who's source code has changed. So the question is, how do people handle this situation? We could try to change our build process so that we don't rebuild every project the second time (let MSBuild pick just the changed ones), but then we won't get clean builds and we won't detect circular references between assemblies (developers sometimes accidentally do that). We can limit the impact by doing a non-clean build for only the patch. This may be the only option, but I wanted to get some opinions first. Maybe there is something I'm missing here. Thanks for your input! - John -- View this message in context: http://windows-installer-xml-wix- toolset.687559.n2.nabble.com/Patch-building-with-Torch-all-NET-assembl ies- changed-tp7227881p7227881.html Sent from the wix-users mailing list archive at Nabble.com. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net
Re: [WiX-users] WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers section for DirProp
Replying to myself: Commenting out the iis:WebDirProperties element results in a different error: Action 13:13:03: WriteIIS7ConfigChanges. Installing Config Keys and Values MSI (s) (60:E0) [13:13:03:168]: Executing op: CustomActionSchedule(Action=WriteIIS7ConfigChanges,ActionType=11265,Source=BinaryData,Target=**,CustomActionData=**) MSI (s) (60:B4) [13:13:03:170]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI4097.tmp, Entrypoint: WriteIIS7ConfigChanges WriteIIS7ConfigChanges: Error 0x80070057: Failed get httpErrors section WriteIIS7ConfigChanges: Error 0x80070057: Failed to configure IIS web svc ext. WriteIIS7ConfigChanges: Error 0x80070057: WriteIIS7ConfigChanges Failed. CustomAction WriteIIS7ConfigChanges returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox) Action ended 13:13:06: InstallFinalize. Return value 3. -- John M. Cooper -Original Message- From: John Cooper Sent: Wednesday, February 01, 2012 12:45 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers section for DirProp I'm getting an install time error during IIS7 Configuration: WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers for DirProp. This is with Wix 3.5 RTM. An extract of the verbose log looks like: Action 12:37:38: WriteIIS7ConfigChanges. Installing Config Keys and Values MSI (s) (F4:74) [12:37:38:134]: Executing op: CustomActionSchedule(Action=WriteIIS7ConfigChanges,ActionType=11265,Source=BinaryData,Target=**,CustomActionData=**) MSI (s) (F4:CC) [12:37:38:137]: Invoking remote custom action. DLL: C:\Windows\Installer\MSID717.tmp, Entrypoint: WriteIIS7ConfigChanges WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers section for DirProp WriteIIS7ConfigChanges: Error 0x80070057: Failed to configure IIS DirProperties. WriteIIS7ConfigChanges: Error 0x80070057: WriteIIS7ConfigChanges Failed. CustomAction WriteIIS7ConfigChanges returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox) Action ended 12:37:41: InstallFinalize. Return value 3. The relevant source looks like: Fragment PropertyRef Id=WEBSITE_NAME / iis:WebSite Id=TargetWebSite Description=[WEBSITE_NAME] Directory=WebsiteFolder iis:WebAddress Id=AllUnassigned Port=80 IP=* / iis:WebAddress Id=AllUnassignedSsl Port=443 IP=* Secure=yes / /iis:WebSite /Fragment Fragment Property Id=XHSAlias Value=/XperienceHelpSystem / DirectoryRef Id=WebsiteFolder Component Id=CmpXHSIis Guid=SOME-GUID-HERE KeyPath=yes Win64=yes CreateFolder / iis:WebVirtualDir Id=XHSRoot Directory=WebsiteFolder Alias=[XHSAlias] WebSite=TargetWebSite iis:WebDirProperties Id=XHSDirProperties AnonymousAccess=no BasicAuthentication=yes Index=yes Read=yes WindowsAuthentication=yes / iis:WebApplication Id=XHSWebApp Name=[XHSAlias] WebAppPool=XHSAppPool / /iis:WebVirtualDir util:User Id=XHSAppPoolUser CreateUser=no Name=ApplicationPoolIdentity / iis:WebAppPool Id=XHSAppPool Name=XperienceHelpSystem Identity=other User=XHSAppPoolUser ManagedPipelineMode=integrated ManagedRuntimeVersion=v4.0 / /Component /DirectoryRef /Fragment I'm at a loss how to work around this. -- John Merryweather Cooper Build Install Engineer - ESA Jack Henry Associates, Inc.(r) Shawnee Mission, KS 66227 Office: 913-341-3434 x791011 jocoo...@jackhenry.commailto:jocoo...@jackhenry.com www.jackhenry.comhttp://www.jackhenry.com/ NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving,
Re: [WiX-users] Burn - Moving payload to Cache Directory
Yes, that does sound like a bug that was fixed post-Beta. On Wed, Feb 1, 2012 at 9:46 AM, Romeo S. dfox.mxyzp...@gmail.com wrote: It seems it has been fixed on latest build. I just reproduced it on the Beta but not in 3.6.2527.0 Cheers, Romeo -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-Moving-payload-to-Cache-Directory-tp7237441p7243773.html Sent from the wix-users mailing list archive at Nabble.com. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Bootstrapper logo in wrong location
UI design changed, documentation was not updated. Bug in the documentation. Thanks. On Wed, Feb 1, 2012 at 3:47 AM, Kyle Lee klee...@gmail.com wrote: Hi, The WIX manual says, The WiX Standard Bootstrapper Application displays a generic logo in the bottom left corner of the user interface. WixVariable Id=WixStdbaLogo Value=path\to\customlogo.png / I used this last year (the version was 3.6.1608.0), and yes, the log showed up in the bottom left corner of the dialog. Now I am using v3.6.2221.0 and it doesn't behave that way any more. The logo is always in the top left corner and it only displays the square shape, so that if my image is rectangle, it is clipped. I strongly believe this is a regression. If not, can anyone point me what I am missing? TIA. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers section for DirProp
This sounds very much like a bug that was fixed in WiX v3.6... On Wed, Feb 1, 2012 at 11:17 AM, John Cooper jocoo...@jackhenry.com wrote: Replying to myself: Commenting out the iis:WebDirProperties element results in a different error: Action 13:13:03: WriteIIS7ConfigChanges. Installing Config Keys and Values MSI (s) (60:E0) [13:13:03:168]: Executing op: CustomActionSchedule(Action=WriteIIS7ConfigChanges,ActionType=11265,Source=BinaryData,Target=**,CustomActionData=**) MSI (s) (60:B4) [13:13:03:170]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI4097.tmp, Entrypoint: WriteIIS7ConfigChanges WriteIIS7ConfigChanges: Error 0x80070057: Failed get httpErrors section WriteIIS7ConfigChanges: Error 0x80070057: Failed to configure IIS web svc ext. WriteIIS7ConfigChanges: Error 0x80070057: WriteIIS7ConfigChanges Failed. CustomAction WriteIIS7ConfigChanges returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox) Action ended 13:13:06: InstallFinalize. Return value 3. -- John M. Cooper -Original Message- From: John Cooper Sent: Wednesday, February 01, 2012 12:45 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers section for DirProp I'm getting an install time error during IIS7 Configuration: WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers for DirProp. This is with Wix 3.5 RTM. An extract of the verbose log looks like: Action 12:37:38: WriteIIS7ConfigChanges. Installing Config Keys and Values MSI (s) (F4:74) [12:37:38:134]: Executing op: CustomActionSchedule(Action=WriteIIS7ConfigChanges,ActionType=11265,Source=BinaryData,Target=**,CustomActionData=**) MSI (s) (F4:CC) [12:37:38:137]: Invoking remote custom action. DLL: C:\Windows\Installer\MSID717.tmp, Entrypoint: WriteIIS7ConfigChanges WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers section for DirProp WriteIIS7ConfigChanges: Error 0x80070057: Failed to configure IIS DirProperties. WriteIIS7ConfigChanges: Error 0x80070057: WriteIIS7ConfigChanges Failed. CustomAction WriteIIS7ConfigChanges returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox) Action ended 12:37:41: InstallFinalize. Return value 3. The relevant source looks like: Fragment PropertyRef Id=WEBSITE_NAME / iis:WebSite Id=TargetWebSite Description=[WEBSITE_NAME] Directory=WebsiteFolder iis:WebAddress Id=AllUnassigned Port=80 IP=* / iis:WebAddress Id=AllUnassignedSsl Port=443 IP=* Secure=yes / /iis:WebSite /Fragment Fragment Property Id=XHSAlias Value=/XperienceHelpSystem / DirectoryRef Id=WebsiteFolder Component Id=CmpXHSIis Guid=SOME-GUID-HERE KeyPath=yes Win64=yes CreateFolder / iis:WebVirtualDir Id=XHSRoot Directory=WebsiteFolder Alias=[XHSAlias] WebSite=TargetWebSite iis:WebDirProperties Id=XHSDirProperties AnonymousAccess=no BasicAuthentication=yes Index=yes Read=yes WindowsAuthentication=yes / iis:WebApplication Id=XHSWebApp Name=[XHSAlias] WebAppPool=XHSAppPool / /iis:WebVirtualDir util:User Id=XHSAppPoolUser CreateUser=no Name=ApplicationPoolIdentity / iis:WebAppPool Id=XHSAppPool Name=XperienceHelpSystem Identity=other User=XHSAppPoolUser ManagedPipelineMode=integrated ManagedRuntimeVersion=v4.0 / /Component /DirectoryRef /Fragment I'm at a loss how to work around this. -- John Merryweather Cooper Build Install Engineer - ESA Jack Henry Associates, Inc.(r) Shawnee Mission, KS 66227 Office: 913-341-3434 x791011 jocoo...@jackhenry.commailto:jocoo...@jackhenry.com www.jackhenry.comhttp://www.jackhenry.com/ NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the
Re: [WiX-users] WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers section for DirProp
Wonderful. Is there an assembly I can take from the Wix 3.6 build and replace in the 3.5? I've got to stay with 3.5 until 3.6 goes RTM. -- John M. Cooper -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Wednesday, February 01, 2012 2:25 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers section for DirProp This sounds very much like a bug that was fixed in WiX v3.6... On Wed, Feb 1, 2012 at 11:17 AM, John Cooper jocoo...@jackhenry.com wrote: Replying to myself: Commenting out the iis:WebDirProperties element results in a different error: Action 13:13:03: WriteIIS7ConfigChanges. Installing Config Keys and Values MSI (s) (60:E0) [13:13:03:168]: Executing op: CustomActionSchedule(Action=WriteIIS7ConfigChanges,ActionType=11265,So urce=BinaryData,Target=**,CustomActionData=**) MSI (s) (60:B4) [13:13:03:170]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI4097.tmp, Entrypoint: WriteIIS7ConfigChanges WriteIIS7ConfigChanges: Error 0x80070057: Failed get httpErrors section WriteIIS7ConfigChanges: Error 0x80070057: Failed to configure IIS web svc ext. WriteIIS7ConfigChanges: Error 0x80070057: WriteIIS7ConfigChanges Failed. CustomAction WriteIIS7ConfigChanges returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox) Action ended 13:13:06: InstallFinalize. Return value 3. -- John M. Cooper -Original Message- From: John Cooper Sent: Wednesday, February 01, 2012 12:45 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers section for DirProp I'm getting an install time error during IIS7 Configuration: WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers for DirProp. This is with Wix 3.5 RTM. An extract of the verbose log looks like: Action 12:37:38: WriteIIS7ConfigChanges. Installing Config Keys and Values MSI (s) (F4:74) [12:37:38:134]: Executing op: CustomActionSchedule(Action=WriteIIS7ConfigChanges,ActionType=11265,So urce=BinaryData,Target=**,CustomActionData=**) MSI (s) (F4:CC) [12:37:38:137]: Invoking remote custom action. DLL: C:\Windows\Installer\MSID717.tmp, Entrypoint: WriteIIS7ConfigChanges WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers section for DirProp WriteIIS7ConfigChanges: Error 0x80070057: Failed to configure IIS DirProperties. WriteIIS7ConfigChanges: Error 0x80070057: WriteIIS7ConfigChanges Failed. CustomAction WriteIIS7ConfigChanges returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox) Action ended 12:37:41: InstallFinalize. Return value 3. The relevant source looks like: Fragment PropertyRef Id=WEBSITE_NAME / iis:WebSite Id=TargetWebSite Description=[WEBSITE_NAME] Directory=WebsiteFolder iis:WebAddress Id=AllUnassigned Port=80 IP=* / iis:WebAddress Id=AllUnassignedSsl Port=443 IP=* Secure=yes / /iis:WebSite /Fragment Fragment Property Id=XHSAlias Value=/XperienceHelpSystem / DirectoryRef Id=WebsiteFolder Component Id=CmpXHSIis Guid=SOME-GUID-HERE KeyPath=yes Win64=yes CreateFolder / iis:WebVirtualDir Id=XHSRoot Directory=WebsiteFolder Alias=[XHSAlias] WebSite=TargetWebSite iis:WebDirProperties Id=XHSDirProperties AnonymousAccess=no BasicAuthentication=yes Index=yes Read=yes WindowsAuthentication=yes / iis:WebApplication Id=XHSWebApp Name=[XHSAlias] WebAppPool=XHSAppPool / /iis:WebVirtualDir util:User Id=XHSAppPoolUser CreateUser=no Name=ApplicationPoolIdentity / iis:WebAppPool Id=XHSAppPool Name=XperienceHelpSystem Identity=other User=XHSAppPoolUser ManagedPipelineMode=integrated ManagedRuntimeVersion=v4.0 / /Component /DirectoryRef /Fragment I'm at a loss how to work around this. -- John Merryweather Cooper Build Install Engineer - ESA Jack Henry Associates, Inc.(r) Shawnee Mission, KS 66227 Office: 913-341-3434 x791011 jocoo...@jackhenry.commailto:jocoo...@jackhenry.com www.jackhenry.comhttp://www.jackhenry.com/ NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for
[WiX-users] Negative LastSequence number for pyro-generated MSP
Hi all, We're using Torch/Pyro to create MSP patches for an installer originally from InstallShield (haven't converted it to Wix yet) and we're ending up with a negative number for the patch CAB's LastSequence number. This seems to cause a 2920 source directory not specified error during install. This doesn't happen for the installers that we've already converted to Wix. - Wix 3.5 - MSI schema 301 (according to Orca) - Windows Installer 5.0 Can anyone shed light on how that LastSequence number is being calculated, or offer suggestions? Thanks! - John Burak -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Negative-LastSequence-number-for-pyro-generated-MSP-tp7244318p7244318.html Sent from the wix-users mailing list archive at Nabble.com. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers section for DirProp
Hmm. Rebuilt with the latest Wix 3.6, and I still get: Action 15:10:21: WriteIIS7ConfigChanges. Installing Config Keys and Values MSI (s) (44:24) [15:10:21:915]: Executing op: CustomActionSchedule(Action=WriteIIS7ConfigChanges,ActionType=11265,Source=BinaryData,Target=**,CustomActionData=**) MSI (s) (44:20) [15:10:21:945]: Invoking remote custom action. DLL: C:\Windows\Installer\MSIA97A.tmp, Entrypoint: WriteIIS7ConfigChanges WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers section for DirProp WriteIIS7ConfigChanges: Error 0x80070057: Failed to configure IIS DirProperties. WriteIIS7ConfigChanges: Error 0x80070057: WriteIIS7ConfigChanges Failed. CustomAction WriteIIS7ConfigChanges returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox) Action ended 15:10:22: InstallFinalize. Return value 3. -- John M. Cooper -Original Message- From: John Cooper Sent: Wednesday, February 01, 2012 2:36 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers section for DirProp Wonderful. Is there an assembly I can take from the Wix 3.6 build and replace in the 3.5? I've got to stay with 3.5 until 3.6 goes RTM. -- John M. Cooper -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Wednesday, February 01, 2012 2:25 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers section for DirProp This sounds very much like a bug that was fixed in WiX v3.6... On Wed, Feb 1, 2012 at 11:17 AM, John Cooper jocoo...@jackhenry.com wrote: Replying to myself: Commenting out the iis:WebDirProperties element results in a different error: Action 13:13:03: WriteIIS7ConfigChanges. Installing Config Keys and Values MSI (s) (60:E0) [13:13:03:168]: Executing op: CustomActionSchedule(Action=WriteIIS7ConfigChanges,ActionType=11265,So urce=BinaryData,Target=**,CustomActionData=**) MSI (s) (60:B4) [13:13:03:170]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI4097.tmp, Entrypoint: WriteIIS7ConfigChanges WriteIIS7ConfigChanges: Error 0x80070057: Failed get httpErrors section WriteIIS7ConfigChanges: Error 0x80070057: Failed to configure IIS web svc ext. WriteIIS7ConfigChanges: Error 0x80070057: WriteIIS7ConfigChanges Failed. CustomAction WriteIIS7ConfigChanges returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox) Action ended 13:13:06: InstallFinalize. Return value 3. -- John M. Cooper -Original Message- From: John Cooper Sent: Wednesday, February 01, 2012 12:45 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers section for DirProp I'm getting an install time error during IIS7 Configuration: WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers for DirProp. This is with Wix 3.5 RTM. An extract of the verbose log looks like: Action 12:37:38: WriteIIS7ConfigChanges. Installing Config Keys and Values MSI (s) (F4:74) [12:37:38:134]: Executing op: CustomActionSchedule(Action=WriteIIS7ConfigChanges,ActionType=11265,So urce=BinaryData,Target=**,CustomActionData=**) MSI (s) (F4:CC) [12:37:38:137]: Invoking remote custom action. DLL: C:\Windows\Installer\MSID717.tmp, Entrypoint: WriteIIS7ConfigChanges WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers section for DirProp WriteIIS7ConfigChanges: Error 0x80070057: Failed to configure IIS DirProperties. WriteIIS7ConfigChanges: Error 0x80070057: WriteIIS7ConfigChanges Failed. CustomAction WriteIIS7ConfigChanges returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox) Action ended 12:37:41: InstallFinalize. Return value 3. The relevant source looks like: Fragment PropertyRef Id=WEBSITE_NAME / iis:WebSite Id=TargetWebSite Description=[WEBSITE_NAME] Directory=WebsiteFolder iis:WebAddress Id=AllUnassigned Port=80 IP=* / iis:WebAddress Id=AllUnassignedSsl Port=443 IP=* Secure=yes / /iis:WebSite /Fragment Fragment Property Id=XHSAlias Value=/XperienceHelpSystem / DirectoryRef Id=WebsiteFolder Component Id=CmpXHSIis Guid=SOME-GUID-HERE KeyPath=yes Win64=yes CreateFolder / iis:WebVirtualDir Id=XHSRoot Directory=WebsiteFolder Alias=[XHSAlias] WebSite=TargetWebSite iis:WebDirProperties Id=XHSDirProperties AnonymousAccess=no BasicAuthentication=yes Index=yes Read=yes WindowsAuthentication=yes / iis:WebApplication Id=XHSWebApp Name=[XHSAlias] WebAppPool=XHSAppPool / /iis:WebVirtualDir util:User Id=XHSAppPoolUser CreateUser=no Name=ApplicationPoolIdentity /
[WiX-users] patch install error 2247 1636 while adding a new component to the patch.
I am getting below error when trying to install a patch that has added a new
component (2 files). When looked from orca it appears to add the 2 files just
fine. Also if I add the new files to existing component instead of adding a new
component, it seems to be installing fine.
Additional information:
1. I am using WIX 3 toolset to generate patch. Original MSI and the
updated one is built using WIX 2.0
2. We have another MSI that and we have added components via it's patch,
that one seems to be working just fine. It's just this MSI that has the below
issue.
3. I also tried using WIX 3.5 to generate patch and that too is failing
with same error.
What is the problem here and how do I fix it? Do I need to open a bug for this
if this isn't already a known issue? Let me know if you need more info on this.
Patch Install error:
=== Verbose logging started: 2/1/2012 13:56:08 Build type: SHIP UNICODE
5.00.7601.00 Calling process: C:\Windows\System32\msiexec.exe ===
MSI (c) (84:64) [13:56:08:703]: Font created. Charset: Req=0, Ret=0, Font:
Req=MS Shell Dlg, Ret=MS Shell Dlg
MSI (c) (84:64) [13:56:08:704]: Font created. Charset: Req=0, Ret=0, Font:
Req=MS Shell Dlg, Ret=MS Shell Dlg
MSI (c) (84:70) [13:56:08:737]: Resetting cached policy values
MSI (c) (84:70) [13:56:08:737]: Machine policy value 'Debug' is 0
MSI (c) (84:70) [13:56:08:737]: *** RunEngine:
*** Product: {PRODUCT-CODE-GUID}
*** Action:
*** CommandLine: **
MSI (c) (84:70) [13:56:08:739]: Machine policy value 'DisableUserInstalls' is 0
MSI (c) (84:70) [13:56:08:845]: Cloaking enabled.
MSI (c) (84:70) [13:56:08:845]: Attempting to enable all disabled privileges
before calling Install on Server
MSI (c) (84:70) [13:56:08:857]: End dialog not enabled
MSI (c) (84:70) [13:56:08:858]: Original package ==
C:\Windows\Installer\241bb396.msi
MSI (c) (84:70) [13:56:08:858]: Package we're running from ==
C:\Windows\Installer\241bb396.msi
MSI (c) (84:70) [13:56:08:861]: APPCOMPAT: Uninstall Flags override found.
MSI (c) (84:70) [13:56:08:861]: APPCOMPAT: Uninstall VersionNT override found.
MSI (c) (84:70) [13:56:08:861]: APPCOMPAT: Uninstall ServicePackLevel override
found.
MSI (c) (84:70) [13:56:08:862]: APPCOMPAT: looking for appcompat database entry
with ProductCode '{PRODUCT-CODE-GUID}'.
MSI (c) (84:70) [13:56:08:862]: APPCOMPAT: no matching ProductCode found in
database.
MSI (c) (84:70) [13:56:08:872]: MSCOREE not loaded loading copy from system32
MSI (c) (84:70) [13:56:08:880]: Original patch == C:\acs\KB1234567-x64-ABC.msp
MSI (c) (84:70) [13:56:08:880]: Patch we're running from ==
C:\acs\KB1234567-x64-ABC.msp
MSI (c) (84:70) [13:56:08:881]: SOFTWARE RESTRICTION POLICY: Verifying patch
-- 'C:\acs\KB1234567-x64-ABC.msp' against software restriction policy
MSI (c) (84:70) [13:56:08:881]: Note: 1: 2262 2: DigitalSignature 3: -2147287038
MSI (c) (84:70) [13:56:08:881]: SOFTWARE RESTRICTION POLICY:
C:\acs\KB1234567-x64-ABC.msp is not digitally signed
MSI (c) (84:70) [13:56:08:883]: SOFTWARE RESTRICTION POLICY:
C:\acs\KB1234567-x64-ABC.msp is permitted to run at the 'unrestricted'
authorization level.
MSI (c) (84:70) [13:56:08:884]: SequencePatches starts. Product code:
{PRODUCT-CODE-GUID}, Product version: 6.1.7221.0, Upgrade code:
{UPGRADE-CODE-GUID}, Product language 1033
MSI (c) (84:70) [13:56:08:884]: PATCH SEQUENCER: verifying the applicability of
QFE patch C:\acs\KB1234567-x64-ABC.msp against product code:
{PRODUCT-CODE-GUID}, product version: 6.1.7221.0, product language 1033 and
upgrade code: {UPGRADE-CODE-GUID}
MSI (c) (84:70) [13:56:08:885]: PATCH SEQUENCER: QFE patch
C:\acs\KB1234567-x64-ABC.msp is applicable.
MSI (c) (84:70) [13:56:08:887]: SequencePatches returns success.
MSI (c) (84:70) [13:56:08:887]: Final Patch Application Order:
MSI (c) (84:70) [13:56:08:887]: {E0B517BB-1A9E-4FDF-9D87-95BD35F21BE3} -
C:\acs\KB1234567-x64-ABC.msp
MSI (c) (84:70) [13:56:08:887]: Machine policy value 'DisablePatch' is 0
MSI (c) (84:70) [13:56:08:887]: Machine policy value 'AllowLockdownPatch' is 0
MSI (c) (84:70) [13:56:08:887]: Machine policy value 'DisableLUAPatching' is 0
MSI (c) (84:70) [13:56:08:887]: Machine policy value 'DisableFlyWeightPatching'
is 0
MSI (c) (84:70) [13:56:08:887]: Turning off patch optimization.
{E0B517BB-1A9E-4FDF-9D87-95BD35F21BE3} patch is not authored to support it.
MSI (c) (84:70) [13:56:08:887]: Looking for patch transform: RTM.1
MSI (c) (84:70) [13:56:08:887]: Note: 1: 2262 2: _Tables 3: -2147287038
MSI (c) (84:70) [13:56:08:887]: Note: 1: 2262 2: _Columns 3: -2147287038
MSI (c) (84:70) [13:56:08:888]: Note: 1: 2262 2: Feature 3: -2147287038
MSI (c) (84:70) [13:56:08:888]: Note: 1: 2262 2: Error 3: -2147287038
MSI (c) (84:70) [13:56:08:888]: Note: 1: 2262 2: Binary 3: -2147287038
MSI (c) (84:70) [13:56:08:888]: Note: 1: 2247 2: 3: 4:
DEBUG: Error 2247: Database: Transform stream read/write failure.
1: 2247 2: 3:
Re: [WiX-users] Install issue - wix2010.target line 761
Thanks for the reply. How do I set %WIX%? And what should I set it to? Previously, I just installed WiX and compile worked fine. What might have changed? On Wed, Feb 1, 2012 at 18:05, Blair os...@live.com wrote: I don't know. Is the %WIX% environment variable set? I use the HarvestDirectory items instead of the PreBuildEvent property to use the harvester in 3.5 myself. -Original Message- From: Mark Sugrue [mailto:mark.sug...@gmail.com] Sent: Wednesday, February 01, 2012 8:57 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Install issue - wix2010.target line 761 I'm setting up a new build machine. VS2010, Wix3.5, etc. Everything the same as the old machine. (both are x64 Win7 Pro) When I try to build the installer on the new machine, I get an odd error which I don't understand. Nothing on the web seems to match it. The error isn't in my code, its on line 761 of wix2010.targets The line is Exec WorkingDirectory=$(OutDir) Command=$(ExpandedPreBuildEvent) / I haven't edited this file at all. The error I get is this: Error 3 The command %WIX%\bin\heat dir D:\Code\products\LE\bin\Debug\Help -dr HelpFolder -cg HelpComponentGroup -var var.HelpDir -srd -gg -sfrag -suid -template:fragment -out D:\Code\products\LE\Setup\help.wxs.sample exited with code 3. C:\Program Files (x86)\MSBuild\Microsoft\WiX\v3.x\wix2010.targets 761 6 Setup But the exact same code compiles fine on the old machine. Is there some setting I need to change maybe? -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Installing multiple applications
Hi, I'm updating my install process and I'd like to hear suggestions on improving my install process. My apps normally consist of a web site and a windows service. The apps and installers are for in-house use only. In the past, I've modified the install UI to allow to separate install locations for the web site and windows service. I think I did it this way because that's how we used to manually install apps. Now, I'm re-visiting this decision and I'd like to fix two install related issues: 1. Have one install location for the application. 2. Move common files to a Common location. Addressing #1 is fairly simple. Use one install location and use subfolders for the different components: [Install Directory] [bin] -- application DLLs [Web Site] -- Web Site files [Windows Service] -- Windows Service files Both the Web Site's and Windows Service's DLLs are in the bin folder. This introduces a new problem: How do the .NET apps find the DLLs? I used SysInternals junction.exe to create a junction to the bin folder in both the Web Site and Windows Services folders. In the config files of both apps, I use a runtime-probing specification to tell the apps to look for the DLLs in a bin subfolder. So, I end up with: [Install Directory] [bin] -- application DLLs [Web Site] -- Web Site files [bin] -- Junction pointing back to top level bin folder [Windows Service] -- Windows Service files [bin] -- Junction pointing back to top level bin folder This seems to work nicely. I'm not particularly fond of calling junction.exe at the end of my install but it works. I'd rather have a DLL call. Since the DLL could be included as a binary. I've been searching around for common solutions to this install problem but I haven't seen it addressed. I'm wondering if there is a better solution? I looked at using codebase but didn't like having to specify specific DLL information. And I think it would be inappropriate to use the GAC as the DLLs are for a specific app (rather than DLLs that could be used by any app). Thanks, Chris McKinnon The information contained in this e-mail is confidential and may contain privileged information. It is intended only for the person or persons named above. If you are not an intended recipient of this e-mail please be advised that any distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify us by return e-mail and delete all copies of the e-mail and any attachments. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers section for DirProp
That's what I was going to suggest first. Can you open a bug to track the issue? On Wed, Feb 1, 2012 at 1:12 PM, John Cooper jocoo...@jackhenry.com wrote: Hmm. Rebuilt with the latest Wix 3.6, and I still get: Action 15:10:21: WriteIIS7ConfigChanges. Installing Config Keys and Values MSI (s) (44:24) [15:10:21:915]: Executing op: CustomActionSchedule(Action=WriteIIS7ConfigChanges,ActionType=11265,Source=BinaryData,Target=**,CustomActionData=**) MSI (s) (44:20) [15:10:21:945]: Invoking remote custom action. DLL: C:\Windows\Installer\MSIA97A.tmp, Entrypoint: WriteIIS7ConfigChanges WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers section for DirProp WriteIIS7ConfigChanges: Error 0x80070057: Failed to configure IIS DirProperties. WriteIIS7ConfigChanges: Error 0x80070057: WriteIIS7ConfigChanges Failed. CustomAction WriteIIS7ConfigChanges returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox) Action ended 15:10:22: InstallFinalize. Return value 3. -- John M. Cooper -Original Message- From: John Cooper Sent: Wednesday, February 01, 2012 2:36 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers section for DirProp Wonderful. Is there an assembly I can take from the Wix 3.6 build and replace in the 3.5? I've got to stay with 3.5 until 3.6 goes RTM. -- John M. Cooper -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Wednesday, February 01, 2012 2:25 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers section for DirProp This sounds very much like a bug that was fixed in WiX v3.6... On Wed, Feb 1, 2012 at 11:17 AM, John Cooper jocoo...@jackhenry.com wrote: Replying to myself: Commenting out the iis:WebDirProperties element results in a different error: Action 13:13:03: WriteIIS7ConfigChanges. Installing Config Keys and Values MSI (s) (60:E0) [13:13:03:168]: Executing op: CustomActionSchedule(Action=WriteIIS7ConfigChanges,ActionType=11265,So urce=BinaryData,Target=**,CustomActionData=**) MSI (s) (60:B4) [13:13:03:170]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI4097.tmp, Entrypoint: WriteIIS7ConfigChanges WriteIIS7ConfigChanges: Error 0x80070057: Failed get httpErrors section WriteIIS7ConfigChanges: Error 0x80070057: Failed to configure IIS web svc ext. WriteIIS7ConfigChanges: Error 0x80070057: WriteIIS7ConfigChanges Failed. CustomAction WriteIIS7ConfigChanges returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox) Action ended 13:13:06: InstallFinalize. Return value 3. -- John M. Cooper -Original Message- From: John Cooper Sent: Wednesday, February 01, 2012 12:45 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers section for DirProp I'm getting an install time error during IIS7 Configuration: WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers for DirProp. This is with Wix 3.5 RTM. An extract of the verbose log looks like: Action 12:37:38: WriteIIS7ConfigChanges. Installing Config Keys and Values MSI (s) (F4:74) [12:37:38:134]: Executing op: CustomActionSchedule(Action=WriteIIS7ConfigChanges,ActionType=11265,So urce=BinaryData,Target=**,CustomActionData=**) MSI (s) (F4:CC) [12:37:38:137]: Invoking remote custom action. DLL: C:\Windows\Installer\MSID717.tmp, Entrypoint: WriteIIS7ConfigChanges WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers section for DirProp WriteIIS7ConfigChanges: Error 0x80070057: Failed to configure IIS DirProperties. WriteIIS7ConfigChanges: Error 0x80070057: WriteIIS7ConfigChanges Failed. CustomAction WriteIIS7ConfigChanges returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox) Action ended 12:37:41: InstallFinalize. Return value 3. The relevant source looks like: Fragment PropertyRef Id=WEBSITE_NAME / iis:WebSite Id=TargetWebSite Description=[WEBSITE_NAME] Directory=WebsiteFolder iis:WebAddress Id=AllUnassigned Port=80 IP=* / iis:WebAddress Id=AllUnassignedSsl Port=443 IP=* Secure=yes / /iis:WebSite /Fragment Fragment Property Id=XHSAlias Value=/XperienceHelpSystem / DirectoryRef Id=WebsiteFolder Component Id=CmpXHSIis Guid=SOME-GUID-HERE KeyPath=yes Win64=yes CreateFolder / iis:WebVirtualDir Id=XHSRoot Directory=WebsiteFolder Alias=[XHSAlias] WebSite=TargetWebSite iis:WebDirProperties Id=XHSDirProperties AnonymousAccess=no BasicAuthentication=yes
Re: [WiX-users] Installing multiple applications
What about duplicating the files? I know that sounds a bit crazy but if you're okay taking a bit more size on disk when installed, the WiX toolset's smartcabbing will only carry the files once in the package. On Wed, Feb 1, 2012 at 3:47 PM, McKinnon, Chris cmckin...@atb.com wrote: Hi, I'm updating my install process and I'd like to hear suggestions on improving my install process. My apps normally consist of a web site and a windows service. The apps and installers are for in-house use only. In the past, I've modified the install UI to allow to separate install locations for the web site and windows service. I think I did it this way because that's how we used to manually install apps. Now, I'm re-visiting this decision and I'd like to fix two install related issues: 1. Have one install location for the application. 2. Move common files to a Common location. Addressing #1 is fairly simple. Use one install location and use subfolders for the different components: [Install Directory] [bin] -- application DLLs [Web Site] -- Web Site files [Windows Service] -- Windows Service files Both the Web Site's and Windows Service's DLLs are in the bin folder. This introduces a new problem: How do the .NET apps find the DLLs? I used SysInternals junction.exe to create a junction to the bin folder in both the Web Site and Windows Services folders. In the config files of both apps, I use a runtime-probing specification to tell the apps to look for the DLLs in a bin subfolder. So, I end up with: [Install Directory] [bin] -- application DLLs [Web Site] -- Web Site files [bin] -- Junction pointing back to top level bin folder [Windows Service] -- Windows Service files [bin] -- Junction pointing back to top level bin folder This seems to work nicely. I'm not particularly fond of calling junction.exe at the end of my install but it works. I'd rather have a DLL call. Since the DLL could be included as a binary. I've been searching around for common solutions to this install problem but I haven't seen it addressed. I'm wondering if there is a better solution? I looked at using codebase but didn't like having to specify specific DLL information. And I think it would be inappropriate to use the GAC as the DLLs are for a specific app (rather than DLLs that could be used by any app). Thanks, Chris McKinnon The information contained in this e-mail is confidential and may contain privileged information. It is intended only for the person or persons named above. If you are not an intended recipient of this e-mail please be advised that any distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify us by return e-mail and delete all copies of the e-mail and any attachments. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] unable to start a service through MSI
Hi, I am currently trying to get my service started as a part of MSI install and am unable to do so. In the event viewer, I see the following error: Product: Myservice Cache Service -- Error 1920. Service ' Myservice ' (Myservice) failed to start. Verify that you have sufficient privileges to start system services. However, I am logged in as admin. Also, if I simply install the service and start the service manually, I am able to do that. I appreciate any input to help me figure out what I might be doing wrong or missing. One additional data about my service is: I am trying to install the service under account NT AUTHORITY\NETWORK SERVICE (Property SERVICEACCOUNT = 'NT AUTHORITY\NETWORK SERVICE' below) Thanks a lot for your help. Rajesh PS: Here is a snippet from my WXS file: Directory Id='TARGETDIR' Name='SourceDir' Component Id=' MyserviceCacheComponent' Guid='my guid' !-- The files to be installed -- File Id='Myservice.exe' Name='Myservice.exe' DiskId='1' Source='$(var.INETROOT)\target\$(var.BUILDTYPE)\$(var.BUILDTARGET)\Myservice.exe' / File Id='Myservice.pdb' Name='Myservice.pdb' DiskId='1' Source='$(var.INETROOT)\target\$(var.BUILDTYPE)\$(var.BUILDTARGET)\Myservice.pdb' / File Id='MyservicePf.dll' Name='MyservicePf.dll' SelfRegCost='1' DiskId='1' Source='$(var.INETROOT)\target\$(var.BUILDTYPE)\$(var.BUILDTARGET)\MyservicePf.dll' / File Id='MyservicePf.pdb' Name='MyservicePf.pdb' DiskId='1' Source='$(var.INETROOT)\target\$(var.BUILDTYPE)\$(var.BUILDTARGET)\MyservicePf.pdb' / RemoveFile Id='REM_MYSERVICE_XML' Name='Myservice_Cache_Service.xml' On='uninstall'/ ServiceControl Id='Myservice_Cache_Service' Name='Myservice' Start='install' Stop='both' Remove='both' Wait='no'/ ServiceInstall Id='Myservice_Cache_Service' Name='Myservice' DisplayName='Myservice' Type='ownProcess' Start='auto' ErrorControl='normal' Account='[SERVICEACCOUNT]' Description='Myservice Cache Service'/ ... /Component /Directory -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] unable to start a service through MSI
The error message is pretty generic, the service can't start for almost any reason. We have MSIs that run in full dialog mode so there is a dialog popped when the service fails to start with the error you are seeing in the eventlog, with a retry and cancel options. When you get this dialog go to the Services control panel and manual start the service, you will often get a more meaningful error. If you don't get the dialog with the error, change your MSI so it does not try start the service, and debug the startup when the install is finished Michael -Original Message- From: Rajesh Khetan [mailto:rajesh.khe...@microsoft.com] Sent: Thursday, 2 February 2012 10:29 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] unable to start a service through MSI Hi, I am currently trying to get my service started as a part of MSI install and am unable to do so. In the event viewer, I see the following error: Product: Myservice Cache Service -- Error 1920. Service ' Myservice ' (Myservice) failed to start. Verify that you have sufficient privileges to start system services. However, I am logged in as admin. Also, if I simply install the service and start the service manually, I am able to do that. I appreciate any input to help me figure out what I might be doing wrong or missing. One additional data about my service is: I am trying to install the service under account NT AUTHORITY\NETWORK SERVICE (Property SERVICEACCOUNT = 'NT AUTHORITY\NETWORK SERVICE' below) Thanks a lot for your help. Rajesh PS: Here is a snippet from my WXS file: Directory Id='TARGETDIR' Name='SourceDir' Component Id=' MyserviceCacheComponent' Guid='my guid' !-- The files to be installed -- File Id='Myservice.exe' Name='Myservice.exe' DiskId='1' Source='$(var.INETROOT)\target\$(var.BUILDTYPE)\$(var.BUILDTARGET)\Myservice.exe' / File Id='Myservice.pdb' Name='Myservice.pdb' DiskId='1' Source='$(var.INETROOT)\target\$(var.BUILDTYPE)\$(var.BUILDTARGET)\Myservice.pdb' / File Id='MyservicePf.dll' Name='MyservicePf.dll' SelfRegCost='1' DiskId='1' Source='$(var.INETROOT)\target\$(var.BUILDTYPE)\$(var.BUILDTARGET)\MyservicePf.dll' / File Id='MyservicePf.pdb' Name='MyservicePf.pdb' DiskId='1' Source='$(var.INETROOT)\target\$(var.BUILDTYPE)\$(var.BUILDTARGET)\MyservicePf.pdb' / RemoveFile Id='REM_MYSERVICE_XML' Name='Myservice_Cache_Service.xml' On='uninstall'/ ServiceControl Id='Myservice_Cache_Service' Name='Myservice' Start='install' Stop='both' Remove='both' Wait='no'/ ServiceInstall Id='Myservice_Cache_Service' Name='Myservice' DisplayName='Myservice' Type='ownProcess' Start='auto' ErrorControl='normal' Account='[SERVICEACCOUNT]' Description='Myservice Cache Service'/ ... /Component /Directory -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] unable to start a service through MSI
Service can't start can be a dependency issue. A service that's dependent on Dlls being installed to the GAC or to SxS (C++ runtimes) will fail when MSI starts because StartServices is before these are committed to the system. It will start from Service Control Panel afterwards (if there's no rollback) because now the dependencies are installed. Phil W -Original Message- From: Michael Osmond [mailto:mosm...@baytech.com.au] Sent: Wednesday, February 01, 2012 4:46 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] unable to start a service through MSI The error message is pretty generic, the service can't start for almost any reason. We have MSIs that run in full dialog mode so there is a dialog popped when the service fails to start with the error you are seeing in the eventlog, with a retry and cancel options. When you get this dialog go to the Services control panel and manual start the service, you will often get a more meaningful error. If you don't get the dialog with the error, change your MSI so it does not try start the service, and debug the startup when the install is finished Michael -Original Message- From: Rajesh Khetan [mailto:rajesh.khe...@microsoft.com] Sent: Thursday, 2 February 2012 10:29 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] unable to start a service through MSI Hi, I am currently trying to get my service started as a part of MSI install and am unable to do so. In the event viewer, I see the following error: Product: Myservice Cache Service -- Error 1920. Service ' Myservice ' (Myservice) failed to start. Verify that you have sufficient privileges to start system services. However, I am logged in as admin. Also, if I simply install the service and start the service manually, I am able to do that. I appreciate any input to help me figure out what I might be doing wrong or missing. One additional data about my service is: I am trying to install the service under account NT AUTHORITY\NETWORK SERVICE (Property SERVICEACCOUNT = 'NT AUTHORITY\NETWORK SERVICE' below) Thanks a lot for your help. Rajesh PS: Here is a snippet from my WXS file: Directory Id='TARGETDIR' Name='SourceDir' Component Id=' MyserviceCacheComponent' Guid='my guid' !-- The files to be installed -- File Id='Myservice.exe' Name='Myservice.exe' DiskId='1' Source='$(var.INETROOT)\target\$(var.BUILDTYPE)\$(var.BUILDTARGET)\Myservice.exe' / File Id='Myservice.pdb' Name='Myservice.pdb' DiskId='1' Source='$(var.INETROOT)\target\$(var.BUILDTYPE)\$(var.BUILDTARGET)\Myservice.pdb' / File Id='MyservicePf.dll' Name='MyservicePf.dll' SelfRegCost='1' DiskId='1' Source='$(var.INETROOT)\target\$(var.BUILDTYPE)\$(var.BUILDTARGET)\MyservicePf.dll' / File Id='MyservicePf.pdb' Name='MyservicePf.pdb' DiskId='1' Source='$(var.INETROOT)\target\$(var.BUILDTYPE)\$(var.BUILDTARGET)\MyservicePf.pdb' / RemoveFile Id='REM_MYSERVICE_XML' Name='Myservice_Cache_Service.xml' On='uninstall'/ ServiceControl Id='Myservice_Cache_Service' Name='Myservice' Start='install' Stop='both' Remove='both' Wait='no'/ ServiceInstall Id='Myservice_Cache_Service' Name='Myservice' DisplayName='Myservice' Type='ownProcess' Start='auto' ErrorControl='normal' Account='[SERVICEACCOUNT]' Description='Myservice Cache Service'/ ... /Component /Directory -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net
Re: [WiX-users] unable to start a service through MSI
Thanks Phil. Is there a way to ensure in WXS file, such that the service gets started after all the dependent dlls are installed? -Original Message- From: Wilson, Phil [mailto:phil.wil...@invensys.com] Sent: Wednesday, February 01, 2012 5:11 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] unable to start a service through MSI Service can't start can be a dependency issue. A service that's dependent on Dlls being installed to the GAC or to SxS (C++ runtimes) will fail when MSI starts because StartServices is before these are committed to the system. It will start from Service Control Panel afterwards (if there's no rollback) because now the dependencies are installed. Phil W -Original Message- From: Michael Osmond [mailto:mosm...@baytech.com.au] Sent: Wednesday, February 01, 2012 4:46 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] unable to start a service through MSI The error message is pretty generic, the service can't start for almost any reason. We have MSIs that run in full dialog mode so there is a dialog popped when the service fails to start with the error you are seeing in the eventlog, with a retry and cancel options. When you get this dialog go to the Services control panel and manual start the service, you will often get a more meaningful error. If you don't get the dialog with the error, change your MSI so it does not try start the service, and debug the startup when the install is finished Michael -Original Message- From: Rajesh Khetan [mailto:rajesh.khe...@microsoft.com] Sent: Thursday, 2 February 2012 10:29 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] unable to start a service through MSI Hi, I am currently trying to get my service started as a part of MSI install and am unable to do so. In the event viewer, I see the following error: Product: Myservice Cache Service -- Error 1920. Service ' Myservice ' (Myservice) failed to start. Verify that you have sufficient privileges to start system services. However, I am logged in as admin. Also, if I simply install the service and start the service manually, I am able to do that. I appreciate any input to help me figure out what I might be doing wrong or missing. One additional data about my service is: I am trying to install the service under account NT AUTHORITY\NETWORK SERVICE (Property SERVICEACCOUNT = 'NT AUTHORITY\NETWORK SERVICE' below) Thanks a lot for your help. Rajesh PS: Here is a snippet from my WXS file: Directory Id='TARGETDIR' Name='SourceDir' Component Id=' MyserviceCacheComponent' Guid='my guid' !-- The files to be installed -- File Id='Myservice.exe' Name='Myservice.exe' DiskId='1' Source='$(var.INETROOT)\target\$(var.BUILDTYPE)\$(var.BUILDTARGET)\Myservice.exe' / File Id='Myservice.pdb' Name='Myservice.pdb' DiskId='1' Source='$(var.INETROOT)\target\$(var.BUILDTYPE)\$(var.BUILDTARGET)\Myservice.pdb' / File Id='MyservicePf.dll' Name='MyservicePf.dll' SelfRegCost='1' DiskId='1' Source='$(var.INETROOT)\target\$(var.BUILDTYPE)\$(var.BUILDTARGET)\MyservicePf.dll' / File Id='MyservicePf.pdb' Name='MyservicePf.pdb' DiskId='1' Source='$(var.INETROOT)\target\$(var.BUILDTYPE)\$(var.BUILDTARGET)\MyservicePf.pdb' / RemoveFile Id='REM_MYSERVICE_XML' Name='Myservice_Cache_Service.xml' On='uninstall'/ ServiceControl Id='Myservice_Cache_Service' Name='Myservice' Start='install' Stop='both' Remove='both' Wait='no'/ ServiceInstall Id='Myservice_Cache_Service' Name='Myservice' DisplayName='Myservice' Type='ownProcess' Start='auto' ErrorControl='normal' Account='[SERVICEACCOUNT]' Description='Myservice Cache Service'/ ... /Component /Directory -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Keep Your Developer Skills Current with LearnDevNow! The most
Re: [WiX-users] Installing multiple applications
I was duplicating the DLLs across both the web site and windows service previously. I guess this is probably the simplest option at the cost of disk space and duplicate components and files in the MSI. My thought was that the reduced disk space and single set of components was worth the complexity of the custom action to add the NTFS junctions. I guess another downside I hadn't thought of is that I'm currently limited to NTFS. Thanks, Chris -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Wednesday, February 01, 2012 5:18 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Installing multiple applications What about duplicating the files? I know that sounds a bit crazy but if you're okay taking a bit more size on disk when installed, the WiX toolset's smartcabbing will only carry the files once in the package. On Wed, Feb 1, 2012 at 3:47 PM, McKinnon, Chris cmckin...@atb.com wrote: Hi, I'm updating my install process and I'd like to hear suggestions on improving my install process. My apps normally consist of a web site and a windows service. The apps and installers are for in-house use only. In the past, I've modified the install UI to allow to separate install locations for the web site and windows service. I think I did it this way because that's how we used to manually install apps. Now, I'm re-visiting this decision and I'd like to fix two install related issues: 1. Have one install location for the application. 2. Move common files to a Common location. Addressing #1 is fairly simple. Use one install location and use subfolders for the different components: [Install Directory] [bin] -- application DLLs [Web Site] -- Web Site files [Windows Service] -- Windows Service files Both the Web Site's and Windows Service's DLLs are in the bin folder. This introduces a new problem: How do the .NET apps find the DLLs? I used SysInternals junction.exe to create a junction to the bin folder in both the Web Site and Windows Services folders. In the config files of both apps, I use a runtime-probing specification to tell the apps to look for the DLLs in a bin subfolder. So, I end up with: [Install Directory] [bin] -- application DLLs [Web Site] -- Web Site files [bin] -- Junction pointing back to top level bin folder [Windows Service] -- Windows Service files [bin] -- Junction pointing back to top level bin folder This seems to work nicely. I'm not particularly fond of calling junction.exe at the end of my install but it works. I'd rather have a DLL call. Since the DLL could be included as a binary. I've been searching around for common solutions to this install problem but I haven't seen it addressed. I'm wondering if there is a better solution? I looked at using codebase but didn't like having to specify specific DLL information. And I think it would be inappropriate to use the GAC as the DLLs are for a specific app (rather than DLLs that could be used by any app). Thanks, Chris McKinnon The information contained in this e-mail is confidential and may contain privileged information. It is intended only for the person or persons named above. If you are not an intended recipient of this e-mail please be advised that any distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify us by return e-mail and delete all copies of the e-mail and any attachments. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users The information contained in this e-mail is confidential and may contain privileged information. It is intended only for the person or persons named above. If you are not an intended recipient of this e-mail please be advised that any
