Re: [WiX-users] WIX 3.5 AppPool is not uninstalled on Windows 7

2011-02-19 Thread Paul Reynolds
Excellent. That fixed it. Thanks for the feedback/confirmation.

Paul

-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com] 
Sent: Sunday, 20 February 2011 3:54 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] WIX 3.5 AppPool is not uninstalled on Windows 7

Yep, store as a string. Windows Installer has a nasty habit of adding the "#" 
in front of integers.

On Fri, Feb 18, 2011 at 4:38 PM, Paul Reynolds < 
preyno...@planetsoftware.com.au> wrote:

> Hi Rob
>
> The install log indicates the following:
>
> MSI (s) (84!9C) [13:29:59:613]: PROPERTY CHANGE: Adding 
> ConfigureIIs7Exec property. Its value is 
> 'ConfigureIIs€1€0€0€2€1€0€0€2€1€17€1€AppPool€1€Name€1€Component_€1€Att
> ributes€2€User_€1€RecycleMinutes€2€RecycleRequests€2€RecycleTimes€1€Vi
> rtualMemory€2€PrivateMemory€2€IdleTimeout€2€QueueLimit€2€CPUMon€1€MaxP
> roc€2€ManagedRuntimeVersion€1€ISInstalled€2€ISAction€2€3€AppPool€Year
> View1€WebVirtualDirComponent€16€€0€-2147483648€€-2147483648€-214748364
> 8€0€-2147483648€0€-2147483648€v4.0€2€3€4€2€1€2€72€Component€1€Attribut
> es€2€3€WebVirtualDirComponent€0€4€3€PersistWebSiteValues€4€4€3€cmpCBE0
> 3EE0AF9F6B0841326F548614EE48€0€4€3€cmp93645FCD1A13835D0DFCD156CF2C6C64
> €0€4€3€cmpECB93C0A0BCC99CFF4F7F86911E011A0€0€4€3€cmp613C806AB0AE5AA7AC
> 14BEA422234BEE€0€4€3€cmpFB33635B7D7AF5906B5DFB25D7E4F343€0€4€3€cmp8349
> F34D6A091B3EC41C3FBDDBC9BD18€0€4€3€cmp9C9BF9D1042FA6EC5ED4930EF8B8FB22
> €0€4€3€cmpCFFE550301C5C4C31FC0C99957544FC3€0€4€3€cmpFC57B0C1E00D38E878
> 0C465303D67AC5€0€4€3€cmpDCFF70F39D6356727B05BC8667003152€0€4€3€cmpDEC4
> EFB7A53E8998622E73D30FB37FE3€0€4€3€cmp90A0520362E97A01F17FE43C62B37A3A
> €0€4€3€cmpB30A35764A30 MSI (s) (84!9C) [13:29:59:613]: Doing action: 
> ConfigureIIs7Exec
>
> The uninstall log shows:
>
> MSI (s) (DC!80) [10:55:03:463]: PROPERTY CHANGE: Adding 
> ConfigureIIs7Exec property. Its value is 
> 'ConfigureIIs€1€0€0€2€1€0€0€2€1€17€1€AppPool€1€Name€1€Component_€1€Att
> ributes€2€User_€1€RecycleMinutes€2€RecycleRequests€2€RecycleTimes€1€Vi
> rtualMemory€2€PrivateMemory€2€IdleTimeout€2€QueueLimit€2€CPUMon€1€MaxP
> roc€2€ManagedRuntimeVersion€1€ISInstalled€2€ISAction€2€3€AppPool€Year
> View#1€WebVirtualDirComponent€16€€0€-2147483648€€-2147483648€-21474836
> 48€0€-2147483648€0€-2147483648€v4.0€3€2€4€2€1€2€72€Component€1€Attribu
> tes€2€3€WebVirtualDirComponent€0€4€3€PersistWebSiteValues€4€4€3€cmpCBE
> 03EE0AF9F6B0841326F548614EE48€0€4€3€cmp93645FCD1A13835D0DFCD156CF2C6C6
> 4€0€4€3€cmpECB93C0A0BCC99CFF4F7F86911E011A0€0€4€3€cmp613C806AB0AE5AA7A
> C14BEA422234BEE€0€4€3€cmpFB33635B7D7AF5906B5DFB25D7E4F343€0€4€3€cmp834
> 9F34D6A091B3EC41C3FBDDBC9BD18€0€4€3€cmp9C9BF9D1042FA6EC5ED4930EF8B8FB2
> 2€0€4€3€cmpCFFE550301C5C4C31FC0C99957544FC3€0€4€3€cmpFC57B0C1E00D38E87
> 80C465303D67AC5€0€4€3€cmpDCFF70F39D6356727B05BC8667003152€0€4€3€cmpDEC
> 4EFB7A53E8998622E73D30FB37FE3€0€4€3€cmp90A0520362E97A01F17FE43C62B37A3
> A€0€4€3€cmpB30A35764A3 Action ended 10:55:03: 
> CommitIIS7ConfigTransaction. Return value 1.
>
> So I can see a difference here where the uninstall gets a # between 
> the View and the 1...?!
>
> Would this indicate a type conversion issue with the way I 
> save/read/use the values to/from the registry?
>
> Loading at startup (so the value we get for uninstall):
>
> 
> Key="SOFTWARE\!(loc.CompanyName)\!(loc.ProductName)\Install" 
> Type="raw" />  
>
> Saving after install:
>
> Guid="C3DAE2E2-FB49-48ba-ACB0-B2B5B726AE65">
>  
> Key="SOFTWARE\!(loc.CompanyName)\!(loc.ProductName)\Install">
> Type="integer" Value="[WEBSITE_ID]"/>
>
> Maybe I should just be storing as a string?
>
> Paul
>
> -Original Message-
> From: Rob Mensching [mailto:r...@robmensching.com]
> Sent: Saturday, 19 February 2011 12:31 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] WIX 3.5 AppPool is not uninstalled on Windows 
> 7
>
> Verbose log file usually tells all. First thing I would double check 
> is the Name of the the WebAppPool data being passed to the custom action.
>
> On Thu, Feb 17, 2011 at 4:07 PM, Paul Reynolds < 
> preyno...@planetsoftware.com.au> wrote:
>
> > Hi
> >
> > On my dev box (win7 64bit), I'm finding that when I uninstall my web 
> > application, everything gets properly removed EXCEPT the AppPool.
> >
> > I found a related thread:
> > http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Proble
> > m- with-Application-pools-in-IIS-on-Windows-7-2008-td5438654.html
> >
> > But no answer was contained there, so I'm hoping for some pointers?!
> >
> > Here's the structure:
> >
> >
> >
> >  
> > > ComponentGuidGenerationSeed='CA19CA4A-C69B-4CDB-BCBD-6C3C5E9A3EDC'>
> >  
> >
> >
> > > Guid="A720C1C9-1D8D-4941-976D-FB1C5C9EF8BB">
> >
> >  
> >   > ManagedRuntimeVersion="v4.0" IdleTimeout="0" RecycleMinutes="0"
> > ManagedPipelineMode="integrated">
>

Re: [WiX-users] Dynamically set WixVariable WixUILicenseRtf

2011-02-19 Thread Rob Mensching
Seems like a reasonable feature request.

On Fri, Feb 18, 2011 at 7:19 AM, James Johnston wrote:

> Oh wow...  Right now we just change it in our build script when calling
> light:
>
> light  -dWixUILicenseRtf=SupportFiles/License_${language}.rtf
> 
>
> Which is also unnecessarily kludgy; that information really should be in
> the
> localization file but at the time I didn't figure out how (that blog entry
> was written after I wrote the setup project...).
>
> Your solution is better except that it involves modifying WiX source code.
> Any chance this might be added to a future version of WiX?  This common
> task
> seems needlessly complicated.  Maybe the change would break compatibility,
> but on the other hand the status quo of modifying WiX source code doesn't
> seem any better to me!
>
> Unless there is a better way that neither of us know about??
>
> James
>
> -Original Message-
> From: Tobias S [mailto:tobias.s1...@gmail.com]
> Sent: Friday, February 18, 2011 15:08
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Dynamically set WixVariable WixUILicenseRtf
>
> Ok, knew there exists an english speaking tutorial:
>
> http://weblogs.sqlteam.com/mladenp/archive/2010/04/15/WiX-3-Tutorial-Custom-
> EULA-License-and-MSI-localization.aspx
>
> 2011/2/18 Tobias S :
> > You have to overwrite the default WiX dialog e.g. in WixUI_InstallDir
> > with a modified LicenseAgreementDlg.wxs:
> >
> > 1.) get the WiX Source code
> >
> >
> > 2.) from there add copies from
> > src\ext\UIExtension\wixlib\WixUI_InstallDir.wxs +
> > LicenseAgreementDlg.wxs to your solution renamed as
> > MyLicenseAgreementDlg.wxs + MyWixUI_InstallDir.wxs
> >
> >
> > 3.) MyLicenseAgreementDlg.wxs
> > change lines
> >  > Title="!(loc.LicenseAgreementDlg_Title)">
> > -->
> >  > Title="!(loc.LicenseAgreementDlg_Title)">
> >
> >
> >
> >  > Width="330" Height="140" Sunken="yes" TabSkip="no">
> >   
> > 
> >
> > -->
> >
> >  > Width="330" Height="140" Sunken="yes" TabSkip="no">
> >
> >
> >
> > 4.) WixUI_InstallDir.wxs
> > change line
> >  
> > -->
> >  
> >
> > Replace all four occurences of LicenseAgreementDlg with
> MyLicenseAgreementDlg
> >
> >
> > 5.) Change in the main wxs the reference to the modified
> MyWixUI_InstallDir
> > 
> > -->
> > 
> >
> >
> > 6.) Add for every language a localization file with at least the
> > following content:
> > 
> >  > xmlns="http://schemas.microsoft.com/wix/2006/localization";>
> >  1033
> >  Languages\EnglishLicenseAgreement.rtf
> > 
> >
> >
> > Here LicenseRtf is the location of the localized License Agreement
> >
> >
> > Regards
> > Tobias
> >
> >
> > 2011/2/18 Michael Tissington :
> >> How can I dynamically set the value of WixUILicenseRtf?
> >>
> >> I have tried 
> >>
> >> What I'm trying to do is for each localization to use a different
> license.rtf.
> >>
> >>
> >>
>
> 
> --
> >> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio
> XE:
> >> Pinpoint memory and threading errors before they happen.
> >> Find and fix more than 250 security defects in the development cycle.
> >> Locate bottlenecks in serial and parallel code that limit performance.
> >> http://p.sf.net/sfu/intel-dev2devfeb
> >> ___
> >> WiX-users mailing list
> >> WiX-users@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/wix-users
> >>
> >
>
>
> 
> --
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
> --
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>


-- 
virtually, Rob Mensching - http://RobMensching.com LLC
--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before t

Re: [WiX-users] What's the reason of not allowing the modification of the persistent data from within the CA?

2011-02-19 Thread Rob Mensching
The MSI database is read-only. You can add information to the in memory copy
but it is, of course, discarded when the install is complete. IIRC, the
Windows Installer does not let you modify the stuff read-only from the
database. I think that's just a restriction they enforce.

Why? You'd have to ask the Windows Installer team.
On Fri, Feb 18, 2011 at 12:19 PM, Yan Sklyarenko <
yansklyarenko+...@gmail.com> wrote:

> Yes, that's what I mean...
> How is inserting temporary records possible then? I assume it inserts
> temporary records to a certain view of the database in memory during
> install
> time, right? Why isn't it possible to modify this view in memory, not only
> inserting? Sorry if I'm asking the stupid things, just want to make it
> absolutely clear to myself...
>
> -- Yan
>
> On Fri, Feb 18, 2011 at 4:03 PM, Rob Mensching 
> wrote:
>
> > What do you mean "persistent data"? Are you asking why a CA can't modify
> an
> > MSI database? If so, the answer is: The Windows Installer opens the
> database
> > for read-only during install.
> >
> >  On Thu, Feb 17, 2011 at 1:55 AM, Yan Sklyarenko <
> > yansklyarenko+...@gmail.com> wrote:
> >
> >>  Hello WiX Community,
> >>
> >> Well, actually the subject tells it all. I'm aware of this limitation,
> and
> >> I've been successfully using the CA working with temporary data.
> >> Now I'd like to know the reasoning behind this. Is it a technical
> >> limitation? Why we can't "temporary" change the persistent data, just
> for
> >> the current transaction - the way temporary records are inserted?
> >>
> >> Thanks,
> >>
> >> -- Yan
> >>
> >>
> --
> >> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio
> XE:
> >> Pinpoint memory and threading errors before they happen.
> >> Find and fix more than 250 security defects in the development cycle.
> >> Locate bottlenecks in serial and parallel code that limit performance.
> >> http://p.sf.net/sfu/intel-dev2devfeb
> >> ___
> >> WiX-users mailing list
> >> WiX-users@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/wix-users
> >>
> >>
> >
> >
> > --
> > virtually, Rob Mensching - http://RobMensching.com LLC
> >
>
> --
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>


-- 
virtually, Rob Mensching - http://RobMensching.com LLC
--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] error LGHT0104

2011-02-19 Thread Rob Mensching
99% sure it's something wrong with your command-line.

On Fri, Feb 18, 2011 at 9:30 AM, Maillet, Ed  wrote:

> Hey all,
>  All of a sudden I'm getting the following error:
> C:\Program Files\Windows Installer XML v3.5\bin\WixUtilExtension.dll(0,0):
> error LGHT0104: Not a valid object file; detail: '.', hexadecimal value
> 0x00, is an invalid character. Line 1, position 17600.
>
> The Light command line is (from the VS output window):
>
> C:\Program Files\Windows Installer XML v3.5\bin\Light.exe -cultures:en-us
> -ext "C:\Program Files\Windows Installer XML v3.5\bin\WixUtilExtension.dll"
> -out
> C:\Projects\Temp\Setups\CodeSetService\SetupProject1\bin\Debug\SetupProject1.msi
> -pdbout
> C:\Projects\Temp\Setups\CodeSetService\SetupProject1\bin\Debug\SetupProject1.wixpdb
> obj\Debug\Product.wixobj obj\Debug\Product.Generated.wixobj
>
>
> The setup.wixproj is an empty setup with WixUtilExtension referenced.
>
>
> Any ideas as what to fix? It's like the -ext option isn't doing something
> right.
>
> - Ed
>
>
> --
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>


-- 
virtually, Rob Mensching - http://RobMensching.com LLC
--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] How to change the Windows Integrity level in Vista/Win7 when launching the application

2011-02-19 Thread Rob Mensching
When is your custom action scheduled?

On Fri, Feb 18, 2011 at 3:17 PM, little.forest wrote:

> We found a problem in Vista/Win7:
> If we launch the application from the installer for the fresh installation,
> the
> Integrity level is empty. The process is on the same level as
> "explorer.exe".
> If we start the application from Start menu after the installation, the
> Integrity level is Medium(just like other applications). And the process is
> under "explorer.exe".
>
> The question is, how to launch the application from installer to make it
> have
> "Medium" Integrity level.
>
> By the way, by using "Process Explorer" from SystemInternals and turning on
> the
> Integrity field, the Integrity level field will show up.
>
> The reason we ask this is because: we have a bug which seems related to
> this
> Integrity Level thing. If the app is started from the Start menu, things
> are
> fine. If the app is launched from the installer for the 1st time
> installation,
> some functionalities don't work. I tried to set the 'Impersonate' field to
> be
> 'no'. But it doesn't help.
>
> Here's our launch app code:
> Value="[INSTALLLOCATION]$(var.ExeFile)" />
>  BinaryKey="WixCA"
> DllEntry="WixShellExec"
> Impersonate="no"
> />
>
>
> Thanks in advance.
>
>
> --
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>


-- 
virtually, Rob Mensching - http://RobMensching.com LLC
--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] WIX 3.5 AppPool is not uninstalled on Windows 7

2011-02-19 Thread Rob Mensching
Yep, store as a string. Windows Installer has a nasty habit of adding the
"#" in front of integers.

On Fri, Feb 18, 2011 at 4:38 PM, Paul Reynolds <
preyno...@planetsoftware.com.au> wrote:

> Hi Rob
>
> The install log indicates the following:
>
> MSI (s) (84!9C) [13:29:59:613]: PROPERTY CHANGE: Adding ConfigureIIs7Exec
> property. Its value is
> 'ConfigureIIs€1€0€0€2€1€0€0€2€1€17€1€AppPool€1€Name€1€Component_€1€Attributes€2€User_€1€RecycleMinutes€2€RecycleRequests€2€RecycleTimes€1€VirtualMemory€2€PrivateMemory€2€IdleTimeout€2€QueueLimit€2€CPUMon€1€MaxProc€2€ManagedRuntimeVersion€1€ISInstalled€2€ISAction€2€3€AppPool€Year
> View1€WebVirtualDirComponent€16€€0€-2147483648€€-2147483648€-2147483648€0€-2147483648€0€-2147483648€v4.0€2€3€4€2€1€2€72€Component€1€Attributes€2€3€WebVirtualDirComponent€0€4€3€PersistWebSiteValues€4€4€3€cmpCBE03EE0AF9F6B0841326F548614EE48€0€4€3€cmp93645FCD1A13835D0DFCD156CF2C6C64€0€4€3€cmpECB93C0A0BCC99CFF4F7F86911E011A0€0€4€3€cmp613C806AB0AE5AA7AC14BEA422234BEE€0€4€3€cmpFB33635B7D7AF5906B5DFB25D7E4F343€0€4€3€cmp8349F34D6A091B3EC41C3FBDDBC9BD18€0€4€3€cmp9C9BF9D1042FA6EC5ED4930EF8B8FB22€0€4€3€cmpCFFE550301C5C4C31FC0C99957544FC3€0€4€3€cmpFC57B0C1E00D38E8780C465303D67AC5€0€4€3€cmpDCFF70F39D6356727B05BC8667003152€0€4€3€cmpDEC4EFB7A53E8998622E73D30FB37FE3€0€4€3€cmp90A0520362E97A01F17FE43C62B37A3A€0€4€3€cmpB30A35764A30
> MSI (s) (84!9C) [13:29:59:613]: Doing action: ConfigureIIs7Exec
>
> The uninstall log shows:
>
> MSI (s) (DC!80) [10:55:03:463]: PROPERTY CHANGE: Adding ConfigureIIs7Exec
> property. Its value is
> 'ConfigureIIs€1€0€0€2€1€0€0€2€1€17€1€AppPool€1€Name€1€Component_€1€Attributes€2€User_€1€RecycleMinutes€2€RecycleRequests€2€RecycleTimes€1€VirtualMemory€2€PrivateMemory€2€IdleTimeout€2€QueueLimit€2€CPUMon€1€MaxProc€2€ManagedRuntimeVersion€1€ISInstalled€2€ISAction€2€3€AppPool€Year
> View#1€WebVirtualDirComponent€16€€0€-2147483648€€-2147483648€-2147483648€0€-2147483648€0€-2147483648€v4.0€3€2€4€2€1€2€72€Component€1€Attributes€2€3€WebVirtualDirComponent€0€4€3€PersistWebSiteValues€4€4€3€cmpCBE03EE0AF9F6B0841326F548614EE48€0€4€3€cmp93645FCD1A13835D0DFCD156CF2C6C64€0€4€3€cmpECB93C0A0BCC99CFF4F7F86911E011A0€0€4€3€cmp613C806AB0AE5AA7AC14BEA422234BEE€0€4€3€cmpFB33635B7D7AF5906B5DFB25D7E4F343€0€4€3€cmp8349F34D6A091B3EC41C3FBDDBC9BD18€0€4€3€cmp9C9BF9D1042FA6EC5ED4930EF8B8FB22€0€4€3€cmpCFFE550301C5C4C31FC0C99957544FC3€0€4€3€cmpFC57B0C1E00D38E8780C465303D67AC5€0€4€3€cmpDCFF70F39D6356727B05BC8667003152€0€4€3€cmpDEC4EFB7A53E8998622E73D30FB37FE3€0€4€3€cmp90A0520362E97A01F17FE43C62B37A3A€0€4€3€cmpB30A35764A3
> Action ended 10:55:03: CommitIIS7ConfigTransaction. Return value 1.
>
> So I can see a difference here where the uninstall gets a # between the
> View and the 1...?!
>
> Would this indicate a type conversion issue with the way I save/read/use
> the values to/from the registry?
>
> Loading at startup (so the value we get for uninstall):
>
> 
> Key="SOFTWARE\!(loc.CompanyName)\!(loc.ProductName)\Install" Type="raw" />
>  
>
> Saving after install:
>
> Guid="C3DAE2E2-FB49-48ba-ACB0-B2B5B726AE65">
>  
> Key="SOFTWARE\!(loc.CompanyName)\!(loc.ProductName)\Install">
> Type="integer" Value="[WEBSITE_ID]"/>
>
> Maybe I should just be storing as a string?
>
> Paul
>
> -Original Message-
> From: Rob Mensching [mailto:r...@robmensching.com]
> Sent: Saturday, 19 February 2011 12:31 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] WIX 3.5 AppPool is not uninstalled on Windows 7
>
> Verbose log file usually tells all. First thing I would double check is the
> Name of the the WebAppPool data being passed to the custom action.
>
> On Thu, Feb 17, 2011 at 4:07 PM, Paul Reynolds <
> preyno...@planetsoftware.com.au> wrote:
>
> > Hi
> >
> > On my dev box (win7 64bit), I'm finding that when I uninstall my web
> > application, everything gets properly removed EXCEPT the AppPool.
> >
> > I found a related thread:
> > http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Problem-
> > with-Application-pools-in-IIS-on-Windows-7-2008-td5438654.html
> >
> > But no answer was contained there, so I'm hoping for some pointers?!
> >
> > Here's the structure:
> >
> >
> >
> >  
> > > ComponentGuidGenerationSeed='CA19CA4A-C69B-4CDB-BCBD-6C3C5E9A3EDC'>
> >  
> >
> >
> > > Guid="A720C1C9-1D8D-4941-976D-FB1C5C9EF8BB">
> >
> >  
> >   > ManagedRuntimeVersion="v4.0" IdleTimeout="0" RecycleMinutes="0"
> > ManagedPipelineMode="integrated">
> >  
> >
> >   > Directory="INSTALLLOCATION" WebSite="SelectedWebSite">
> > > WebAppPool="AppPool" Name="[VD][WEBSITE_ID]" />
> > > AnonymousAccess="yes" WindowsAuthentication="no"
> > DefaultDocuments="Default.aspx" />
> >  
> >
> >
> > As stated before, the VD gets removed fine...so this proves (?!) that
> > [VD][WEBSITE_ID] are valid...
> >
> >