I have an ASP.NET web application (Visual Stuido project type) in which everything is compiled into a single assembly, it is deployed in IIS. My question is if I have a new version of the assembly, is OK to replace it in IIS without bringing down the IIS? Or for a safe consideration, should I firstly shutdown the web server and then replace the assembly and restart? I am looking for a better solution to reduce server down time?
Yes. but it will cause an immediate Application Pool Recycling.
Quoting MSDN Blog:
Altering the following files will also trigger an immediate restart of the application pool:
web.config
machine.config
global.asax
Anything in the bin directory or it's sub-directories
We've reinstalled applications numerous times usnig the Visual Studio installer and it has replaced the assemblies with no problems. The only thing we find is that the first time we open the web page it takes a little while to open - possibly as it reads in the new assembly. We haven't had to to do an IIS reset or anything like that.
In addition on our dev environments (and because I am lazy) I often simply overwrite the assembly on the web server and that exhibits the same behaviour as above.
Taking down IIS is not an option for us, as we have many websites running on the same server.
I can't guarantee this is the best way to do it or that it won't cause problems, but it works for us.
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.
The situation is I made a minor bug fix to a class, so they want to just deploy the dll affected. They stopped IIS, replaced the dll in the /bin folder of the iis directory for the web site with the new one I gave them, and started iis again. There are multiple servers, but they just changed it on one to try it out. They are still seeing the same error in the eventlog of the server in question. Looking at the stack trace I can tell it is running the old dll.
They've checked the GAC and don't see it there.
I've checked the dll with reflector to verify I gave them the correct new dll.
This is an asp.net 2.0 website and the server is 2003. I'm not sure how it was deployed originally but it has a copy of the old dll in C:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files\NAME_services#################\assembly\dl3###################\ and in D:\xxxx\Sites\NAME\Services\obj\Release. Could it be using one of these or building the old one or even just caching it in memory?
Nuke your temporary asp.net folder contents. Not sure why the update didn't automatically get compiled, though.
We had same problem but with minor complications, we have many many sites so a "clearing all temp" and restart IIS is not a good option for us. So we needed to be more selective in what to force a refresh on.
On our QA machine, under ... "C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files"
I did a file explorer search for the partial file name of what we are trying to release. The file was found in a folder something like:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\4503212x\ad95664x, so I stopped app pool, deleted the folder, restarted and all was deployed then - great!
But .... We had same trouble deploying to production and the above did not work.
Long story short, the QA app pool was set to "enable 32 bit true", but production was set to "False" so the prod temp files resided in:
"C:\Windows\Microsoft.NET\Framework64\v4.0.30319" instead (\Framework64\ instead of \Framework\ ).
If clearing temp files is not working - double check your frameworks, or look for files to refresh at the C:\Windows\Microsoft.NET folder level and below. you may be surprised.
You don't have to stop IIS to deploy your update, you just copy them over.
Also, if they copied only the DLL but your fix was in the .aspx file, then it won't show up. You should really do a full deployment.
We copied the project source code to a new folder and reopened the solution. This somehow tricked Visual Studio into not using the cached version of the DLL. Wish we knew why this worked, but that resolved it for us.
I want to update a class library (a single DLL file) in a production web application. This web app is pre-compiled (published). I read an answer on StackOverflow (sorry, can't seem to find it anymore because the Search function does not work very well), that led me to believe that I could just paste the new DLL in the bin folder and it would be picked up without problems (this would cause the WP to recycle, which is fine with me because we do not use InProc session state).
However, when I tried this, my site blows up and gives a FileLoadException saying that the assembly manifest definition does not match the assembly reference. What in the world is this?! Updating the DLL in Visual Studio and re-deploying the entire site works just fine, but it is a huge pain in the rear. What is the point of having a separate DLL if you have to re-deploy the entire site to implement any changes?
Here's the question: How can I update a DLL on a production web site without breaking the app and without re-deploying all of the files?
The thing to remember is that there are web sites and web applications as far as Visual Studio and ASPNET is considered.
Web Sites typically have all of the aspx and vb files published to the live server and ASPNET Worker Process recompiles the app every time before presentation.
On the other end is the web application, where all of your code behind files get compiled down to a single DLL file and you simply deploy your aspx pages and you bin folder with the DLL file to production.
There is also a "hybrid" known as "Precompiled Web Sites" (see the link for the official MSDN overview) where you don't have the single DLL layout of a web application, but all the compile work of the website is done for you. There are several "modes" to this depending on your needs.
It seems to me that your error is caused because your site is set up as a web site with some kind of precompilation in place. Using the pre-compiled model is a little more "strict" in that is assumes certain files/signatures are in place. Having an updated version of the DLL file causes a break since the precompilation wants a name and a version of the file.
If possible, your best bet would be to convert to a web application, since you can add the additional DLLs into production without a problem. Otherwise, take a look at this matrix to see what form of precompilation you need for your application.
Look at this SO post, might be what you are referring to. The located assembly's manifest definition does not match the assembly reference
Have a look at your reference. Does it say "specific version = true" ? Set it to false, republish your app (you have to do it once, because now your app is still looking for an assembly with a specific manifest) and try it again.
I have downloaded the online project in ASP.Net. While running application I get an error
It is an error to use a section registered as allowDefinition='MachineToApplication' beyond application level. This error can be caused by a virtual directory not being configured as an application in IIS.
What changes should i make in web.config or elsewhere to make this work?
I've just encountered this "delight". It seems to present itself just after I've published a web application in release mode.
The only way to consistently get round the issue that I've found is to follow this checklist:
Clean solution whilst your solution is configured in Release mode.
Clean solution whilst your solution is configured in Debug mode.
Build whilst your solution is configured in Debug mode.
Just come across this post and that was happening to me.
Just Clean the project and the error goes away. (must be a VS2010 bug)
I have just had this problem when building a second version of my website. It didn't happen when I built it the first time.
I have just deleted the bin and obj folders, run a Clean Solution and built it again, this time without any problem.
None. You need to set up the directory you've placed the website as a web application within IIS.
This error occurs when you attempt to open a project as a website. The easiest way to determine if you've created a website or a project is to check your solution folder (i.e. where you saved your code) and see if you have a *.sln file in the root directory, if you do then you've created a project.
Just to add, I encountered this error just now when I attempted to open a project I created a while back by selecting "File", "Open Website" from the Visual Studio menus whereas I should have selected "File", "Open Project" instead. I facepalmed as soon as I realised :)
If you have MVC project with enabled views build, one of the solution is to delete obj folder before build. Add to project file:
<Target Name="BeforeBuild">
<!-- Remove obj folder -->
<RemoveDir Directories="$(BaseIntermediateOutputPath)" />
<!-- Remove bin folder -->
<RemoveDir Directories="$(BaseOutputPath)" />
</Target>
Here is article: How to remove bin and/or obj folder before the build or deploy
In Visual Studio 2013 I struggled with this for a while and it is pretty much easy to solve just follow what the exceptions says "virtual directory not being configured as an application in IIS"
In my case I had WebService planted inside IIS website so
I opened the website in IIS manager
right clicked the WCF folder
clicked Convert to Application
and then submitted with Ok
WCF is back and running.
The error suggests that the code you are using is expecting a virtual directory to be setup on IIS.
Look up the documentation and add the required virtual directory. It should be a directory that has a web.config in it (not the root directory).
A recent web.config change may be in the wrong web.config file.
A <machineKey...> property had been added to Views/web.config. No matter how many Cleans and Rebuilds the error remained. The fix was to move the property into the root /web.config.
if you ever encounter this error
It is an error to use a section registered as
allowDefinition='MachineToApplication' beyond application level. This
error can be caused by a virtual directory not being configured as an
application in IIS
SOLUTION
I had the same issue with VS 2012.
I resolved this by
Unload your current project
edit your .csproj
Find this <MvcBuildViews>false</MvcBuildViews>
Instead of false change the value to true
Load again your project and you should not have any more this error
If you do have then one solution is to delete the content of the obj folder in the project generated by compiler.
In my case, the problem appeared only after I published the project to the subdirectory. Because of my lack of knowledge, I have placed my web_publish subdirectory inside the web_project directory.
It is clear that the web_publish contains also the same Web.configs that the project contains. However, the web_project does not know that my web_publish should be avoided when searching Web.configs in the nested subdirectories. This way, the Web.configs were duplicated and the error appeared.
The solution was to place my web_publish somewhere else.
In my case there was a "Backup" folder which contained another copy of the whole website in there. This meant another web.config and so the build failed with this error. I deleted the "Backup" folder, did a Clean solution on the Debug and Release builds, and the error disappeared.
In my case,
Solution contains 6 projects, 1 main and 5 sub directories. all the sub directories having web.config.
When running any page within sub directories, I was getting same error.
I removed this line from web.config,
<authentication mode="Windows"/>
that worked for me.
Clean your project
Remove the /obj folder (probably using publish and deploy? - there is a bug in it)
My problem was I had accidentally published my webservice to a pre-completed location on a fresh install of VS2010.
I had published to a folder called PreCompiledWeb, and the presence of the web.config I suspect messed it up.
I simply nuked the folder, and refreshed the project.
When double-clicking this error - it took me to that erroneous web.config file, which tipped me off.
It may be the version problem like you download the project of .Net framework 2.0 and want to open it into the VS2008 then you will need to upgrade to the latest version and VS will create the Backup of the folder in same root directory.You will get the answer here.
I had this error when building the solution with Web Deployment Project created into my solution. I resolve the error by deleting the folder where Web Deployment Project is built to. This folder is specified in "Project Folder" attribute of WDP properties
Delete bin and obj folders. Then rebuild the solution.
Apparently there were two web.config files in my solution. I am using MVC4 and there was another config file under Views and i was making the change in the wrong file. Fixed there helped me.
But you can always change the default redirect/route in the global.asax file.
Probably you have a sub asp.net project folder within the project folder which is not configured as virtual directory. Setup the project to run in IIS.
I added to my website publish script. At the end, delete the obj folder from your website folder.
I've this problem more frequent if "true" is enabled in the project file.
Set false
As Jonny says:
Clean solution whilst your solution is configured in Release mode.
Clean solution whilst your solution is configured in Debug mode.
Build whilst your solution is configured in Debug mode.
I had a project that I didn't want to be a web application I wanted it to be a folder. The answer was to delete the web.config file altogether. It only belongs in the root of an application.
If you face this problem while publishing your website or application on some server, the simple solution I used is to convert folder which contains files to web application.
I've got the same problem in VS 2013 after publishing my project in debug mode. The problem has been solved by removing obj/ files
I have a website project.
In my case I had moved the solution file to another path and that cause the problem. I restored it to the previous location and the problem went out.
For any one still looking, my solution was to delete both the bin and obj folders and restart visual studio seems to fix it.
Via Visual Studio, I had published a WCF Service via FTP, to an external server. It worked fine locally, and when publishing to an internal server, but not to the external. The solution was to publish without providing a Site Path (in other words, publish directly to the root of the virtual directory).
I'm not sure why it worked, since I had already tried moving the files to the root via an external FTP Client - among many other attempts, including all listed here. Maybe it was something with the publish profile, like it was for FabianVal. But I'm not in the mood of testing anymore at this point, since I'm in a hurry to get up to speed after all the days wasted on this problem.
tip 1: clean & then rebuild.
tip 2: just close VS and open again.
tip 3: the downloaded project may be inside another sub folder... open the folder which has you .net files.
c:/demo1/demo/
(all files)
You should have to open demo from vs... not demo1.
I tried every solution above, but none of them worked for my problem. (I'm sure there are 1000 solutions to this problem) For my scenario, I was attempting to publish my WCF web service that I had in test into production.
However, I failed to realize that in production we are HTTPS only, meaning we redirect everything to HTTPS. As it turns out, I was pointing to the service via HTTP instead of HTTPS, thus causing the error. The solution in this scenario was to simply to change the address protocol to HTTPS rather than HTTP.
I hope that helps some poor soul out there trying to figure out this problem.