I've learned that web.config will inherit across applications on the same site.
I've learned that this is true, even if the child application is a virtual application, not in the same directory tree as the parent, and even if it's not on the same physical drive.
I've learned that the <location> tag has an attribute called InheritInChildApplications to control web.config inheritance.
I've learned that the <configSection> tag cannot be nested in a <location> tag.
I've learned that ASP.NET 3.5 has conflicting <configSection> tags with ASP.NET 2.0 child applications, if you used AJAX controls.
I've learned that no amount of quality control, unit testing, regression testing, or continuous integration on your application will catch it breaking another unrelated application hosted on the same server.
I've learned that when deploying an application update to the test environment, it's good to check the other applications as well, just in case.
I've learned that rolling out changes to production should not be done right before leaving for lunch.
I've learned that when I've taken down all the web applications on a server I can edit every web.config to fix the problem in an amazingly short amount of time.
(credit to Carl Franklin of Mondays for the style)
Posted By Mike On Friday, March 21, 2008
Filed under asp.net developer |
Comments (2)
Dylan
-
Friday, March 21, 2008
4:50:54 PM
"I've learned that no amount of quality control, unit testing, regression testing, or continuous integration on your application will catch it breaking another unrelated application hosted on the same server."
Yeah, I learned this the hard way: http://www.dylanwolf.com/programming/46/
Servers are rarely set up in a clean and compartmentalized way in the real world, unless special care has been taken to set them up that way. (Also, virtualization is awesome for this, because the cost of additional hardware isn't an excuse to throw everything on the same machine.)
It's not so much that you <em>can't</em> test for it, it's just that being able to set up a test environment that actually mimics the live environment would take so much time and effort that it doesn't balance out the chance of actually having one of these issues occur. Especially when you can't adequately predict where the incompatibility is going to show up--trying to test every function of every application, etc. So testing is in one sense an economic and statistical problem.
I just know when we had our issue with IIS and Outlook RPC, "why didn't you test for this?" was the first question asked, followed by the suggestion that we should set up a test system <em>exactly</em> like our real system to make sure this never happens again.
I'll let you know when someone actually has the time to do that.
Nathan Blevins
-
Saturday, March 22, 2008
2:23:52 AM
So, the real question is, "Did you learn all of this at the same time?" lol...
I have to 3rd the following:
"I've learned that no amount of quality control, unit testing, regression testing, or continuous integration on your application will catch it breaking another unrelated application hosted on the same server."
So very very true... and painful.
