Windows mkbuildmachine failures

[rossphilipson]

1. The download step for Wix is pulling down some HTML page rather than the Wix installer and renaming it to wix.exe. It then runs this which just hangs up the install process forever. The Wix URL probably just needs tweaking. The workaround is to stub out the download step and download it manually to the temp location.
2. The installation of WDK8 fails with error code -2147023294 (0x80070642). For some reason, starting wdksetup.exe spawns 2 processes, which stay there for a while and disappear, which may be part of the problem.

[aikidokatech]

Altering the user agent can fix this. I have an example on my build box
when I reworked that script.
On Aug 19, 2014 3:53 PM, "Ross Philipson" notifications@github.com wrote:

The download step for Wix is pulling down some HTML page rather than the
Wix installer and renaming it to wix.exe. It then runs this which just
hangs up the install process forever. The Wix URL probably just needs
tweaking. The workaround is to stub out the download step and download it
manually to the temp location.

—
Reply to this email directly or view it on GitHub
#27.

[rossphilipson]

Adam, is that something we can check in to fix the problem?

[dotdashnotdot]

No idea I'm afraid, we always downloaded from a local server so have no experience on the automated public wix download sorry

[stefanopanella]

When I was working on that I was using this URL:
http://download-codeplex.sec.s-msft.com/Download/Release?ProjectName=wix&DownloadId=762937&FileTime=130301249344430000&Build=20928

the problem with it was that if put in the XML, the parsing library was failing decoding the "&"

[rossphilipson]

Adam L. - I was actually asking Adam O. that question.
Stefano - I played at length with that url in a shell with wget last night and could not get it to work right.

[rossphilipson]

Ok I see what the problem is now. The script uses:

"http://download-codeplex.sec.s-msft.com/Download/Release?ProjectName=wix&DownloadId=762937&FileTime=130301249344430000&Build=20911"

but the build number has changed to what Stefano pasted in above. If I wget his url I get the Wix package. I guess I can just change it but this seems a rather un-maintainable way to do this. Unfortunately I cannot figure out another way.

[aikidokatech]

I ran into issues with the redirection due to the default user agent string
used. I did not check what is used in the new build machine prep scripts
but this is what I used for wix that worked. Sourceforge then had an issue
with this one..

$request.UserAgent = "Mozilla/5.0 (Windows NT; Windows NT 6.1; en-US)
WindowsPowerShell/3.0"

On Wed, Aug 20, 2014 at 2:49 PM, Ross Philipson notifications@github.com
wrote:

Ok I see what the problem is now. The script uses:

"
http://download-codeplex.sec.s-msft.com/Download/Release?ProjectName=wix&DownloadId=762937&FileTime=130301249344430000&Build=20911
"

but the build number has changed to what Stefano pasted in above. If I
wget his url I get the Wix package. I guess I can just change it but this
seems a rather un-maintainable way to do this. Unfortunately I cannot
figure out another way.

—
Reply to this email directly or view it on GitHub
#27 (comment).

[dickon]

If Microsoft keep changing their URLs like that perhaps we'll need to simply ask people to supply binaries given instructions on how to search for them on the Microsoft site.

[rossphilipson]

Tracking #1 here: https://openxt.atlassian.net/browse/OXT-53
#2 was fixed by using the new url for the file.

Closing this out.