XslCompiledTransform.Load() raises System.IO.FileNotFoundException

Question

My webapp (ASP.NET 2.0) consumes a webservice (asmx on 1.1 framework) on the same machine. After getting XML in return, I pass it to XslCompiledTransform for transform XML to HTML and it works fine.

Yesterday I got a System.IO.FileNotFoundException frequently and don't know what causes this kind of problem.

First look I thought it's about read/write permission on c:\windows\temp and then I made sure give it full permission for Network Service (also Everybody at last -_-!) but it doesn't help.

Any ideas or solutions would be appreciate.

-------------------- stack trace --------------------------
Exception: **System.IO.FileNotFoundException**
**Could not find file 'C:\WINDOWS\TEMP\sivvt5f6.dll'.**

   at System.IO.__Error**.WinIOError**(Int32 errorCode, String maybeFullPath)
   at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 
rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy)
   at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share)
   at Microsoft.CSharp.CSharpCodeGenerator.FromFileBatch(CompilerParameters options, String[] fileNames)
   at Microsoft.CSharp.CSharpCodeGenerator.FromDomBatch(CompilerParameters options, CodeCompileUnit[] ea)
   at Microsoft.CSharp.CSharpCodeGenerator.System.CodeDom.Compiler.ICodeCompiler.CompileAssemblyFromDomBatch(CompilerParameters options, CodeCompileUnit[] ea)
   at System.CodeDom.Compiler.CodeDomProvider.CompileAssemblyFromDom(CompilerParameters options, CodeCompileUnit[] compilationUnits)
   at System.Xml.Xsl.Xslt.Scripts.CompileAssembly(List`1 scriptsForLang)
   at System.Xml.Xsl.Xslt.Scripts.CompileScripts()
   at System.Xml.Xsl.Xslt.QilGenerator.Compile(Compiler compiler)
   at System.Xml.Xsl.Xslt.**Compiler.
Compile**(Object stylesheet, XmlResolver xmlResolver, QilExpression& qil)
   at System.Xml.Xsl.XslCompiledTransform.LoadInternal(Object stylesheet, XsltSettings settings, XmlResolver stylesheetResolver)
   at System.Xml.Xsl.**XslCompiledTransform.Load**(String stylesheetUri, XsltSettings settings, XmlResolver stylesheetResolver)

Answer 1

After checking for details and googling for the related topics,

1. This problem found with .Transform() and also occures with XmlSerialization as Marc said. Christoph Schittko has a good article for troubleshooting.

2. Someone said the problem may because some update patch of windows that can change the behavior of serializer.

   I called my administrator to clarify if there's any changes on our server and he said nothing changes and he suggest me for restarting.

   and Yes... my problem has been solved by.....restarting server (windows 2003 ;)

Answer 2

OK, that's an interesting one. I've seen similar issues with serializers, but not with XslCompiledTransform specifically.

From the title, I was expecting it to be an issue loading included/imported transforms, which would probably have been fixable by supplying an XmlResolver. Not finding the self-generated dlls is very odd!

As a stop-gap (while you investigate the issue), you might want to see if it still happens with XslTransform. I realise this isn't ideal (given the optimisations etc in XslCompiledTransform), but it might at least let your app work while you investigate...

The first investigative thing I would do is look at the event log. Anything interesting? Also worth checking if your anti-virus software hasn't gone mad with false positives (unlikely).

The next thing I would do is isolate the app - i.e. snip off the 1.1 stuff - since you're calling it via an asmx page (to a separate application) it shouldn't be a factor, so you should (theoretically) be able to reproduce it just from a flat xml file. Ideally, it would be good to have a page (maybe an ashx for simplicity) in you project that just tries to do a transform from a local file.

Is it reproducable with simple xslt/xml? The simpler you can make the code that has an issue, the closer you are to either finding/fixing it, or having something that you can fire at MS via "connect".