|
Mike is correct.
However, ideally, you’d look at getting the policy in the domain tweaked
so you could run validation on your build servers. You will catch bugs
much earlier running it there. If worse comes to worse, maybe you could
only suppress validation on the build machines but ensure all dev machines still
run validation. In case anyone
hasn’t noticed, Mike is just tearing up the mailing list with answers
that are almost always *right on target* (very few times have I thought,
“Well, I would do that a bit differently, but whatever…”).
If you haven’t
said, “Thanks, Mike” recently, you should do that. At the same
time, you might also say, “Thanks, Bob” since Bob also does quite a
bit of work here (Bob’s just been busy lately moving into his new condo). And, don’t
let these guys scare you away. If you know the answer to someone else’s
question, feel free to fire it off. If you’re not quite right,
someone will provide slightly adjusted guidance. One of the best ways to
learn something well is to give a slightly wrong answer and then get corrected…
well, at least I remember those cases very well. <smile/> Okay, time for
me to get back to shipping Vista. Thanks,
Mike. Thanks, Bob. From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mike
Dimmick light.exe
has, I believe, to load the .msi in order to perform the validation step.
For the moment, you could suppress validation with the -sval switch which I
think is a SuppressValidation property (I'm not familiar with MSBuild). --
Mike
Dimmick From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Peterson, Joel Hi all. I’m new to this list so please correct me if this has
already been discussed. I’ve installed the latest weekly build of WiX 3
on my development system and also on my Team Foundation Server/Team Foundation
Build. The WiX solution builds fine on my development system, in
all Debug/Release configurations. I checked that solution in to the main project
on the Team Foundation Server, and configured a Build for it. When I start the
build, it’s all run with the DOMAIN\TFSService user account as specified
in the Team Foundation Installation manual. Everything runs fine, until it gets
to Light: Target
PrepareForBuild:
Creating directory "obj\Release\".
Creating directory "D:\Build\ProjectName\WiX - Web Client
Printer\Binaries\Release\".
Target Compile:
C:\Program Files\Windows Installer XML v3\bin\candle.exe -out
"obj\Release\Web Client Printer.wixobj" "Web Client
Printer.wxs"
Target Link:
C:\Program Files\Windows Installer XML v3\bin\Light.exe -out
"D:\Build\ProjectName\WiX - Web Client Printer\Binaries\Release\Web_Client_Printer.msi"
"obj\Release\Web Client Printer.wixobj"
light.exe : error LGHT0216: An unexpected Win32 exception with error code 0x659
occurred: This installation is forbidden by system policy. Contact your
system administrator
Done building target "Link" in project "Web Client
Printer.wixproj" -- FAILED. This error is what one would get if they ran a MSI with a
user account that did not have Administrative priviledges, but why would that
appear during the link process? The Team Foundation Server Installation manual
specifically says not to give DOMAIN\TFSService administrative priviledges for
security reasons, but I did anyways to see if it would get around this issue.
It did not, and I still received the same error message. I can provide the full build log if necessary, I
haven’t had a chance to redact it yet. Joel Peterson |
------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
