Can I safely delete the contents of this folder
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root
on a Windows 2003 R2 standard system, given that I am not using IIS (6/7) on it?
If that is the case, could you please point me to the relevant documentation about ASP.NET's runtime and maintenance tasks such as this?
Yes, it's safe to delete these, although it may force a dynamic recompilation of any .NET applications you run on the server.
For background, see the Understanding ASP.NET dynamic compilation article on MSDN.
Just an update on more current OS's (Vista, Win7, etc.) - the temp file path has changed may be different based on several variables. The items below are not definitive, however, they are a few I have encountered:
"temp" environment variable setting - then it would be:
%temp%\Temporary ASP.NET Files
Permissions and what application/process (VS, IIS, IIS Express) is running the .Net compiler. Accessing the C:\WINDOWS\Microsoft.NET\Framework folders requires elevated permissions and if you are not developing under an account with sufficient permissions then this folder might be used:
c:\Users\[youruserid]\AppData\Local\Temp\Temporary ASP.NET Files
There are also cases where the temp folder can be set via config for a machine or site specific using this:
<compilation tempDirectory="d:\MyTempPlace" />
I even have a funky setup at work where we don't run Admin by default, plus the IT guys have login scripts that set %temp% and I get temp files in 3 different locations depending on what is compiling things! And I'm still not certain about how these paths get picked....sigh.
Still, dthrasher is correct, you can just delete these and VS and IIS will just recompile them as needed.
Related
I have an application that is installed at several different client's servers. They each have different web.config files and different virtual folders. At the moment I am compiling, manually copying over, setting up IIS, changing web.config and adding virtual folders for each install and also again when updating.
I simply don't know how to deploy using something like Web Deploy or Deployment Package that will let me create different config files or how to manage virtual folders (I would assume I would simply deploy empty folders and would still have to do this part manually). I can handle setting up IIS and virtual folders from the start but I want each client to be able to download new versions and install them without my input (as some Clients are funny about remote access).
You can setup build configurations for each environment. Typically, you get Debug and Release out of the box. I like to replace those with Development, Staging, and Production configurations, which allows a different web.config per environment.
Of course, when publishing, you still have to make sure you select the correct configuration.
I'm not a fan of Web Deploy and other schemes because web-servers, unlike desktops, all tend to have a unique configuration.
In my case, all of our web applications are deployed with custom-written VBScripts (much more pleasant than Batch files and without needing to relearn PowerShell). VBScript (with its default COM object library) provides a compelling platform for writing deployment scripts. And if you can't stand the syntax you can use JScript using the same tools. Bonus: Visual Studio still provides Windows scripting IntelliSense despite it not being an advertised feature).
My most recent deployment script is simple: it's a VBScript (invoked by VS's Post-build command-line) that uses 7-Zip to pack up the web application's files, then generates an ftp.exe batch file (then runs ftp.exe itself) that uploads the files to the server, it also generates an uploads a file called "Unpack.cmd" which calls 7-Zip to extract the files into the right place. The only manual step is executing Unpack.cmd on the server, but that can be done with Remote PowerShell, for example.
Why do you need to customise your IIS configuration separately from the application? Can't you put everything in your web.config file under <system.webServer>?
Should developers keep the web.config file updated and commit it to a VCS such as SVN? At my company we very rarely update it via SVN; instead somebody will create an "instructions" text file in our deployment scripts (SQL scripts and the like, plus batch files to compile the ASPX files as individual DLLs for deployment) that says something like "Change X to Y in web.config files for Sites A, B and D", and relies on the individual developer following those instructions each time the file is updated.
This seems counter-intuitive to me: I would expect the web.config file to be kept in sync as needed, with necessary changes being made and the file committed as any other artifact of the codebase, but I have raised this issue in the past and nobody has paid it any mind.
What approach should be followed when dealing with config files like this?
Absolutely, web config must be in source control, and you can define differences beetween various versions of web.config with web.config configurations
for example we have one for local development server, one for test IIS server, and one for production IIS server. And we can set solution configuration and publish from visual studio for different targets and different clients (sites).
here are the links for web.config configurations :
Common Web.Config transformations with Visual Studio 2010
Web.config Transformation Syntax for Web Application Project Deployment
I wouldn't allow all developers to have access to web.config file at all either via SVN or other way. Although if in your company it is allowed for developers to access web.config i see no reason why it shouldn't be on SVN. Point of SVN is to keep track of your single/multi person development process. If you make changes to web.config and this cause a bug in someone's else code it would be much easier to revert changes using SVN
I have built a few custom applications that run on WSS 3 using the Visual Studio 2010 Web application template. When I compile the application, Visual Studio creates the assembly file in the bin directory which I copy over later to the production server (another machine) with WSS 3. The compiled application dll file is copied into the bin folder inside the virtual directory of WSS and runs fine in there.
As the project requirements / applications grew over time I now face the problem that the first hit on the assembly triggers dynamic compilation which I would like to avoid.
Even if applications are running fine I would like to use the asp precompiler on my development machine in order to reduce the delay when the page is first requested.
I have used the following command to precompile the entire Web Application:
aspnet_precompile -v / -p PATH_TO_WEB_APPLICATION C:\WebApp -errorstack
The compilation runs fine without any errors and I end up with a couple of .compiled files and also a Web_App_xxxxx.dll file inside the C:\WebApp\bin folder.
From here onwards I am a bit lost on how to proceed.
Could you please give me some advise to which folder I need to copy the compiled files on the production server ?
Do they need to go into the bin folder on the server or better into the folder where the aspx pages are located?
Additionally I would like to know if I can precompile the Web application on a development machine without the IIS metabase using the -v and -p switch and later use it inside WSS?
I copied all files from the C:\WebApp\bin folder to the server bin folder but unfortunately the csc compilation process still kicks in when looking with process monitor at the server events.
Cheers,
Mathias
The files just need to be dropped into the bin folder and everything will work fine. As for the -v switch you do need to have it if you're using the -p flag, but I think it depends how you're compiling the app too. Check this link out for more. I don't believe its a big deal if its wrong / incorrect though.
This kind of scenario sounds like a job for Cruise Control .NET environment.
I found an answer to this precompilation question:
I thought the first hit on the application page takes a long time because asp.net needs to compile it and I can save some time by precompiling. The application runs inside the WSS context and enables the user to go to a web form and update through the form his/her Active Directory profile. The Exchange global address list is also updated on the Exchange forest so the changes are visible through the Outlook address list and also on Communicator.
The complete solution code with reports etc is around 6000 lines of C# code.
My assumption regarding slow compilation due to the amount of lines was wrong.
I downloaded the following hotfix for asp.net:
http://support.microsoft.com/kb/961884
and set optimizeCompilations="true" in the web.config as explained here:
http://blogs.msdn.com/b/davidebb/archive/2009/04/15/a-new-flag-to-optimize-asp-net-compilation-behavior.aspx
http://www.paulliebrand.com/2009/09/18/sharepoint-development-to-bin-folder-and-extremely-slow-render-initial-render-times-solution/
Now the first hit on the application is much faster.
Many thanks,
Mathias
I'd like to know what happens when a native (read: non-.NET) DLL is placed within the Bin folder of an ASP.NET application. Specifically I have ~two questions (I won't bog down these straight forward questions with the specifics of my situation):
Does ASP.NET store the DLL's in memory? Is this why a) I can't delete the files and b) changing permissions on the files doesn't affect ASP.NET's ability to read them?
Also, is it possible for a native DLL in one ASP.NET application bin folder to affect a completely different ASP.NET application? Because that certainly seems to be happening with two of my applications. Is a native DLL a resource that is subsequently used by the ASP.NET client in any context?
for me, if the CLR comes across a non-net dll in the bin folder, it will try to load it and not be able to, and the compiler will show you the YSOD.
if you are having trouble deleting the dlls, i would suggest iisreset - works for me when i come across files i can't delete.
You won't be able to delete any files in the Bin folder of your app until you stop IIS.
Your other app may be dying because it's sharing an AppPool with the application that's loading the "bad" DLL; this may in turn be killing (read shutting down) the AppPool. Make sure each site is running on a different pool and you shouldn't seen any problems on the other site.
Today I stumpled upon the shadowCopyBinAssemblies option in the hostingEnvironment tag.
Appearently this attribute it is a web.config (system.web) configuration Boolean option indicating whether the assemblies of an application in the Bin directory are shadow copied to the application's ASP.NET Temporary Files directory.
<hostingEnvironment shadowCopyBinAssemblies="false" />
A colleague had to enable this setting because (only) on his development machine he frequently got that ASP.NET error in the web browser:
Cannot create shadow copy assembly file dll when that file already exists.
compiling a specific web project in Visual Studio 2008 and openining a page.
So now my question: can I preserve this setting in a production environment or could it harm performance and/or create other issues?
Thanks!
I get this error from time to time, and usually doing Clean Solution followed by Rebuild Solution takes care of the problem. If this works for your colleague, then there's no need to play with the setting (especially in production).