R
Rich Yadach
Does anyone have any ideas or comments on this?
The problem seems to stem from having Impersonate=True set in our web.config
files (Version 1.1).
Here is the error we encountered .
The actual filename changes every time you try to load the page:
An error has occurred: Access to the path
"C:\DOCUME~1\servername\ASPNET\LOCALS~1\Temp\olvtg0lf.0.vb" is denied.
This is what I grabbed from the server's event viewer:
1) Exception Information
*********************************************
Exception Type: System.UnauthorizedAccessException
Message: Access to the path
"C:\DOCUME~1\servername\ASPNET\LOCALS~1\Temp\olvtg0lf.0.vb" is denied.
TargetSite: Void WinIOError(Int32, System.String)
HelpLink: NULL
Source: mscorlib
StackTrace Information
*********************************************
at System.IO.__Error.WinIOError(Int32 errorCode, String str)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess
access, FileShare share, Int32 bufferSize, Boolean useAsync, String msgPath,
Boolean bFromProxy)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess
access, FileShare share)
at System.CodeDom.Compiler.CodeCompiler.FromDomBatch(CompilerParameters
options, CodeCompileUnit[] ea)
at System.CodeDom.Compiler.CodeCompiler.FromDom(CompilerParameters
options, CodeCompileUnit e)
at
System.CodeDom.Compiler.CodeCompiler.System.CodeDom.Compiler.ICodeCompiler.C
ompileAssemblyFromDom(CompilerParameters options, CodeCompileUnit e)
at System.Xml.Xsl.Compiler.CompileAssembly(ScriptingLanguage lang,
Hashtable typeDecls, String nsName, Evidence evidence)
at System.Xml.Xsl.Compiler.CompileScript(Evidence evidence)
at System.Xml.Xsl.Compiler.Compile(NavigatorInput input, XmlResolver
xmlResolver, Evidence evidence)
at System.Xml.Xsl.XslTransform.Compile(XPathNavigator stylesheet,
XmlResolver resolver, Evidence evidence)
at System.Xml.Xsl.XslTransform.Load(String url, XmlResolver resolver)
at System.Xml.Xsl.XslTransform.Load(String url)
at UI.Sitemap.PortalSiteMap.TransformXML()
Here is what the code is doing.simply trying to load an XSL file
Dim resultsXSLT As New Xsl.XslTransform()
Dim xslFile As new String = "somexslfile..xsl"
resultsXSLT.Load(xslFile) ß Exception Occurs Here
The xsl file has imbedded within it VBScript.
My theory on what is causing the error.
Since the application code is loading the XSL file,
which contains VBScript, I think the CLR is trying to JIT compile the code
at runtime, and since Impersonate=True, is doing
this under the security context of the end user. This user does not have
access rights to the c:\documents and Setting. directory
listed above. When we turn Impersonate off everything works because the
security context is now ASPNET and for version 1.1 of the
frameworks this account was granted full control of the above mentioned
directory (see link below). The reason I think the CLR is trying to JIT the
VBScript is when we did some testing I noticed the CLR JIT perfmon counters
being incremented when traversing thru this code.
Here is a link to an identical problem (bet he had impersonate=true):
http://www.dotnet247.com/247reference/msgs/46/231289.aspx
Not the same situation but does talk about impersonate=true and the
Documents and Settings Folder:
http://support.microsoft.com/default.aspx?scid=kb;en-us;827190
Question:
Can anyone confirm my theory and more importantly is there a way
to configure the location of the temp files used for JIT compiles? I'd
rather not have to grant our end users full control to the C:\documents and
settings. folder when Impersonate=true is set.
The problem seems to stem from having Impersonate=True set in our web.config
files (Version 1.1).
Here is the error we encountered .
The actual filename changes every time you try to load the page:
An error has occurred: Access to the path
"C:\DOCUME~1\servername\ASPNET\LOCALS~1\Temp\olvtg0lf.0.vb" is denied.
This is what I grabbed from the server's event viewer:
1) Exception Information
*********************************************
Exception Type: System.UnauthorizedAccessException
Message: Access to the path
"C:\DOCUME~1\servername\ASPNET\LOCALS~1\Temp\olvtg0lf.0.vb" is denied.
TargetSite: Void WinIOError(Int32, System.String)
HelpLink: NULL
Source: mscorlib
StackTrace Information
*********************************************
at System.IO.__Error.WinIOError(Int32 errorCode, String str)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess
access, FileShare share, Int32 bufferSize, Boolean useAsync, String msgPath,
Boolean bFromProxy)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess
access, FileShare share)
at System.CodeDom.Compiler.CodeCompiler.FromDomBatch(CompilerParameters
options, CodeCompileUnit[] ea)
at System.CodeDom.Compiler.CodeCompiler.FromDom(CompilerParameters
options, CodeCompileUnit e)
at
System.CodeDom.Compiler.CodeCompiler.System.CodeDom.Compiler.ICodeCompiler.C
ompileAssemblyFromDom(CompilerParameters options, CodeCompileUnit e)
at System.Xml.Xsl.Compiler.CompileAssembly(ScriptingLanguage lang,
Hashtable typeDecls, String nsName, Evidence evidence)
at System.Xml.Xsl.Compiler.CompileScript(Evidence evidence)
at System.Xml.Xsl.Compiler.Compile(NavigatorInput input, XmlResolver
xmlResolver, Evidence evidence)
at System.Xml.Xsl.XslTransform.Compile(XPathNavigator stylesheet,
XmlResolver resolver, Evidence evidence)
at System.Xml.Xsl.XslTransform.Load(String url, XmlResolver resolver)
at System.Xml.Xsl.XslTransform.Load(String url)
at UI.Sitemap.PortalSiteMap.TransformXML()
Here is what the code is doing.simply trying to load an XSL file
Dim resultsXSLT As New Xsl.XslTransform()
Dim xslFile As new String = "somexslfile..xsl"
resultsXSLT.Load(xslFile) ß Exception Occurs Here
The xsl file has imbedded within it VBScript.
My theory on what is causing the error.
Since the application code is loading the XSL file,
which contains VBScript, I think the CLR is trying to JIT compile the code
at runtime, and since Impersonate=True, is doing
this under the security context of the end user. This user does not have
access rights to the c:\documents and Setting. directory
listed above. When we turn Impersonate off everything works because the
security context is now ASPNET and for version 1.1 of the
frameworks this account was granted full control of the above mentioned
directory (see link below). The reason I think the CLR is trying to JIT the
VBScript is when we did some testing I noticed the CLR JIT perfmon counters
being incremented when traversing thru this code.
Here is a link to an identical problem (bet he had impersonate=true):
http://www.dotnet247.com/247reference/msgs/46/231289.aspx
Not the same situation but does talk about impersonate=true and the
Documents and Settings Folder:
http://support.microsoft.com/default.aspx?scid=kb;en-us;827190
Question:
Can anyone confirm my theory and more importantly is there a way
to configure the location of the temp files used for JIT compiles? I'd
rather not have to grant our end users full control to the C:\documents and
settings. folder when Impersonate=true is set.