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.
Related
lets say I have two ASP MVC applications.
ProjectXXX
ProjectYYY - this is fork of ProjectXXX.
Both projects have same structure (project/assembly name), but it differs on some functionality (it will be deployed for other countries).
For testing purposes we deploy both applications on one server.
ProjectXXX - has own IIS pool
ProjectYYY - has own IIS pool
Problem
When I removed some functionality from assembly of ProjectXXX and run ProjectYYY it throws TypeLoadException : Could not load type 'Project.Namespace.IMyInterface' from assembly 'Project.Namespace'
It looks like ProjectYYY uses DLL from ProjectXXX (IIS (asp.net?) loads dll once, because it "thinks" assemblies are the same?)
How to force IIS not to cache those assemblies and load the proper one for both apps?
EDIT / SOLUTION:
I have found, that my application uses MEF composition. As for now I have changed how it searches for assemblies and problem looks like gone :)
if you create separate IIS Site for each, it should do the trick, as for each site a separate w3wp process is run. Having said that, you can't share same ip and port for 2 sites so if you need that, you'll have to play around with redirecting, url rewriting on IIS.
I want to run my new web application with forms authentication under the ASP.NET Development WebServer (Cassini), but not at site root "/" (rather, at the path it will reside in production; "/New").
However, the build process gives the 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.
New.MvcWeb\obj\debug\csautoparameterize\original\web.config"
Now, I understand what it is saying. I have forms authentication enabled in my web.config in a virtual directory. The error goes away when I remove the web.config, or remove the "virtual path: /New" debugger configuration, or move debugging from Cassini to IIS and manually create an application at "/New".
But it is only a 'virtual' directory in the mind of the Build System. The path IS application-enabled in a production IIS setting. Also, if I remove the web.config, Cassini will happily publish "http://localhost/New" as an application (for example, Server.MapPath("~") returns my project directory without the "/New" suffix); however I need forms authentication (an application-level web.config parameter) enabled in it.
How I can avoid this build error while retaining my desired features?
More Details
The project is currently configured for "file-system" site development. This and Cassini are supposed to make it easier for my content creators to participate in development and testing with their local copy of VS2010, without having to install IIS on their Windows PCs. I will also one-click publish to my local IIS for testing, then package/publish/deploy to public test, then finally publish to production. In my mind I imagine Cassini being a very helpful part of this whole process.
VS2010, MVC application, file-system site project
Project Settings:
* ASP.NET 4.0
* Use Visual Studio Development Server
* Virtual Path: /New
web.config snippet:
<authentication mode="Forms">
<forms loginUrl="~/../login.html" timeout="30"/>
</authentication>
I'd generally argue apps should never care if they are running as the root or in a sub-uri. I'd also say that, in 2010, with IIS Express coming, it makes no sense investing any time nor heartache in fighting cassini. That should support your requirements much better.
EDIT FOR MORE DETAILS
Interesting updates about IIS express. We do some of the same things for our design types -- we'd rather they implement the designs rather than the programmers lose hours of their life pursuing individual pixels. We found it easiest to basically treat the designers' machines as essentially continuous integration build agent. They run IIS and build using the same command line build script the CI boxes do. Works surprisingly well. In both cases you have a machine that can't care for itself, so everything needs to be scripted. The IIS bit gets setup once generally as we keep it pretty simple and it rarely needs tweakage with modern versions of .NET. Hope this helps.
So, having learned that Cassini actually does run paths as applications [i.e. Server.MapPath("~") returns the project root folder, and Server.MapPath("/") may not exist], it really becomes strictly a build error.
With a better problem definition, I now see other people also have this error in MVC projects with MvcBuildViews and One-Click-Publish. Here are some articles on how to avoid it:
allowDefinition='MachineToApplication' error when publishing from VS2010 (but only after a previous build)
http://connect.microsoft.com/VisualStudio/feedback/details/556312/mvcbuildviews-does-not-play-well-with-one-click-publish
Hi guys,
We have a mixed development environment of three servers running: Win Server 2003 & 2008, IIS 7 & IIS 6, ASP.NET 2.0 & ASP.NET 3.5. Previously, all three servers were Server 03/IIS6/ASP.NET 2.0, but with this new change, I am finding that pushing/moving any applications from server to server is always a terrifying experience because there are always a variety of problems with the web.config from server to server. I used to consider myself a confident ASP.NET developer but now I am frightened to come to work every day.
I have always used the web.configs that VS generates for me on the Win 2003/ ASP.NET 2.0 server. None of our web.configs are "leet", they are just normal, although we do use ScriptManager and UpdatePanel.
To get by, as a temporary fix, I'm having to remember that when projects are moved/tested/deployed, never to move or overwrite any web.configs and things get confusing very fast. I've tried "ducttaping" like suggested here my web.configs with the new IIS7 stuff but even that doesn't work all the time.
What can I do here, what's going on? Is there a standard web.config that will work on all of the servers and do the UpdatePanel and ScriptManager ?
[edited question]
Since IIS6 is the baseline install for your application, you should make sure to run the application in "Classic" mode under IIS7. This makes configuration the same as an IIS6 box. This is how we run our web applications for now until we have fully migrated to 100% IIS7 server environments and we have zero problems with deployment/runtime.
To do this you can either choose to run your app under the built in "Classic .NET AppPool" that comes with IIS7 or, assuming you create your own custom application pools, just make sure you set the "Managed Pipeline Mode" to "Classic" under the "Advanced Settings" dialog for the app pool.
You should seriously look at web deployment projects for visual studio 2008.
This is an official add-on for Visual Studio that gives you a new project type called web deployment project. Among the most useful features is the ability to do web.config search/replace as well as pre-compiled builds of your web sites or web application projects.
In your case, what you'd do is create a solution configuration in visual studio for all of your target web servers. Then you'd create a web deployment project for your web app. In the properties for the deployment project you tell it how you want to compile the project and what web.config replacements you want to use for each solution configuration.
The end result should be that you can open Visual Studio, pick a solution configuration, build the deployment project. The build will create a folder with everything you need for that environment including the correctly configured web.config files. Then you just copy the folder to your server and you are up-and-running.
Best of all, since the different config files are all stored in the projecct, it lets you manage your configuration in one place and check it all into source control.
Do note that there is no equivalent in Visual Studio 2010. Instead, VS 2010 has a whole new deployment mechanism called MSDeploy. With 2010 you don't need a seperate project for deployments, and MSDeploy goes a lot further allowing you to package your SQL databases and other stuff too.
You can use the Classic mode under IIS6 by changing the process. That is actually pretty simple and it should work.
Another approach would be to automating your deployment process and have it so that it deploys the correct web.config to the server when you need to update your application.
If you run your IIS 7 websites using the Classic .NET App Pool, then the config files will match what you would use for IIS 6. That's probably the easiest thing to do until you're ready to migrate everything to IIS 7.
Knowledge is a great way to get over fear. Figure out what's going on (you're currently grasping at straws) and the fear will go away.
It's my guess that you'll do better if you refactor the code that uses the config file. Sloppiness there can definitely explain your weirdness and inconsistencies. You can't control much with your config settings if the code isn't behaving properly.
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).
I'm comparing it Java where you can start your application server in debug mode, then attach your IDE to the server. And you can change your code "on the fly" without restarting the server. As long as your changes don't affect any method signatures or fields you can just hit recompile for a class and the application server (servlet container) will reload the class.
I suppose this is impossible in ASP.NET since all classes are packed into assemblies and you cannot unload/reload assemblies, can you ?
So when you have an .aspx page and an assembly deployed to GAC and your codebehind changes you have to redeploy the assembly and reset IIS. I'm talking about Sharepoint applications in particular and I'm not sure whether you have to do iisreset for private assemblies but I guess you have too.
So the best way to debug aspx pages with code behind I guess would be to get rid of the codebehind for the time of active debugging and move into the page, then when it is more or less working move it back to codebehind. (This would be applicable only for application pages in Sharepoint, site pages don't allow inline code )
How do you approach debugging of your ASP.NET applications to make it less time consuming?
From Matt Smiths blog on how to get F5 debugging with sharepoint. A very cool trick.
Create a web application project in Visual Studio (File -> New -> Project -> ASP.Net Web Application, not File -> New -> Web Site).
Move the .csproj and .csproj.user files, along with the Properties folder, into C:\inetpub\wwwroot\wss\virtualdirectories\, where is the name or number of the web application corresponding to the SharePoint site you'd like to debug on.
Attach the project to an existing solution (e.g. STSDEV project).
Set as startup project (right-click project name, "Set as Startup Project").
Access project properties (right-click project name, "Properties") and click
Under the "Servers" setting, click "Use IIS web server", then enter the URL to the SharePoint web application you want to debug on, e.g. http://mymachine:99.
Yes private assemblies DO NOT require reset of the IIS. So you should just to xcopy new version to the application's Bin directory and refresh the page (e.g. by VS post build event as I did).
But there are some trade offs. You should decrease trust level in application web.config file:
<system.web>
...
<trust level="WSS_Medium" originUrl="" />
...
</system.web>
By the way. I do not suggest to deploy like this. It's just workaround for comfort write-test-debug cycle length.
If you are using the GAC, you can at least do iisapp.vbs /a "App Pool Name" /r instead of iisreset (it's quicker to recycle a single app pool than to restart IIS).
First, develop on a computer running SharePoint. Preferably, this means running Windows Server 2003 on Virtual PC or VMWare. This will let you deploy and debug SharePoint code directly, rather than having to copy files between servers and use the remote debugger.
Use a VS add-in to simplify the process of deployment and debugging. I've been using WSPBuilder but I think there are others out there. WSPBuilder has commands to deploy solutions, package them as WSPs, and attach your debugger to the local IIS process. It won't allow you to add/remove assemblies on the fly, but you can set breakpoints and run code through the Immediate window in VS.
Depending on how your production server is configured, it's usually a good idea to develop on a server with full/trust security settings, including disallowing code blocks in ASPX files. This makes debugging a little more difficult, but it reduces the number of nasty surprises you'll have when your code is finally deployed to production.
And you can change your code "on the fly" without restarting the server
You can accomplish this with ASP.net if you make a Web Site project (as opposed to a Web Application Project). Using a Web Site project, you can post changes to code-behinds without having to refresh anything on the server, and the server does the compile work for you on all code changes. See here for more info on this.
This should also solve your difficulties with deploying the assembly to the GAC. As the server handles all compilations for Web Site projects, you wont have to redeploy any assemblies when changing files.
Use an automated testing framework (NUnit) to write integration tests. This won't work for everything, but of course, it depends on what you're testing.
If you also have TestDriven.NET installed, you can run individual tests with the debugger. This has been helpful.
WSPBuilder Extensions has a "deploy to GAC" shortcut, unfortunately it never works for me. But it's a really quick way to code->compile->test.
If you're not using WSPBuilder Extensions, you can instead open a command prompt and run
gacutil /u yourassemblynamegoeshere
gacutil /i yourdllgoeshere.dll
If you do this often, you can put it in a post-build event or in a batch file. Also, I'm unclear whether the gacutil /u (to remove the DLL first) is necessary.
What it seems like you're trying to do is tell Sharepoint "When I start debugging in Visual Studio, use the version of the DLL that was compiled in the project's /bin/debug directory instead of the version of the DLL that is registered in the GAC." I haven't solved that problem, but here is how I debug Sharepoint.
A developer machine is Win2008, IIS 7, MOSS 2007, VisStudio 2008, and WSP Builder installed. Inside VS2008, a button is added to attach to w3p.exe process, Andrew's HOWTO attach to w3p
The solution file has two projects:
* First project is the .WSP that deploys all the app pages, including the DLL. Use WSPBuilder menu items for handling the .WSP creation and deployment.
* Second project is for the DLL behind the pages.
If you want the DLL to be copied to the GAC regularly, add a post-build event to the DLL's project that copies from /bin/Debug to the GAC. But, these days, I find I have just been recompiling the solution and then deploying the .WSP using the menu items, and then starting up the debugger using the button. It takes me an F-key and 3 clicks and about a minute for most of my projects, but I suppose it could be quicker.