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
