If you are like me, you like to use the XML commenting feature that comes with .Net. Personally, I only turn this feature on when I am creating a release build. However, if you do this make sure that you turn-off the read-only property on the output xml file. Failure to do so can will cause your build to fail.
This happened to me recently with a rather large solution set and I could not for the life of me figure out why all of a sudden when I switched to release build my solution set failed to build properly. If it was just a single project solution or a small solution set, it might have appeared obvious. It was only after I did a 'clean' of my obj and dll files that I was able to see that it was unable to write the output xml file that the error became more pronounced in my output. I quickly turned off the read-only attribute and it finally built. I hit this problem a while ago...but my memory must be fleeting.
Note to self: When doing a release build make sure to turn off the read-only attributes on the generated xml file (I keep this file in source safe with the rest of my project files).
-Mathew C. Nolton
A friend of mine sent this to me. It is too funny. The guy turned his George Forman grill into a WebServer. It takes a while to bring up the page. Apparently the George Forman Grill/WebServer is actually serving up the web pages.
Most people use the web.config file to define features or pieces of functionality to be used by their application. You may or may not know it, but there is a feature of the web.config file that enables you to remove definitions defined by a parent web.config file. This is especially important when an application (either rightly or wrongly) places a web.config file in the root web directory or your parent directory that adds functionality or puts a constraint on all child directories that you do not want or that will break your application.
The web.config file has a heirarchy of sorts. All applications pick up their defaults from the machine.config file. Your application then uses any parent directory web.config file before using it's own web.config file. This means that if you are a couple levels deep and your parent directories have web.config files defined, you will pick up your defaults first from them before your own is processed.
This heirarchy is helpful when carefully planned; however, if a parent directory makes assumptions that are not valid or the person deploying the application does not consider all avenues, it presents a problem. I ran across this situation when a commerce server implementation added some .net functionality and placed a web.config file in the root web directory. When I deployed my .net application I inherited all of its defaults....which would have broken my application. To get around this, I used the <remove/> tag of the web.config. For example, the CommerceServer implementation defined a number of commerce server pieces that I did not want...nor could my application handle:
<remove name="CommerceServer/application"/> <---- Most sections enable you to remove
<remove name="CommerceApplication"/> <---- Most sections enable you to remove
<compilation defaultLanguage="c#" debug="false">
<remove assembly="Microsoft.CommerceServer.Runtime, Version=4.5.2002.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/> <---- Most sections enable you to remove
<customErrors mode="RemoteOnly" />
Be carefule using the <clear/> tag, it will clear out everything for that section including defaults from the machine.config file....Typically, you do not want to do this.
Overall, if you have a parent application or parent web directory that isn't well-behaved, you do have options in working around this problem.
-Mathew C. Nolton