I develop a simple file manager inside an ASP.NET Web site (not web application).
I notice that every time I rename or delete a folder, the site gets recompiled - i.e. the very next web request after delete or rename operation takes considerably much time to execute.
It's only true for folders, not for files.
Why does this occur?
P.S. I use WebDev server (Cassini), haven't tested in on IIS yet.
UPDATE: The same disaster happens with ASP.NET MVC Web Applications :(
UPDATE 2: Here are similar discussions:
Storing temporary user files in ASP.NET in medium trust
ASP.NET restarts when a folder is created, renamed or deleted
Asp.net watches the folders and then runs compilation to keep up with any changes you make. To overcome this you can use Non-updateable full precompilation, which you can read about here.
You should move the files folder outside the project structure and probably use a virtual folder in IIS to keep the paths. This should not only prevent recompilation but will also make updating the code and backing up the user files easier because they will be separated.
Where are the folders you are creating? Under App_Data?
Related
I have created my first website using asp.net 3.5 .
I have used App_Code for managing my source code files.
Now, after completion:
List item
What needs to be uploaded to the server ?
Do uploading all file including webforms files, source code files make any sense ?
Please provide your own suggestions apart from these.
You should look in to one of these several very good tutorials and articles about deploying ASP.NET applications.
How to Deploy ASP.NET
15 Seconds: Deploying ASP.NET
Deploying ASP.NET Applications on IIS 6
Deploying ASP.NET Applications
Now to your thoughts on what should be uploaded and what not. If you understand the asp.net cycle and how the files are processed by the webserver, it would be easy to know that all files need to be uploaded. But since this is your first application you probably don't have that knowledge.
So, to save you some reading time, Upload everything. In older versions such as 1.1 you had to compile all your source-code into binaries, which you don't have to anymore, but you can, it's up to you.
I However prefere to upload all the files without compiling it to binaries, makes it easier to manage once they are on the server.
The webserver will upon request ( first request ) compile these and then use the compiled files on other requests, this is the short answer anyway, this is why the load-time is longer the first time and the other times it's ( suppose to ) go faster.
Also, worht to know is that if you change the web.config, the application will re-compile.
So just drag n' drop em' to your webb-location and start playing!
If you are using the App_Code folder, it sounds like you are using a web site project type. In this case, the easiest thing to do is just xCopy all of the files up to the webserver. IIS will then do Just In Time compilation (JIT) the first time a page is hit, and will compile your code on the fly.
rgds,
Paul
All content files (i.e. aspx, ascx, asmx, asax, js, css, htm, jpg, gif, png) and DLLs need to be deployed to the server. I recommend using the Visual Studio "Publish..." option on the Build menu to do this for you. It can deploy to a folder (which you can then copy to somewhere else if you like), an FTP site or to an IIS virtual directory.
Uploading your .cs or .vb files is not necessary. It will still work if you do but it's probably safer not to. There's a remote possibility that IIS will have a vulnerability or a sysadmin will make a mistake and your source code will end up being served to the public.
In Visual Studio you could could do File -> New Web Setup Project and build an MSI to do it. This article and This article have more details on this option.
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.
I have deployed a new build on Production server, but I dont see the change in this version. I found out that it was caused due to old version of the DLL file under the temporary ASP.net folder
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files
In DEV environment, I can delete, but in Prod. I have restricted access to delete files inside the ASP.net temporary folder.
Can anyone tell me how can I get the new DLL files recreated immediately after I deploy the new files?
Thanks!
When you add new DLLs to the bin folder, they should immediately overwrite the files in the ASP.NET temp folders. I have myself noticed that sometimes (I assume that happend becuase of concurrency issues) the dlls are not loaded into memory.
If you have access to IIS management console, you could recycle the worker process. That should ensure that new temp assemblies are loaded.
Also if you change aspx oder ascx files, the resulting assemblies should be automatically replaced in the temp folder. If there is the same problem, I recommend recycling the worker process. Maybe you can integrate this in some automated way in your deployment procedure.
I'm using a Web Deployment Project in Visual Studio 2008 in order to prepare my ASP.NET application (ASP.NET web application, not ASP.NET web site) for being copied to several servers. I have to copy the files on local staging servers, on different servers via FTP and sometimes I have to fetch them from customers' servers.
So, it would be nice to have all files for deployment in a compact form without the necessity of doing a lot of comparing between source and destination. Web deployment projects have this nice feature: compile all your aspx and ascx files into a single (additional) assembly.
I somehow found out how to get rid of aspx placeholder files on the server, now I'd like to know if there is a (maybe self-made) way to get rid of these .compiled files.
From Rick Strahl's blog:
The .Compiled file is a marker file
for each page and control in the Web
site and identifies the class used
inside of the assembly. These files
are not optional as they map the ASPX
pages to the appropriate precompiled
classes in the precompiled assemblies.
If you remove the .Compiled file, the
page that it maps will not be able to
execute and you get a nasty execution
error.
Anybody out there with a creative idea, maybe using a module/handler which intercepts the check against the .compiled files in the bin folder?
The .compile file comes from pre-compiling on deployment. So you basically have 3 options:
Keep the .compiled file
Don't pre-compile and deploy source code
Turn this in to a Web Application instead of a Web Site and compile as an assembly
I have run in to the same problem myself. I actually choose #1 in most cases when dealing with deployment of Web Sites, but on the rare occasion when I know I am going to have to maintain the site for an extended period of time, I take the time to upgrade it to a Web Application.
I don't like the .compiled files either, but nobody gets hurt if they're there. So why bother?
You might want to take a look at Virtual Path Providers (KB how to here) in ASP.NET.
Credit for this suggestion must go to Cheeso and his self answered question here:
Can I get “WAR file” type deployment with ASP.NET?
I don't know about the .compiled files, but you could set up your servers to update their files with subversion instead of manually copying the files when you compile.
So you would compile the files using the Web deployment project (not into a single assembly), put them in a repository you created for this purpose, and on each server, just do an svn update to fetch and compare the files automatically.
I know it's not what you asked for directly, but it may be a path to explore.
Add "Exclude Filter" to your deployment project:
In the Deployment Project.
Right Click on Content Files.
Click on "Exclude Filter".
Add "*.Compiled"
click OK.
and thats it.
I remember at the days when I cant do Web Application with VWD Express, I use nant script to compile the project into a single dll and deploy, that would work (so I dont need the full VS to do dll deployment too), so if you really don't want to mess your project to Web Application, maybe this is a path to check too.
You can get rid of the .compiled files by using the aspnet_merge tool with the -r option.
Removes the .compiled files for the main code assembly (code in the App_Code folder). Do not use this option if your application contains an explicit type reference to the main code assembly.
If you publish your code as updateable (in publish settings) these files are generated. Uncheck that value and republish. This is an old question I know, but no answers are clearly defined for this here.
I've discovered this folder in C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files and have a few questions.
What does ASP.NET use this folder for, and what sort of files are stored here?
How does a file get stored here, and when is it updated?
Does the folder need any sort of maintenance?
These are what's known as Shadow Copy Folders.
Simplistically....and I really mean it:
When ASP.NET runs your app for the
first time, it copies any assemblies
found in the /bin folder, copies any
source code files (found for example
in the App_Code folder) and parses
your aspx, ascx files to c# source
files. ASP.NET then builds/compiles
all this code into a runnable
application.
One advantage of doing this is that it prevents the possibility of .NET assembly DLL's #(in the /bin folder) becoming locked by the ASP.NET worker process and thus not updatable.
ASP.NET watches for file changes in your website and will if necessary begin the whole process all over again.
Theoretically the folder shouldn't need any maintenance, but from time to time, and only very rarely you may need to delete contents. That said, I work for a hosting company, we run up to 1200 sites per shared server and I haven't had to touch this folder on any of the 250 or so machines for years.
This is outlined in the MSDN article Understanding ASP.NET Dynamic Compilation
The CLR uses it when it is compiling at runtime. Here is a link to MSDN that explains further.
Thats where asp.net puts dynamically compiled assemblies.