View Single Post
  #2  
Old 07-27-2007, 07:00 PM
kinook kinook is online now
Administrator
 
Join Date: 03-06-2001
Location: Colorado
Posts: 6,003
You didn't indicate how you're logging the username, but the value of the USERNAME system macro depends on the identity of the thread that instantiated the Application object (since it currently initializes the value when created), not the identity of the build thread. By default, IIS 6 ASP.NET Web applications run in the security context of the NetworkService account [1].

Now, the build thread itself (and actions such as the Copy Files and Write File actions) will either run under the identity of the calling thread (if the first parameter of SyncBuildEx is true) or the identity of the calling process (if false), while other processes that are started by calling RunProgramEx (Run Program, SourceSafe, etc.) will run under the identity specified in the SyncBuildEx call.
http://www.visualbuild.com/Manual/syncbuildexmethod.htm

There does seem to be something a bit odd going on with the Write XML action. Since it is implemented as script code, it gets executed in the context of a COM apartment-threaded helper component. I suspect that COM is creating a compatible thread for this component, and the identity of this thread (where the script code executes) is that of the calling process (since this is what happens for threads created by a thread that is running impersonated unless special steps are taken [2]). We'll investigate to see what can be done about this. One workaround might be to force the IIS process to run under an identity with the necessary privileges [3].

Another alternative would be to instead invoke the VBP console app to build (the no wait method demonstrated in the WebLauncher sample). Since that process gets created with the proper identity and no impersonation occurs, both the build thread and all processes created by it will run under the specified identity. This method could be performed synchronously as well (for instance, waiting for the process to complete while populating the response page with stdout) or asynchronously, returning as soon as the process was started (in this case a link could be provided to the build log file or another file that is periodically updated with build progress).

[1] http://support.microsoft.com/kb/317012/
[2] http://groups.google.com/group/micro...s&rnum=3&hl=en
[3] http://msdn.microsoft.com/msdntv/tra...ranscript.aspx
Reply With Quote