(See URL) Because nsinstall.exe includes "install", on Windows Vista with UAC it will want privilege escalation and fail. I didn't know this, but apparently it is possible embed a manifest to explicitly state that is not necessary. Workaround: run the shell as an administrator.
I believe Rob had a local fix for this, a script to embed manifests in all the MSYS executables. Probably something we should consider adding to the MozillaBuild build process.
Created attachment 272839 [details] vbs to apply manifests The following allows me to build without admin privs The root dir where I keep my trees and c:\mozilla-build\ I give the Users group full control. Then and only then should you add dirs and files underneath these directories or run the mozilla build installer. Then I run the attached vbscript... notes on the vbscript I installed the latest version of MozillaBuild and found that rm.exe and mv.exe were periodically failing so I went ahead and created a simple vbscript for adding manifests directly using mt.exe to all of the exe's under mysys/bin and both versions of nsinstall. It is just easier than creating individual files and then having to touch the exe's. There are two lines you may have to change if you didn't install into the default locations. strPathMozBuild = "c:\mozilla-build" strPathMT = "c:\Program Files\Microsoft Visual Studio 8\VC\bin\mt.exe" Run it from a cmd shell with cscript.exe ApplyManifests.vbs Hopefully MSYS will add manifests to their files soon (I saw a bug on this but don't have it handy) but this simplifies things in the mean time.
Hello all, How do you apply the manifest? Can I instead be working always "running as administrator" the msvc8.bat? I was able to build Firefox last week on my Vista but after this weekend I wasn't able. Could it be that I checked out the source code when the tree was burning? I've posted about it, maybe it helps others: http://armenzg.blogspot.com/2007/10/session-11-mozillabuild-in-vista.html Thanks for any help
(In reply to comment #3) > Hello all, > How do you apply the manifest? The details are in comment #2 above > Can I instead be working always "running as administrator" the msvc8.bat? I used to build successfully by starting the batch file using "running as administrator". That should still work. > I was able to build Firefox last week on my Vista but after this weekend I > wasn't able. Could it be that I checked out the source code when the tree was > burning? Yes
Mass re-assign of MozillaBuild bugs into mozilla.org:MozillaBuild
Created attachment 324622 [details] [diff] [review] Add some manifests to *install*.exe I'm uploading an installer with this patch installed right now, I'll link it in a minute.
Comment on attachment 324622 [details] [diff] [review] Add some manifests to *install*.exe I have a field report that says this doesn't work.
Created attachment 324835 [details] [diff] [review] embed manifests in *install*.exe This looks better, will get some testing on it.
Ted, unless I'm mistaken all exe files will require manifests due to Data Execution Prevention... otherwise sporadic "Invalid access to memory location" errors will occur. One example with SP1 but I've seen this without SP1. http://digerati-illuminatus.blogspot.com/2008/03/windows-vista-sp1-and-unable-to-load.html
Ugh, that sucks.
Just so you know, I've been building without issues with manifests applied to MozillaBuild's exe's in the following directories for around a year now \msys\bin \moztools\bin \moztools-180compat\bin
Ok, thanks for clarifying. I thought maybe you were just being thorough by embedding manfiests in everything. :) I'll rework the patch to embed manifests in everything in msys/bin.
And I've been working with just nsintall patched, since August or so :) Vista/SP0/32bit. Just XR though, not Firefox.
Mook, do you have UAC enabled?
(In reply to comment #15) > Mook, do you have UAC enabled? bah... and you are building without elevation?
UAC is enabled, and I'm building without elevation, yes. Otherwise I wouldn't have needed to file the bug :)
Strange... I'm building without elevation as well and ended up with the sporadic "Invalid access to memory location" errors without adding manifests to the additional exe's. Vlad experienced the same errors at that time about a year ago as well.
Ok, this one has manifests embedded in every exe under /msys, as well as nsinstall.exe: http://people.mozilla.com/~tmielczarek/MozillaBuildSetup-1.3rc2.exe
Meh, maybe I was just lucky. Adding random manifests is unlikely to hurt, though.
Created attachment 324961 [details] [diff] [review] embed manifests in msys/*.exe, nsinstall.exe This is the patch I used for the above installer. It embeds manifests in every exe in msys, as well as nsinstall.exe.
Lukas points out that we don't have a manifest in the installer, either, which makes UAC use its heuristic, and thus you get the "program may not have installed correctly" dialog afterwards. We should put a manifest in the installer as well, to avoid this. I think I'll put the same "no privileges" manifest in there, since the installer doesn't touch the registry, and can be installed anywhere. You can always "run as admin" if you want to install it somewhere you don't have access to.
bsmedberg suggests instead that we use "highestAvailable". Rob: any thoughts?
Ted, unless you're using am old version of NSIS you can use the following and change user to highest http://mxr.mozilla.org/mozilla/source/browser/installer/windows/nsis/uninstaller.nsi#74 http://nsis.sourceforge.net/Docs/Chapter4.html
or just use RequestExecutionLevel highest
Created attachment 325014 [details] [diff] [review] embed manifests in msys/*.exe, nsinstall.exe, MozillaBuildSetup.exe Thanks Rob. This also adds that to the NSIS script, so the installer gets a manifest.
I've updated the installer here to one built with this patch: http://people.mozilla.com/~tmielczarek/MozillaBuildSetup-1.3rc2.exe
Comment on attachment 325014 [details] [diff] [review] embed manifests in msys/*.exe, nsinstall.exe, MozillaBuildSetup.exe I'm confused why you still need MozillaBuildStep.exe.manifest, now that you have the NSIS goodness... but this looks good in either case.