Without a lot of big introductions….

The Problem:
Some of the .Net Classes when used generate a temp dlls and then use it to call certain code or even make some operations in the local server
However those temp dlls are saved in the temp file of the application which usually set by default to c:\Windows\Temp which is a very secure file and needs permissions to read or to write from this file…
And as used Microsoft didn’t do all the work….in a way or anther the permission to .Net classes is generating the dlls is managed in windows Xp but it is note managed in windows 2003
So if you are developing your web application on xp and deploying to 2003 server strange errors will appear to you because of this problem

N.B. Sometimes Crystal reports generate the same error by saving temp reports in the windows temp file.

Solution:

Attempt 1:
If Your Applications Is Using the Asp.Net Authentications…. You can simply give the permissions to the ASP User on the Windows Temp Folder and You are done however this Solution is not safe because you open the server temp file to anyone to write in …!!
Any way attempt 2 might help you with that

Attempt 2
By more search I found out that you can change the temp folder for your web application and prevent it from using the default file (c:\Windows\Temp)
Using this code

Environment.SetEnvironmentVariable("TEMP", "c:\\Filename"); Environment.SetEnvironmentVariable("TMP", "c:\\Filename");
And adding this tag in the web config

compilation tempDirectory="c:\FileName"

As you can notice you have to change both the variables TEMP and TMP as Microsoft uses to Variables for the Temp Files……….

Attempt 3:

If You know the part of the code that generates the temp dlls you can use the impersonate class to change the current user to a anther user from the servers user that have permissions to the temp folder of the application and after performing the target code you can return back to the original user
You will find this link very useful if you are attempting to do this solution

Attempt 4:
the poorest solution to make this problem work out is to add this tag in the config file
trust level="full" originUrl=""
but that will make the pc opened to any user to do whatever he wants… so it is not a solution actually

Attempt 5 :
This is the attempt where I succeeded to make the problem work out; in my case I knew exactly the part that generated the temp Dlls
I was using XslCompiledTransform to Transform an Xsl file that contains Scripts, Those scripts was the reason for generating the temp dlls, so I just removed the scripts and passed the values calculated by them as xsl param, for more details read my next post."XslCompiledTransform and xsl Scripts"