Just tested that and no change, unfortunately. I'll also note that when the
services were correctly uninstalling in the past, I would have the Services
window open, and I could refresh it to see that the services were completely
removed.
But in debugging, we stumbled upon the reason for this Disabled behaviour, and
Phil was right all along: I had recently started using Sysinternal's Process
Explorer to watch detailed information about the services and processes
starting and stopping, which was useful in seeing the cmd.exe/batch file
problem. However, Process Explorer, a process itself, must hook into the
services to monitor them more closely than the Task Manager or the Services
window, because the result is quite clear: When Process Explorer is open, the
services are Disabled, but not removed, but if Process Explorer is not open, I
can see our services being removed in the Services window.
I'm guessing the Services window used to do the same thing, but perhaps it's
been fixed in Windows 7.
To think our own debugging tools can turn against us and sabotage our
efforts...et tu, Brute?
Thank you for your help everyone! If anyone has any other ideas on the
cmd.exe/batch file execution that's errorneously triggering the RestartManager,
or a better way to interact with services in Java than with
Runtime.getRuntime().exec("net stop MyService"), please do let me know.
However, I think this is a sufficient workaround in the meantime.
Alain
-----Original Message-----
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: June 28, 2013 16:07
To: afor...@cmu.edu; General discussion for Windows Installer XML toolset.
Subject: RE: [WiX-users] Uninstall restart issue
Do you still have the computer management console open when doing the uninstall
(but after stopping the service)? I seem to remember bugs in the snap in that
either leaked handles or maintained an exclusive lock on the SCM that would
exhibit this behavior.
-----Original Message-----
From: Alain Forget [mailto:afor...@cmu.edu]
Sent: Friday, June 28, 2013 2:38 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Uninstall restart issue
I'll open by saying that I don't think this is why the services are being
disabled, because I'm not even using this part of our client yet. All I'm doing
right now to test this is installing our software, manually (in Services)
stopping our services (to "simulate" what our software would do before trying
to upgrade), and then uninstall. For some reason, this disables all the
services, but doesn't remove them until a restart. I can't imagine what process
would be interacting with our services that would lock them as you've described
though...especially since this used to work just fine before I started
debugging the other problem. Arg.
Ah, I understand what you mean. Well, Runtime.getRuntime().exec("net stop " +
serviceName) returns a Process object that can be used to monitor the process,
get the output, return values, and so on. someProcessObject.waitFor() stops the
execution of the current program until someProcessObject is done and returns.
Regarding what net stop does, whenever I open a command line, and type "net
stop MyService1", the command window sits and waits until the service stops,
and only then (or after longer than I've ever waited) does it actually give me
a command prompt again once the service has stopped.
So this seems pretty synchronous to me, although not as useful and interactive
as the ServiceController class you've described. I would prefer to use Java API
to interact with services, no such thing exists, hence net stop. I could
capture the output of net stop to confirm whether or not it was successful to
get at least some info. But yes, it's a suboptimal solution.
Had I known getting a Java application to work as a service would be such a
nightmare, I might have pushed harder to redo everything in .NET.
Alain
-----Original Message-----
From: Phil Wilson [mailto:phil.wil...@mvps.org]
Sent: June 28, 2013 14:55
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Uninstall restart issue
Any process that wants to do something with a service (such as stop it) has a
Windows handle open to it. In managed code you'd use a ServiceController class,
and the Dispose() method in that class is explicitly there to release unmanaged
resources like that service handle. By "managed" I mean Microsoft .NET
"managed" - I don't know what your java is.
In C++ it's a bit more exposed - you'd do a Win32 OpenService() call, this
returns a handle that must be closed or you have a handle leak and a service
that can't be deleted.
On the net stop thing my cmd-style/old dos style knowledge is long gone but:
I don't know for a fact that your net stop is synchronous. It might be that it
actually fires off a process to host the net stop, and it runs while you return
and you're in a timing race with the rest of what you're doing. It's also
possible that internally net stop just tells the service to stop but doesn't
wait for it to actually finish, in which case it's also asynchronous and you're
in a timing race. That's because stopping a service is message based. An actual
synchronous API call will tell you what's really going on, such as whether the
service asked for more time to shut down, and will return a result saying
whether it worked or not, and you can really wait for it to finish. The other
issue is that you don't actually know that your net stop worked - you're
trusting that it will be ok and the service will stop.
If your java runtime has an explicit way to stop a Windows service and wait for
it to actually finish, use that.
Phil
-----Original Message-----
From: Alain Forget [mailto:afor...@cmu.edu]
Sent: Friday, June 28, 2013 11:14 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Uninstall restart issue
Can you clarify what you mean by "If any process has a handle open to a
service"? Isn't it the service that runs/spawns/opens a handle to a process,
and not the other way around? And isn't it the service that tries to stop the
process when the service is told to stop?
Our code is all in Java (so it's managed, as far as I know), and I use the
following to stop the services:
Runtime.getRuntime().exec("net stop " + serviceName).waitFor();
So our client stops and waits until our service is stopped. This waiting of
indeterminate length makes me jumpy as well, but I don't know of any other
solution to this problem (of a running service that called a batch file causes
the RestartManager to think a restart is needed when it really won't
be) that we've been trying to figure out and fix for weeks.
I'm definitely open to any suggestions.
Alain
-----Original Message-----
From: Phil Wilson [mailto:phil.wil...@mvps.org]
Sent: June 28, 2013 14:03
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Uninstall restart issue
I've mentioned this before, but I don't recall if it was in connection with
this thread...
If any process has a handle open to a service, then Windows can't delete it so
it gets marked disabled. In code this tends to be code that doesn't close
handles , whether explicitly in C++ or in managed code ServiceControllers by
failure to Dispose().
Personally I wouldn't use anything asynchronous or of indeterminate length such
as net stop in a cmd shell. If you're seeing something timing-related, that may
be where the issue is. Even in C++ the code to stop a service is not
complicated and is much more manageable than a command shell.
Phil
-----Original Message-----
From: Alain Forget [mailto:afor...@cmu.edu]
Sent: Friday, June 28, 2013 7:07 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Uninstall restart issue
Yes, the cmd.exe is from a .bat file the service executes. Making it read-only
did give the uninstaller pause as it took longer before finally deciding to
still request a restart.
One of my team members pointed something out that I should have realised:
Since this problem is mainly causing problems when our software was
auto-updating itself, we can run "net stop MyServiceX" from our own client
before it runs the downloaded installer. Although this doesn't "solve" the
problem, I think it sufficiently circumvents the problem for our purposes
(especially given the ridiculous amount of time and effort we've sunken into
it, including everyone here who has so graciously helped!).
However, we now have a new problem where, during uninstall, the services are
sometimes only disabled but not removed (although other times they are removed
without problem, and I haven't figured out why it's intermittent).
This new problem seems to have begun since we started using the ServiceInstall,
and relying on the ServiceControl element to remove our
service:
<ServiceInstall
Id="svcInstMySensor1"
Name="MySensor1"
Arguments="-ini "[#fileMySensor1JslConfig]""
Description="My Sensor 1"
DisplayName=" My Sensor 1"
ErrorControl="normal"
Start="auto"
Type="ownProcess"
Vital="yes"
>
</ServiceInstall>
<ServiceControl
Id="svcMySensor1"
Name="MySensor1"
Remove="uninstall"
Start="install"
Stop="both"
Wait="yes"
/>
Before this, we used a CA to run "jsl.exe -remove MySensor1JSLConfig.ini",
which seemed to reliably remove the services every time.
Now that we've stopped using it, any running services (i.e. ones that aren't
using batch files or cmd.exe) still stop correctly, and the services are
"disabled" and do disappear if I restart the computer, but this isn't
sufficient, since when doing a silent upgrade, there is no opportunity to
restart (and "reboots are evil" anyway).
The verbose uninstall log file of when the services are not removed by the
uninstaller doesn't show much:
MSI (s) (5C:BC) [09:41:50:273]: Doing action: StopServices Action ended
09:41:50: UnpublishFeatures. Return value 1.
Action start 09:41:50: StopServices.
MSI (s) (5C:BC) [09:41:50:273]: Doing action: DeleteServices Action ended
09:41:50: StopServices. Return value 1.
Action start 09:41:50: DeleteServices.
MSI (s) (5C:BC) [09:41:50:273]: Doing action: RemoveRegistryValues Action ended
09:41:50: DeleteServices. Return value 1.
Action start 09:41:50: RemoveRegistryValues.
Looking in the .msi with Orca, there doesn't seem to be a column in the
ServiceControl table for the WiX attributes of "Start", "Stop", and
"Remove":
ServiceControl Name Event Argument Wait Component_
svcMyClient MyClient 163 1 compMyClient
svcMySensor1 MySensor1 163 1
compMySensor1JslExe
svcMySensor2 MySensor2 163 1
compMySensor2JslExe
svcMySensor3 MySensor3 163 1
compMySensor3JslExe
I didn't see anywhere else in the tables in Orca that tells the uninstaller to
remove the services, but maybe it's not stored/shown there.
Anyway, any idea why the services aren't being completely removed immediately
at uninstall, even though I have specified that they should be removed at
uninstall in the ServiceControl tags?
Alain
-----Original Message-----
From: Blair Murri [mailto:os...@live.com]
Sent: June 27, 2013 19:06
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Uninstall restart issue
Very plausible. My understanding is that basically Restart Manager sorts
processes into three groups: services (which it can see either have explicit
stop commands in the MSI or not), applications in the same desktop that have a
visible window with a title (to which it can send messages to shut it down),
and everything else. It never looks at the parentage of a process because there
is never any guarantee that a process will kill its children when it is stopped.
Its plausible that if the cmd.exe process using your files were to register
with Restart Manager for what MSFT has called "freeze dry" it wouldn't be
treated the way it is.
One other possible workaround for your scenario: if the files that are in use
are marked in the filesystem as "read only" they MAY be ignored by Restart
Manager. Is cmd.exe used because your service calls a batch script file? Try
making that batch script file read-only and see if cmd.exe at least is removed
from the list of "critical applications".
Regarding the question on CAs: All CAs should never expose their own UI,
instead using the message processing APIs that MSI provides. Deferred actions
may not run on the same desktop as the user and thus will never even be seen
(and can't be acted up) by the user, which is why it is critical that they be
"silent". The only actions that cannot use MSIs messaging apis are actions
called directly by MSI's UI (dialogs), but even they run in a sandbox that
makes it very difficult to properly interact with the MSI UI.
There is no reason that an action has to be deferred to be "silent" (most
immediate actions never show any UI) but non-deferred actions are never assumed
to alter machine state (which is why they cannot ever be rolled back, are never
given elevated privileges, and can potentially cause several unexpected side
effects if they ever do alter machine state, which is why they are discouraged
for any installer that intends to be reliable).
Blair Murri
> From: afor...@cmu.edu
> To: wix-users@lists.sourceforge.net
> Date: Thu, 27 Jun 2013 16:12:04 -0400
> Subject: Re: [WiX-users] Uninstall restart issue
>
> I have just confirmed that, when my service is running the cmd.exe
process, the RestartManager requests the restart, while otherwise, it does not.
>
> My service would immediately kill the cmd.exe process the moment the
service is asked to stop, but for whatever reason, I'm guessing the
RestartManager seems to think that the cmd.exe process is a "critical
application" and it doesn't realise that it's entirely under the control of my
service, which will stop it when requested.
>
> Does this sound plausible, given what you know about the RestartManager?
Do you know why it would just assume that cmd.exe won't be stopped by the
uninstaller (maybe because it wasn't installed by our installer)?
>
> Alain
>
> -----Original Message-----
> From: Alain Forget [mailto:afor...@cmu.edu]
> Sent: June 27, 2013 14:12
> To: 'General discussion for Windows Installer XML toolset.'
> Subject: RE: [WiX-users] Uninstall restart issue
>
> Sorry for the delay. I'm not sure I want non-elevated privileges to be
able to stop my service, but I suppose that might be a last-ditch solution.
Also, I thought for that CAs had to be marked as deferred (rather than
immediate) for them to be quietly/silently executed in the background...is that
not so? See this for more information:
>
> Below is what the Event Viewer\Windows Logs\Application -> Source:
> Restart
Manager says. What I find most interesting is the fourth entry, where the
description is "Machine restart is required.", and it points out the following
applications:
>
> <RmRestartEvent
xmlns:auto-ns2="http://schemas.microsoft.com/win/2004/08/events";
xmlns="http://www.microsoft.com/2005/08/Windows/Reliability/RestartManager/";
>
> <RmSessionId>0</RmSessionId>
> <nApplications>5</nApplications>
> <Applications>
> <Application>cmd.exe</Application>
> <Application>My Client </Application>
> <Application>My Sensor 1</Application>
> <Application>My Sensor 2</Application>
> <Application>My Sensor 3</Application>
> </Applications>
> <RebootReasons>3</RebootReasons>
> </RmRestartEvent>
>
> I don't know what a "RebootReasons" of 3 is, but it's clearly
> identified
my programs (but not the fact that they're actually services), as well as
cmd.exe, which is something one of my sensors has executed. I will do further
tests to see if it's actually what the cmd.exe is doing that's triggering the
request to reboot, but let me know if you have any other thoughts.
>
> Event Viewer Log follows:
>
> Log Name: Application
> Source: Microsoft-Windows-RestartManager
> Date: 2013-06-27 13:50:05
> Event ID: 10000
> Task Category: None
> Level: Information
> Keywords:
> User: aforget
> Computer: aforget
> Description:
> Starting session 0 - ?2013?-?06?-?27T17:50:05.048184800Z.
> Event Xml:
> <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event";>
> <System>
> <Provider Name="Microsoft-Windows-RestartManager" Guid="{SOMEGUID}" />
> <EventID>10000</EventID>
> <Version>0</Version>
> <Level>4</Level>
> <Task>0</Task>
> <Opcode>0</Opcode>
> <Keywords>0x8000000000000000</Keywords>
> <TimeCreated SystemTime="2013-06-27T17:50:05.048184800Z" />
> <EventRecordID>9756</EventRecordID>
> <Correlation />
> <Execution ProcessID="3048" ThreadID="4828" />
> <Channel>Application</Channel>
> <Computer>aforget</Computer>
> <Security UserID="SOMEID" />
> </System>
> <UserData>
> <RmSessionEvent
xmlns:auto-ns2="http://schemas.microsoft.com/win/2004/08/events";
xmlns="http://www.microsoft.com/2005/08/Windows/Reliability/RestartManager/";
>
> <RmSessionId>0</RmSessionId>
> <UTCStartTime>2013-06-27T17:50:05.048184800Z</UTCStartTime>
> </RmSessionEvent>
> </UserData>
> </Event>
>
> Log Name: Application
> Source: Microsoft-Windows-RestartManager
> Date: 2013-06-27 13:50:15
> Event ID: 10001
> Task Category: None
> Level: Information
> Keywords:
> User: aforget
> Computer: aforget
> Description:
> Ending session 0 started ?2013?-?06?-?27T17:50:05.048184800Z.
> Event Xml:
> <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event";>
> <System>
> <Provider Name="Microsoft-Windows-RestartManager" Guid="{SOMEGUID}" />
> <EventID>10001</EventID>
> <Version>0</Version>
> <Level>4</Level>
> <Task>0</Task>
> <Opcode>0</Opcode>
> <Keywords>0x8000000000000000</Keywords>
> <TimeCreated SystemTime="2013-06-27T17:50:15.219402700Z" />
> <EventRecordID>9758</EventRecordID>
> <Correlation />
> <Execution ProcessID="3048" ThreadID="3352" />
> <Channel>Application</Channel>
> <Computer>aforget</Computer>
> <Security UserID="SOMEID" />
> </System>
> <UserData>
> <RmSessionEvent
xmlns:auto-ns2="http://schemas.microsoft.com/win/2004/08/events";
xmlns="http://www.microsoft.com/2005/08/Windows/Reliability/RestartManager/";
>
> <RmSessionId>0</RmSessionId>
> <UTCStartTime>2013-06-27T17:50:05.048184800Z</UTCStartTime>
> </RmSessionEvent>
> </UserData>
> </Event>
>
> Log Name: Application
> Source: Microsoft-Windows-RestartManager
> Date: 2013-06-27 13:50:24
> Event ID: 10000
> Task Category: None
> Level: Information
> Keywords:
> User: aforget
> Computer: aforget
> Description:
> Starting session 0 - ?2013?-?06?-?27T17:50:24.860219600Z.
> Event Xml:
> <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event";>
> <System>
> <Provider Name="Microsoft-Windows-RestartManager" Guid="{SOMEGUID}" />
> <EventID>10000</EventID>
> <Version>0</Version>
> <Level>4</Level>
> <Task>0</Task>
> <Opcode>0</Opcode>
> <Keywords>0x8000000000000000</Keywords>
> <TimeCreated SystemTime="2013-06-27T17:50:24.860219600Z" />
> <EventRecordID>9762</EventRecordID>
> <Correlation />
> <Execution ProcessID="3048" ThreadID="2524" />
> <Channel>Application</Channel>
> <Computer>aforget</Computer>
> <Security UserID="SOMEID" />
> </System>
> <UserData>
> <RmSessionEvent
xmlns:auto-ns2="http://schemas.microsoft.com/win/2004/08/events";
xmlns="http://www.microsoft.com/2005/08/Windows/Reliability/RestartManager/";
>
> <RmSessionId>0</RmSessionId>
> <UTCStartTime>2013-06-27T17:50:24.860219600Z</UTCStartTime>
> </RmSessionEvent>
> </UserData>
> </Event>
>
> Log Name: Application
> Source: Microsoft-Windows-RestartManager
> Date: 2013-06-27 13:50:25
> Event ID: 10005
> Task Category: None
> Level: Information
> Keywords:
> User: aforget
> Computer: aforget
> Description:
> Machine restart is required.
> Event Xml:
> <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event";>
> <System>
> <Provider Name="Microsoft-Windows-RestartManager" Guid="{SOMEGUID}" />
> <EventID>10005</EventID>
> <Version>0</Version>
> <Level>4</Level>
> <Task>0</Task>
> <Opcode>0</Opcode>
> <Keywords>0x8000000000000000</Keywords>
> <TimeCreated SystemTime="2013-06-27T17:50:25.000619800Z" />
> <EventRecordID>9763</EventRecordID>
> <Correlation />
> <Execution ProcessID="3048" ThreadID="2524" />
> <Channel>Application</Channel>
> <Computer>aforget</Computer>
> <Security UserID="SOMEID" />
> </System>
> <UserData>
> <RmRestartEvent
xmlns:auto-ns2="http://schemas.microsoft.com/win/2004/08/events";
xmlns="http://www.microsoft.com/2005/08/Windows/Reliability/RestartManager/";
>
> <RmSessionId>0</RmSessionId>
> <nApplications>5</nApplications>
> <Applications>
> <Application>cmd.exe</Application>
> <Application>My Client </Application>
> <Application>My Sensor 1</Application>
> <Application>My Sensor 2</Application>
> <Application>My Sensor 3</Application>
> </Applications>
> <RebootReasons>3</RebootReasons>
> </RmRestartEvent>
> </UserData>
> </Event>
>
> Log Name: Application
> Source: Microsoft-Windows-RestartManager
> Date: 2013-06-27 13:50:34
> Event ID: 10001
> Task Category: None
> Level: Information
> Keywords:
> User: aforget
> Computer: aforget
> Description:
> Ending session 0 started ?2013?-?06?-?27T17:50:24.860219600Z.
> Event Xml:
> <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event";>
> <System>
> <Provider Name="Microsoft-Windows-RestartManager" Guid="{SOMEGUID}" />
> <EventID>10001</EventID>
> <Version>0</Version>
> <Level>4</Level>
> <Task>0</Task>
> <Opcode>0</Opcode>
> <Keywords>0x8000000000000000</Keywords>
> <TimeCreated SystemTime="2013-06-27T17:50:34.743837800Z" />
> <EventRecordID>9767</EventRecordID>
> <Correlation />
> <Execution ProcessID="3048" ThreadID="3352" />
> <Channel>Application</Channel>
> <Computer>aforget</Computer>
> <Security UserID="SOMEID" />
> </System>
> <UserData>
> <RmSessionEvent
xmlns:auto-ns2="http://schemas.microsoft.com/win/2004/08/events";
xmlns="http://www.microsoft.com/2005/08/Windows/Reliability/RestartManager/";
>
> <RmSessionId>0</RmSessionId>
> <UTCStartTime>2013-06-27T17:50:24.860219600Z</UTCStartTime>
> </RmSessionEvent>
> </UserData>
> </Event>
>
>
> -----Original Message-----
> From: Blair [mailto:os...@live.com]
> Sent: June 26, 2013 09:17
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Uninstall restart issue
>
> It also requires that the service is setup to allow non-elevated
privileges to stop it.
>
> Event Viewer\Windows Logs\Application
> Source: RestartManager
>
> -----Original Message-----
> From: Joel Budreau
> Sent: Tuesday, June 25, 2013 6:22 PM
> To: afor...@cmu.edu ; General discussion for Windows Installer XML
toolset.
> Subject: Re: [WiX-users] Uninstall restart issue
>
> Hey Alain,
>
> Take a look at my answer to this problem on stackoverflow -
> http://stackoverflow.com/questions/6913332/wix-installer-problem-why-d
> oes-restartmanager-mark-service-as-rmcritical-and-no/8147540#8147540
>
> Basically, you can 'lie' about the custom action and mark it as
> immediate
instead of deferred. The drawback is that if your install fails and rollsback,
the service you've shut down will still be shut down. Up to you whether or not
that's an appropriate risk for your product.
>
> - Joel
>
> On Sat, Jun 15, 2013 at 11:11 AM, Alain Forget <afor...@cmu.edu> wrote:
> > I'm still wrestling with this request to restart on uninstall. To
> > recap, I have an MSI that when I install it, and then try to
> > uninstall it, it usually tells the user that some of the files to be
> > uninstalled are in use and will require a reboot. However, this
> > should not be, because the services that are using the files will
> > stop
immediately upon request.
> >
> > The problem seems to be that the installer is making the
> > determination that the files are in use before even trying to stop
> > services. Looking at the uninstall log, during FileCost, the
> > installer determines that multiple "folder had been blocked by the 1
> > mask argument (the folder pair's iSwapAttrib member = 0)", which I
> > think
means it's in use?
> > Furthermore, at InstallValidate, "RESTART MANAGER: Did detect that a
> > critical application holds file[s] in use, so a reboot will be
> > necessary." Note that both InstallValidate and FileCost come before
> > StopServices (see http://msdn.microsoft.com/en-us/library/aa372038).
> >
> > It had been suggested that I should stop the services myself with
> > "net stop". So I attempted to do so with this in my .wxs:
> >
> > <!-- Silently stop my services (with elevated privileges;
> > Execute="deferred", see
> > http://wix.sourceforge.net/manual-wix3/qtexec.htm ) -->
> > <CustomAction Id="Set_cmdStopMyService"
> > Property="cmdStopClientCommModuleService" Value="net stop
> > [#myService]" /> <CustomAction Id="cmdStopMyService" Execute="deferred"
BinaryKey="WixCA"
> > DllEntry="CAQuietExec" Return="check" Impersonate="no" />
> >
> > <InstallExecuteSequence>
> > <Custom Action="Set_cmdStopMyService" Before="CostInitialize"
> > ></Custom>
> > <Custom Action="cmdStopMyService" Before="CostInitialize"
> > ></Custom>
> > </InstallExecuteSequence>
> >
> > However, candle / light don't allow it:
> >
> > error LGHT0204 : ICE77: cmdStopMyService is a in-script custom action.
> > It must be sequenced in between the InstallInitialize action and the
> > InstallFinalize action in the InstallExecuteSequence table
> >
> > Following Light's recommendation wouldn't solve my problem, because
> > InstallInitialze happens long after the uninstaller has decided that
> > the files are in use.
> >
> > So I'm completely stumped and would appreciate some suggestions.
> >
> > Alain
> >
> >
> >
> > --------------------------------------------------------------------
> > --
> > -------- This SF.net email is sponsored by Windows:
> >
> > Build for Windows Store.
> >
> > http://p.sf.net/sfu/windows-dev2dev
> > _______________________________________________
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
>
> ----------------------------------------------------------------------
> -------- This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> ----------------------------------------------------------------------
> -------- This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> ----------------------------------------------------------------------
> -------- This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
----------------------------------------------------------------------------
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
----------------------------------------------------------------------------
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
----------------------------------------------------------------------------
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
----------------------------------------------------------------------------
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
