[WiX-users] IIS entities not created or created incorrectly
We're seeing regular failures creating IIS virtual directories using WiXIISExtension (currently on 3.0.4014). Sometimes the virtual directory isn't created at all, sometimes the folder exists, but the application isn't created, and sometimes the application is created on a folder in a location other than that requested, usually down several levels in a nonsensical location. I can see from the CustomActionData that the arguments are set correctly. I saw some earlier information that there were difficulties with this in WiX 2.x, and in older versions of 3.x, but that the issues should be resolved in more current WiX builds. Occurs: * Intermittently on a virtual directory created at the root of the website (60% of the time on some machines) * Consistently on a virtual directory created under another virtual directory (sibling is created fine) (100% of the time on some machines, perhaps 75% of the time on other machines) (seems to happen much more frequently during upgrades, where the original package is uninstalled, then the new package is installed) Is anyone else seeing this type of difficulties with current 3.x builds, or have any pointers for things we could try that might reduce the probability of encountering this difficulty? Thanks! - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] IIS entities not created or created incorrectly
The problem:
A nested WebApplication isn't created consistently. With 3.0.3110, the app was
created 90% of the time. With 3.0.4014, it is almost (90%?) never created.
The original query had two issues, but there's just info on one here. The other
issue is with a non-nested web application not being created sometimes (fails
perhaps 40% of the time, and gets created if I run a repair). I'll handle the
other possibly related issue on another thread.
The WebApplication BobManager below not created. The folder shows up in IIS,
but there's no app. The log seems to indicate that it should have been created.
Snippits from the .wxs
iis:WebSite Id=DefaultWebSite Description=Default Web Site
ConnectionTimeout=3600
iis:WebAddress Id=DefaultWebSiteAddress Port=80 /
/iis:WebSite
iis:WebAppPool Id=BOB_App_Pool Name=[APP_POOL_NAME] /
iis:WebAppPool Id=BOB_App_Pool_Services
Name=[APP_POOL_NAME_SERVICES] /
DirectoryRef Id=BobDeploy
Component Id=IIS_BobDeploy
Guid={1A104A4E-1EDE-4498-A254-DFEA74CE435C} KeyPath=yes
CreateFolder /
iis:WebVirtualDir Id=BobDeploy Alias=BobDeploy
Directory=BobDeploy WebSite=DefaultWebSite
iis:WebApplication Id=BobDeploy AllowSessions=yes
Buffer=yes DefaultScript=VBScript Isolation=low Name=BobDeploy
WebAppPool=BOB_App_Pool /
iis:WebDirProperties Id=BobDeploy_WebDirProperties
AnonymousAccess=yes BasicAuthentication=no WindowsAuthentication=yes
Script=yes Read=yes Index=yes LogVisits=yes /
/iis:WebVirtualDir
/Component
/DirectoryRef
iis:WebDirProperties Id=BobServices_WebDirProperties
AnonymousAccess=no BasicAuthentication=no WindowsAuthentication=yes
Script=yes Read=yes Index=yes LogVisits=yes /
DirectoryRef Id=BobServices
Component Id=IIS_BobServices
Guid={FB0BC9C0-61C2-4431-A515-DA74B27ABD33} KeyPath=yes
CreateFolder /
iis:WebVirtualDir Id=BobServices Alias=BobServices
Directory=BobServices WebSite=DefaultWebSite
DirProperties=BobServices_WebDirProperties
iis:WebApplication Id=BobServicesApp AllowSessions=yes
Buffer=yes DefaultScript=VBScript Isolation=low Name=BobServices
WebAppPool=BOB_App_Pool_Services /
iis:WebVirtualDir Id=BobManager Alias=BobManager
Directory=Services_BobManager DirProperties=BobServices_WebDirProperties
iis:WebApplication Id=BobManager AllowSessions=yes
Buffer=yes DefaultScript=VBScript Isolation=low Name=BobManager
WebAppPool=BOB_App_Pool_Services /
/iis:WebVirtualDir
/iis:WebVirtualDir
/Component
/DirectoryRef
During install:
MSI (s) (B4:38) [08:56:17:591]: Invoking remote custom action. DLL:
C:\WINDOWS\Installer\MSI1D6.tmp, Entrypoint: ConfigureIIs
MSI (s) (B4!9C) [08:56:17:732]: PROPERTY CHANGE: Adding
StartMetabaseTransaction property. Its value is 'ScaConfigureIIs'.
Action start 8:56:17: ConfigureIIs.
MSI (s) (B4!9C) [08:56:17:748]: Doing action: StartMetabaseTransaction
Action start 8:56:17: StartMetabaseTransaction.
MSI (s) (B4!9C) [08:56:17:763]: PROPERTY CHANGE: Adding
RollbackMetabaseTransaction property. Its value is 'ScaConfigureIIs'.
MSI (s) (B4!9C) [08:56:17:763]: Doing action: RollbackMetabaseTransaction
Action ended 8:56:17: StartMetabaseTransaction. Return value 1.
Action start 8:56:17: RollbackMetabaseTransaction.
MSI (s) (B4!9C) [08:56:17:779]: PROPERTY CHANGE: Adding
CommitMetabaseTransaction property. Its value is 'ScaConfigureIIs'.
MSI (s) (B4!9C) [08:56:17:779]: Doing action: CommitMetabaseTransaction
Action ended 8:56:17: RollbackMetabaseTransaction. Return value 1.
Action start 8:56:17: CommitMetabaseTransaction.
Action ended 8:56:17: CommitMetabaseTransaction. Return value 1.
ConfigureIIs: Skipping ScaInstallWebSvcExt() because IIsWebServiceExtension
table not present
ConfigureIIs: Skipping ScaInstallMimeMap() - required table not present
ConfigureIIs: Skipping ScaGetHttpHeaders() - required tables not present.
ConfigureIIs: Skipping ScaGetWebErrors() - required tables not present.
ConfigureIIs: Skipping ScaInstallWebDirs() because IIsWebDir table not present
ConfigureIIs: Skipping ScaInstallFilters() - no IIsFilter table
ConfigureIIs: Skipping ScaInstallProperty() - required table not present
MSI (s) (B4!9C) [08:56:18:044]: PROPERTY CHANGE: Adding WriteMetabaseChanges
property. Its value is
[WiX-users] XMLConfig in two packages - Error opening XML
I'm having difficulties with running XMLConfig from two packages. I have XMLConfig data in two WiX MSI packages, updating key=blah value=blah2 entries in two different XML files. I can run either install, and the XMLConfig operations in that package will succeed (no errors and changes are present), but if I then run the other package, it fails when attempting to open the referenced XML file (indicates that the file, which is correct in the error message, does not exist). I'm working on creating two test packages to confirm that nothing else is going on that could be causing my symptoms and to see if rebooting between packages resolves the issue, but has anyone else observed this, and if so, do you have a workaround? Thanks, e - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Extracting COM data from executable COM servers (AppID) with heat.exe
As always, thank you for your help, Bob. I'll submit an enhancement request for Heat. It seems like we could add a switch (perhaps in file-mode only if it is too giving us much rope for directories) that would override the registry location, run an exe with the regserver switch, capture the diff, and provide the desired functionality. Slow and clunky, but functional. Perhaps if enough other people find it useful, it will be worth the trouble to add the functionality. Eric Hybner wrote: Do y'all have any pointers for extracting COM data from executable COM servers? Bob Arnson wrote: The technique Heat uses to detect self-reg data only works on in-proc servers. I don't think there's a way for Heat to support out-of-proc servers. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Extracting COM data from executable COM servers (AppID) with heat.exe
Do y'all have any pointers for extracting COM data from executable COM
servers? When I heat (-gg) BOB.exe (a legacy VB component not quite
ready to be retired) for example, I get something like this:
Component Id=BOB.exe Guid={14E7...}
File Id= BOB.exe Name= BOB.exe KeyPath=yes
Sourcec:\Path\BOB.exe
TypeLib Id={6DD...} Description= BOB 1.0 Type Library
HelpDirectory=Path Language=0 MajorVersion=1 MinorVersion=0
Interface Id={6DD...} Name=IBOBObject
ProxyStubClassId={00142...} ProxyStubClassId32={00142...} /
/TypeLib
/File
/Component
I get the HKCR\Interface\{6DD...} and HKCR\TypeLib\{6DD...} data in my
resultant MSI, but what I'm not getting (either in the WiX fragment or
at install time) are the HKCR\APPID\BOB.EXE or HKCR\{...}\ (default)=BOB
entries I get if I run BOB.exe /regserver
Is there a switch I'm not seeing for heat that will grab the information
I need?
Thanks!
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] LGHT0093 : Could not find entry section in provided list of intermediates.
Well now, that was silly... trying to light a fragment... Why couldn't I realize that before I emailed the universe? J Is the request for a meaningful error message considered a feature request or a bug? snip I'm getting the error below when trying to light up one of my packages... light.exe : error LGHT0093 : Could not find entry section in provided list of intermediates. /snip - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] CustomTableRef?
With FragmentRef deprecated, is there a supported mechanism for sucking in a CustomTable and associated data from an external file? How about storing data and schema separately (so that developer X can add data rows, but cant muck with my table schema)? Thanks! - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX-users Digest, Vol 5, Issue 11
snip I have an MSM that defines a set of CustomAction entries. The MSM is merged into the MSI, and it is my responsibility to execute the MSM's custom actions. Unfortunately when I compile my project, light rightly complains: C:\xxx\yyy.xml : error LGHT0112 : Unresolved reference to symbol 'CustomAction:foo' in section 'Product:12345678-1234-1234-1234-123456789012'. /snip Custom Actions in an MSM are available as CustomAction.GUID. Add the merge module to your package, candle/light it, then crack open the MSI with Orca, and you'll see it there in your CustomAction table. You should be able to insert CustomAction.GUID without light complaining. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
