4592 - RestartResource solution and review

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

4592 - RestartResource solution and review

Phill Hogland
Based on helpful input from Jacob and the folks in the meeting today, I adopted Bob's method of building changes by deleting the output 'build' folder and running a build of wix.proj, (because while wixca.dll was being built with changes, WixUtilExtension.dll was not being updated).  It takes a little more than the reported 32 seconds (Time Elapsed 00:07:53.98) and gives me more time to ponder my next move if the change fails to do what I want it to.  Also in the middle of this research for some reason in VS2013, F9 stopped adding Breakpoints, but right-clicking and selecting Insert Breakpoint still works.

The core problem is that when another process is running under a different user account, the process calling OpenProcess must have SeDebugPrivilege.  This is true even if PROCESS_QUERY_LIMITED_INFORMATION were used.

I resolved the problem by lifting code from serviceconfig.cpp ConfigService() (which added SeShutdownPrivilege), and modified it to add SeDebugPrivilege.  Initially I also followed the approach in ConfigService() to removed the SeDebugPrivilege, however after stepping through the problem area successfully and returning to the disassembler, a fault is hit again later and the error reports the fault as the same CA.  When I removed the code to reset the privilege this later fault is not observed and the setup succeeds.

I have tested this several times with my scenario which includes targeting a tray app launched under NetworkService account.  I have not succeeded in building an 'Official' Release build yet, so there are other operating system scenarios to test.  I have VS2010, 2012, and 2013 installed, but it fails, so I need to track down the missing SDK or whatever the issue is.

Thank you Jacob for the pointers on using git/github.  The next steps in that email are:
<Add/Commit your changes> 
<Push your changes to origin (your fork)> 
<Submit a pull request from github> 
 
It looks like the github app has a link that will do the 'commit'.  And then they have a 'publish' button.  Should I do any of these steps so you folks can review the changes and let me know if I should make additional changes (in parallel with or before) figuring our how to test these changes on other OS/test configurations.  Do you see any problem with not removing the SeDebugPrivilege for the remainder of the life of this CA process?  Or do you have any insight on how to narrow down what is happening later which apparently also needs SeDebugPrivilege or fails?

Also I tried to run test.bat but it reports lots of failures, so I assume that is related to whatever is missing and causes a Release build to fail.
Tests:22 Failures 5
RegisterArpMinimumTest, RegisterArpFullTest, etc.

Thanks for the help.
Reply | Threaded
Open this post in threaded view
|

Re: 4592 - RestartResource solution and review

Phill Hogland
In thinking about this on the ride home, I suspect the code change I implemented will be a problem for per-user scenarios.  The added code to change permissions must be called from an elevated process.  So if it is likely that a per-user setup would call util:RestartResources then I need to detect a non-elevated setup and take the second option discussed in the meeting and log a reason to skip the registration and continue on.
Reply | Threaded
Open this post in threaded view
|

Re: [SPAM] 4592 - RestartResource solution and review

Hoover, Jacob
In reply to this post by Phill Hogland
As far as your workflow/process, I prefer to commit/push early and often on feature branches.  Then once I get to the point of thinking my changes are "stable", I'll create a new feature branch that is a squashed commit of all the working commits of the original feature branch. This allows you to save your progress, and to provide a clean history when the pull request is merged into the wixtoolset. (Note, Rob/Bob could do squashed merges but I prefer to make the original pull request as easy as possible for them.)

If you're talking about tests in 4.x, lots of them are broken.  Not sure of the 3.x status on the test.

-----Original Message-----
From: Phill Hogland [mailto:[hidden email]]
Sent: Thursday, November 20, 2014 6:13 PM
To: [hidden email]
Subject: [WiX-devs] [SPAM] 4592 - RestartResource solution and review

Based on helpful input from Jacob and the folks in the meeting today, I adopted Bob's method of building changes by deleting the output 'build'
folder and running a build of wix.proj, (because while wixca.dll was being built with changes, WixUtilExtension.dll was not being updated).  It takes a little more than the reported 32 seconds (Time Elapsed 00:07:53.98) and gives me more time to ponder my next move if the change fails to do what I want it to.  Also in the middle of this research for some reason in VS2013,
F9 stopped adding Breakpoints, but right-clicking and selecting Insert Breakpoint still works.

The core problem is that when another process is running under a different user account, the process calling OpenProcess must have SeDebugPrivilege.
This is true even if PROCESS_QUERY_LIMITED_INFORMATION were used.

I resolved the problem by lifting code from serviceconfig.cpp
ConfigService() (which added SeShutdownPrivilege), and modified it to add SeDebugPrivilege.  Initially I also followed the approach in ConfigService() to removed the SeDebugPrivilege, however after stepping through the problem area successfully and returning to the disassembler, a fault is hit again later and the error reports the fault as the same CA.  When I removed the code to reset the privilege this later fault is not observed and the setup succeeds.

I have tested this several times with my scenario which includes targeting a tray app launched under NetworkService account.  I have not succeeded in building an 'Official' Release build yet, so there are other operating system scenarios to test.  I have VS2010, 2012, and 2013 installed, but it fails, so I need to track down the missing SDK or whatever the issue is.

Thank you Jacob for the pointers on using git/github.  The next steps in that email are:
<Add/Commit your changes>
<Push your changes to origin (your fork)> <Submit a pull request from github>
 
It looks like the github app has a link that will do the 'commit'.  And then they have a 'publish' button.  Should I do any of these steps so you folks can review the changes and let me know if I should make additional changes (in parallel with or before) figuring our how to test these changes on other OS/test configurations.  Do you see any problem with not removing the SeDebugPrivilege for the remainder of the life of this CA process?  Or do you have any insight on how to narrow down what is happening later which apparently also needs SeDebugPrivilege or fails?

Also I tried to run test.bat but it reports lots of failures, so I assume that is related to whatever is missing and causes a Release build to fail.
Tests:22 Failures 5
RegisterArpMinimumTest, RegisterArpFullTest, etc.

Thanks for the help.



--
View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/4592-RestartResource-solution-and-review-tp7598149.html
Sent from the wix-devs mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: [SPAM] Re: 4592 - RestartResource solution and review

Hoover, Jacob
In reply to this post by Phill Hogland
Is this a problem in a per-user install?  If it's pe- user, how would the offending process be running in a context other than the user?

-----Original Message-----
From: Phill Hogland [mailto:[hidden email]]
Sent: Thursday, November 20, 2014 8:02 PM
To: [hidden email]
Subject: [WiX-devs] [SPAM] Re: 4592 - RestartResource solution and review

In thinking about this on the ride home, I suspect the code change I implemented will be a problem for per-user scenarios.  The added code to change permissions must be called from an elevated process.  So if it is likely that a per-user setup would call util:RestartResources then I need to detect a non-elevated setup and take the second option discussed in the meeting and log a reason to skip the registration and continue on.




--
View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/4592-RestartResource-solution-and-review-tp7598149p7598150.html
Sent from the wix-devs mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: [SPAM] Re: 4592 - RestartResource solution and review

Phill Hogland
This post was updated on .
Thanks for the comments on the workflow.

My post last night about a potential problem with per-user was speculation.  This morning I tested the per-machine msi, without using the bundle, and it shows the same problem I expected for per-user.  So I set aside the per-user concern and am focused on the per-machine msi only scenario.

The per-machine (and I assume also a per-user) msi implements
<util:RestartResource ProcessName="AppName.exe"/>  (which may not be an app that is even in the msi package)

The problem is that the WixRegisterRestartResources CA gets a list of all process IDs and attempts to open any process ID which has the above app name, without regard to the user context that the process is running under.  (In my particular situation AppName.exe is a tray app which may have many instances running under the same or different users, and when there is one running under a different user, the CA fails at the OpenProcess call.)  Yesterday I implemented a fix for that problem, which works for my situation, but which did not consider that the test scenario I was using, with a bundle, was running the msi elevated.  Today I am refactoring to consider the situation where the msi is not elevated.  I am beginning to believe that the WixRegisterRestartResources functionality which does the registration code (RmuAddProcessesByName), should be in a deferred CA rather than an immediate CA.

Also I am working against the 3.10 develop branch/forks.
Reply | Threaded
Open this post in threaded view
|

Re: [SPAM] Re: 4592 - RestartResource solution and review

Phill Hogland
I have installed vs2010, vs2012, and vs2013, and related sdks in an effort to build the wix 3.10 (from several weeks ago) as an OFFICIAL build.  I also installed Sandcastle Help File Builder and Tools, however the wix3 build fails indicating that Sandcastle must be installed.

In looking at WixBuild.props, the issue is that the path $(ProgramFiles)\Sandcastle does not exist.  The other paths to SandcastleHelpFileBuilder.targets does exist in <ProgramFiles(x86)>\EWSoftware....

I re-ran the Sandcastle Guided Installer.  The Sandcastle Tools help is installed which indicates that while the tools are separate they are included in the Sandcastle Guided Installer and maintained as part of the Sandcastle Help File Builder project.

Any advice on how to resolve this issue and proceed with a wix3 official build (to test 4592)?
Reply | Threaded
Open this post in threaded view
|

Re: [SPAM] Re: [SPAM] Re: 4592 - RestartResource solution and review

Blair Murri-3
IIRC an older version of Sandcastle had to be used.
 
We put some instructions in the wix.chm somewhere...
 
> Date: Sat, 22 Nov 2014 17:52:51 -0700

> From: [hidden email]
> To: [hidden email]
> Subject: [WiX-devs] [SPAM] Re: [SPAM] Re: 4592 - RestartResource solution and review
>
> I have installed vs2010, vs2012, and vs2013, and related sdks in an effort to
> build the wix 3.10 (from several weeks ago) as an OFFICIAL build. I also
> installed Sandcastle Help File Builder and Tools, however the wix3 build
> fails indicating that Sandcastle must be installed.
>
> In looking at WixBuild.props, the issue is that the path
> $(ProgramFiles)\Sandcastle does not exist. The other paths to
> SandcastleHelpFileBuilder.targets does exist in
> <ProgramFiles(x86)>\EWSoftware....
>
> I re-ran the Sandcastle Guided Installer. The Sandcastle Tools help is
> installed which indicates that while the tools are separate they are
> included in the Sandcastle Guided Installer and maintained as part of the
> Sandcastle Help File Builder project.
>
> Any advice on how to resolve this issue and proceed with a wix3 official
> build (to test 4592)?
>
>
>
> --
> View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/4592-RestartResource-solution-and-review-tp7598149p7598205.html
> Sent from the wix-devs mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
> _______________________________________________
> WiX-devs mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-devs

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: [SPAM] 4592 - RestartResource solution and review

Rob Mensching-7
In reply to this post by Hoover, Jacob
When rebasing, I usually just set a tag (so I can hard reset if the rebase goes awry), do the interactive rebase, then if all is well, delete the tag. Avoids switch branches when I'm just cleaning up in place.

_______________________________________________________________
 FireGiant  |  Dedicated support for the WiX toolset  |  http://www.firegiant.com/

-----Original Message-----
From: Hoover, Jacob [mailto:[hidden email]]
Sent: Friday, November 21, 2014 8:30 AM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] [SPAM] 4592 - RestartResource solution and review

As far as your workflow/process, I prefer to commit/push early and often on feature branches.  Then once I get to the point of thinking my changes are "stable", I'll create a new feature branch that is a squashed commit of all the working commits of the original feature branch. This allows you to save your progress, and to provide a clean history when the pull request is merged into the wixtoolset. (Note, Rob/Bob could do squashed merges but I prefer to make the original pull request as easy as possible for them.)

If you're talking about tests in 4.x, lots of them are broken.  Not sure of the 3.x status on the test.

-----Original Message-----
From: Phill Hogland [mailto:[hidden email]]
Sent: Thursday, November 20, 2014 6:13 PM
To: [hidden email]
Subject: [WiX-devs] [SPAM] 4592 - RestartResource solution and review

Based on helpful input from Jacob and the folks in the meeting today, I adopted Bob's method of building changes by deleting the output 'build'
folder and running a build of wix.proj, (because while wixca.dll was being built with changes, WixUtilExtension.dll was not being updated).  It takes a little more than the reported 32 seconds (Time Elapsed 00:07:53.98) and gives me more time to ponder my next move if the change fails to do what I want it to.  Also in the middle of this research for some reason in VS2013,
F9 stopped adding Breakpoints, but right-clicking and selecting Insert Breakpoint still works.

The core problem is that when another process is running under a different user account, the process calling OpenProcess must have SeDebugPrivilege.
This is true even if PROCESS_QUERY_LIMITED_INFORMATION were used.

I resolved the problem by lifting code from serviceconfig.cpp
ConfigService() (which added SeShutdownPrivilege), and modified it to add SeDebugPrivilege.  Initially I also followed the approach in ConfigService() to removed the SeDebugPrivilege, however after stepping through the problem area successfully and returning to the disassembler, a fault is hit again later and the error reports the fault as the same CA.  When I removed the code to reset the privilege this later fault is not observed and the setup succeeds.

I have tested this several times with my scenario which includes targeting a tray app launched under NetworkService account.  I have not succeeded in building an 'Official' Release build yet, so there are other operating system scenarios to test.  I have VS2010, 2012, and 2013 installed, but it fails, so I need to track down the missing SDK or whatever the issue is.

Thank you Jacob for the pointers on using git/github.  The next steps in that email are:
<Add/Commit your changes>
<Push your changes to origin (your fork)> <Submit a pull request from github>
 
It looks like the github app has a link that will do the 'commit'.  And then they have a 'publish' button.  Should I do any of these steps so you folks can review the changes and let me know if I should make additional changes (in parallel with or before) figuring our how to test these changes on other OS/test configurations.  Do you see any problem with not removing the SeDebugPrivilege for the remainder of the life of this CA process?  Or do you have any insight on how to narrow down what is happening later which apparently also needs SeDebugPrivilege or fails?

Also I tried to run test.bat but it reports lots of failures, so I assume that is related to whatever is missing and causes a Release build to fail.
Tests:22 Failures 5
RegisterArpMinimumTest, RegisterArpFullTest, etc.

Thanks for the help.



--
View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/4592-RestartResource-solution-and-review-tp7598149.html
Sent from the wix-devs mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: [SPAM] Re: [SPAM] Re: 4592 - RestartResource solution and review

Bob Arnson-6
In reply to this post by Blair Murri-3
On 25-Nov-14 00:48, Blair Murri wrote:
IIRC an older version of Sandcastle had to be used.
Sean just fixed that.
-- 
sig://boB
http://joyofsetup.com/

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: [SPAM] Re: [SPAM] Re: 4592 - RestartResource solution and review

Phill Hogland
Thanks Blair and Bob.  When I try to download Sandcastle from the Codeplex site, it just hangs and never completes the download.  The May 2008, which is documented in the chm, fails to download.
https://sandcastle.codeplex.com/releases/view/13873

(I also tried the other (June 2010) downloads at sandcastle.codeplex.com and they also fail to download.)

However I also found this download site which 'worked':
http://www.microsoft.com/en-us/download/confirmation.aspx?id=10526

After installation I was able to get a Wix Offical build to complete successfully.  So thanks for the help.  Now off to use the build in testing.
Reply | Threaded
Open this post in threaded view
|

Re: [SPAM] Re: [SPAM] Re: 4592 - RestartResource solution and review

Phill Hogland
As I reported, I succeeded in creating an "unofficial Official" build, in the sense that it did a full compile without any errors or skipping any part of the build. This gets me back to the point where if I recompile both my compiler extensions and my project tree of msi setups and bundles against this "unofficial Official" build the mba cannot display the UX on another system. It creates the UX on the system where it was compiled.  Prior to this I created a test case using WixStdBA, made the necessary changes to address 4592, and tested that debug build on Windows 7 x64 and Windows 8 x64.

The reason I am trying to do an "unofficial Official" build is because of the following statement and an effort to do thorough testing.  From: http://wixtoolset.org/development/
"Code your change and test it. Review our code style and write consistent code throughout the project. Remember to build WiX in both debug and release modes, and to run test\test.bat to make sure nothing is broken."

There is a link in the above text at 'build', wich says:
Official builds with strong-name signing
Strong-name signing a WiX build lets it be used on a machine other than the one used to build WiX. Creating an "official unofficial" WiX build requires all the above prerequisites; you can't skip parts of an official build. In general, it's a lot easier to submit a pull request and get the next interim build of WiX.

To create a build that can be installed on different machines, create a new strong name key pair and point OFFICIAL_WIX_BUILD to it:

sn -k wix.snk
sn -p wix.snk wix.pub
sn -tp wix.pub
Copy the public key and add new InternalsVisibleTo attributes in src\Votive\votive2010\vssdk\AssemblyInfo.cs. Then run the build:

msbuild /p:Configuration=Release /p:OFFICIAL_WIX_BUILD=C:\wix.snk

So how should I proceed with testing this issue?  Try figure out why I am having issues creating an "Official Unofficial" build or (figure out the prior discussion about rebasing) and submit a pull request?

Also I ran the test\test.bat again and observed the same red results reported previously.  The tests are still running with warnings that runtime tests are not enabled.  Should they be?  Most tests have an exit code of 0, but there are some other result codes.  I'm not confident that I understand what to expect. (And eventually I got the "MSBuild has stopped working" dialog just like last time.)

Thanks for any advice!
Reply | Threaded
Open this post in threaded view
|

Re: [SPAM] Re: [SPAM] Re: 4592 - RestartResource solution and review

Bob Arnson-6
On 03-Dec-14 11:13, Phill Hogland wrote:
> As I reported, I succeeded in creating an "unofficial Official" build, in the
> sense that it did a full compile without any errors or skipping any part of
> the build. This gets me back to the point where if I recompile both my
> compiler extensions and my project tree of msi setups and bundles against
> this "unofficial Official" build the mba cannot display the UX on another
> system.
Is the BA compiled against it too? As I recall, the MBA stuff is
strong-name signed so a managed BA will fail to load against a
locally-built MBA core.

> The reason I am trying to do an "unofficial Official" build is because of
> the following statement and an effort to do thorough testing.  From:
> http://wixtoolset.org/development/
> "Code your change and test it. Review our code style and write consistent
> code throughout the project. Remember to build WiX in both debug and release
> modes, and to run test\test.bat to make sure nothing is broken."
It's a judgment call as to whether a particular change needs to go
through an official build. Some do, certainly, but most don't. A custom
action change is unlikely to be affected by anything related to a
managed BA build, for example, though it might be affected by being run
in a bundle with a managed BA -- theoretically, anyway; I wouldn't bet
money on that. :) In this case, an easy workaround would be to build the
.msi with the updated CA from a local WiX build but build the MBA and
bundle from an official build.

--
sig://boB
http://joyofsetup.com/


------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: [SPAM] Re: [SPAM] Re: 4592 - RestartResource solution and review

SeanHall
I would also guess that the MBA is not compiled against the locally built BootstrapperCore.dll.  But why guess?  The error code should be in the Burn log, and you can use Fusion logging as well.

As a side note, why is that Building Wix page different than the Building Wix in the chm?

On Wed, Dec 3, 2014 at 6:52 PM, Bob Arnson <[hidden email]> wrote:
On 03-Dec-14 11:13, Phill Hogland wrote:
> As I reported, I succeeded in creating an "unofficial Official" build, in the
> sense that it did a full compile without any errors or skipping any part of
> the build. This gets me back to the point where if I recompile both my
> compiler extensions and my project tree of msi setups and bundles against
> this "unofficial Official" build the mba cannot display the UX on another
> system.
Is the BA compiled against it too? As I recall, the MBA stuff is
strong-name signed so a managed BA will fail to load against a
locally-built MBA core.

> The reason I am trying to do an "unofficial Official" build is because of
> the following statement and an effort to do thorough testing.  From:
> http://wixtoolset.org/development/
> "Code your change and test it. Review our code style and write consistent
> code throughout the project. Remember to build WiX in both debug and release
> modes, and to run test\test.bat to make sure nothing is broken."
It's a judgment call as to whether a particular change needs to go
through an official build. Some do, certainly, but most don't. A custom
action change is unlikely to be affected by anything related to a
managed BA build, for example, though it might be affected by being run
in a bundle with a managed BA -- theoretically, anyway; I wouldn't bet
money on that. :) In this case, an easy workaround would be to build the
.msi with the updated CA from a local WiX build but build the MBA and
bundle from an official build.

--
sig://boB
http://joyofsetup.com/


------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs


------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

4592 - RestartResource solution and review

Phill Hogland
Thanks again for the ideas.

The log states:
[0FFC:0FD4][2014-12-01T14:33:12]i000: Loading managed bootstrapper application.
[0FFC:0FD4][2014-12-01T14:33:12]e000: Error 0x8013141a: Failed to create the managed bootstrapper application.
[0FFC:0FD4][2014-12-01T14:33:12]e000: Error 0x8013141a: Failed to create UX.
[0FFC:0FD4][2014-12-01T14:33:12]e000: Error 0x8013141a: Failed to load UX.
[0FFC:0FD4][2014-12-01T14:33:12]e000: Error 0x8013141a: Failed while running

As I am writing this I noticed the following, which is strange because my bundles and msi packages are always per-machine.
[0FFC:0FD4][2014-12-01T14:33:12]e000: Error 0x8013141a: Failed to run per-user mode.
[0FFC:0FD4][2014-12-01T14:33:12]i007: Exit code: 0x8013141a, restarting: No

I will look into Fusion Logging but I will also look at the other suggestions.  And Bob's idea to only compile the package against the new build, is what I have done in the past.  I don't know why I did not think of that this time, and try that first.  I'm sure that will work as I agree that there is no link between the 4592 changes and the BA loading issue, except creating the unofficial official build.

When including an mba.dll as a bootstrapper payload, most examples that I have seen just include the mba.dll (and any specific dependency dlls that I also added).  However the mba.dll project output folder also has a lot of wix and microsoft 'framework' dlls, like bootstraperCore.dll.  Should I specifically add payload elements for each of those DLLs, xml (and I suppose optionally pdb) files to my bundle?  I have not been doing that, but I did try that a while back and did not think it made any difference.

Sean, I agree with your question bout the chm.  I concluded that the text under "Hacking" at https://github.com/wixtoolset/wix3 was newer and different than the information that is in the wix manual (either online or in the chm). so I was trying to use the github info, and referring to the chm for more info.  I think the 4592 change is pretty simple and tested with WixStdBA, but I use it in projects with a mba and was trying to test those projects prior to submitting the change.  The whole process of fixing a bug, and submitting the change is a learning process that I have been wanting to tackle for some time.  But there are still some bumps that I need to figure out.
Reply | Threaded
Open this post in threaded view
|

Re: 4592 - RestartResource solution and review

Bob Arnson-6
On 04-Dec-14 09:48, Phill Hogland wrote:
> When including an mba.dll as a bootstrapper payload, most examples that I
> have seen just include the mba.dll (and any specific dependency dlls that I
> also added).  However the mba.dll project output folder also has a lot of
> wix and microsoft 'framework' dlls, like bootstraperCore.dll.  Should I
> specifically add payload elements for each of those DLLs, xml (and I suppose
> optionally pdb) files to my bundle?  I have not been doing that, but I did
> try that a while back and did not think it made any difference.
If you use

<BootstrapperApplicationRef Id='ManagedBootstrapperApplicationHost'>

you get the core MBA files automatically.

--
sig://boB
http://joyofsetup.com/


------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: 4592 - RestartResource solution and review

Phill Hogland
OK thanks Bob, that is what I have been doing.  I have a couple of more OS configurations that I want to test.  I figured out Rob's rebase suggestion and squashed my commits.  So when I complete the testing I will take a shot at the pull request steps.

There have been other changes to the 3.10 develop since I started this.  Should I also do some steps to update the fork before doing the pull request?  I noticed that the instructions that Jacob gave me for getting those changes earlier were predicated on not having made any changes on my end yet.  So I am not sure of those steps are correct now that I have commits.
Reply | Threaded
Open this post in threaded view
|

Re: 4592 - RestartResource solution and review

Phill Hogland
I submitted a pull request.  I am still a little confused on the process so please let me know what I should do different.  Thanks for all of the assistance!
Reply | Threaded
Open this post in threaded view
|

Re: 4592 - RestartResource solution and review

Bob Arnson-6
On 09-Dec-14 13:12, Phill Hogland wrote:
> I submitted a pull request.  I am still a little confused on the process so
> please let me know what I should do different.  Thanks for all of the
> assistance!
The pull request was fine -- there were no conflicting changes so you
didn't have to rebase. I left a few comments, mostly about style. A
couple of other things I wanted to bring up here for discussion:

- Taking the debug privilege seems heavy-handed. Do we always want to
try to tell RM about processes from other users or should it be opt-in
(i.e., an attribute that turns on "try really hard").
- Because MSI reuses custom action hosts, I think that regardless of
which privileges are used, we have to restore them to their original set.

--
sig://boB
http://joyofsetup.com/


------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: 4592 - RestartResource solution and review

SeanHall
The whole point is to avoid reboots, right?  So I would think you would always want to tell RM about processes from other users.

My only problem with the pull request (aside from Bob's comments) is that the method used to do something even if it wasn't elevated, but that won't happen anymore.  I think enabling the debug privilege should be best effort (access denied errors shouldn't be fatal).

On Tue, Dec 9, 2014 at 2:02 PM, Bob Arnson <[hidden email]> wrote:
On 09-Dec-14 13:12, Phill Hogland wrote:
> I submitted a pull request.  I am still a little confused on the process so
> please let me know what I should do different.  Thanks for all of the
> assistance!
The pull request was fine -- there were no conflicting changes so you
didn't have to rebase. I left a few comments, mostly about style. A
couple of other things I wanted to bring up here for discussion:

- Taking the debug privilege seems heavy-handed. Do we always want to
try to tell RM about processes from other users or should it be opt-in
(i.e., an attribute that turns on "try really hard").
- Because MSI reuses custom action hosts, I think that regardless of
which privileges are used, we have to restore them to their original set.

--
sig://boB
http://joyofsetup.com/


------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs


------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: 4592 - RestartResource solution and review

Phill Hogland
Thank you for the comments.  

My understanding of the guidance in the meeting when 4592 was triaged, was to see if changing a permission would resolve the failure, and if not make a change so that the failure is no longer treated as a failure, but as a logged, sorry could not do the request, and continue.

I had not thought of the opt-in approach.  I could work on some attribute that would control this behavior if you like.

>>the method used to do something even if it wasn't elevated, but that won't happen anymore
Yes you are correct and that is wrong.  I will work on that.

But do you want me to work on adding an attribute also?

What do you want me to do in regard to the fact that removing the SeDebugPrivlege at the end of RmuAddProcessById still results in rollback.  In my own products (which will ship before this is completed and merged), I removed the attempt to use the RM for this application, because of this one scenario.  That is an acceptable change in my situation and is better than introducing any complexity into the framework.  There are typically several instances of this application running under the user, and only occasionally another instance running under another user (which causes the rollback if the RM is used).

Thoughts?
12