Beware Visual Studios Bearing Gifts of Pretty Markup!

This one bit me again last night.  The problem is that something mysteriously adds <assembly /> elements to the <compilation /> section of the web.config file.  I had previously attributed the problem to the ASP.NET compiler, but it seems it was not the compiler.  I ran this problem by some friends a while ago, and they said they'd seen it with Visual Studio, but I was assured the compiler couldn't be it. 

Last night I confirmed it is indeed VS (unfortunately).  I innocently opened a user control on the Web server to verify something (note that I was only reading the file--not modifying it--and it was independent of any configured Web site or project).  Visual Studio, wanting to be as helpful as possible, I presume tries to back track and resolve references even for files not within a Web site or project.  Part of this process is, apparently, it trying to add references to the web.config that it thinks you need.

For me, the problem was two-fold.  First, I never want a tool to automagically modify any file on a Web server (that's just bad mojo, IMO)--especially not web.config--but it was compounded in that this app uses the <location path="." inheritInChildApplications="false /> approach to isolate some of the settings to this app and prevent them from being inherited in sub/child applications.  Part of the isolated settings is the <compilation /> element, under which is the <assemblies /> element that tells the ASP.NET compiler about referenced assemblies, and VS apparently does not understand that isolation mechanism, so it added its own <compilation /> and <assemblies /> elements to help it figure out what was going on in the user control I was looking at. 

Well, <compilation /> is one of those that you can only have one of, so as soon as it did this, I started seeing the dreaded hey, this app is configured such that we can't even show the custom error page that is configured message (you know, the one that tells you to turn customErrors=off so you can see the actual error?).  Once I turned custom errors off (not my preferred thing to do, of course), I saw the real exception being that there was more than one <compilation /> element (which is easy enough to resolve).

That jogged my memory about the other times I'd seen this and then I remembered my friends suggesting it was Visual Studio, which further jogged my memory that I had indeed just used VS to view a UC, and it all fell into place that it was VS this time (and likely the last times I've seen this).  I didn't suspect it because 1) VS is configured to open AS*X files for my box (default when it is installed) and 2) I never thought that just opening a file in VS would give it carte blanche to start modifying my web.config; IOW, using VS to view .NET files is so mundane that it was never logged in my brain that I did it and thus, until last night, didn't make the direct connection between VS and the modification of the web.config.

So the moral of this story is to learn from my mistake and debugging.  Sadly, I guess this means I can't use VS to view ASP.NET files on servers.  I've also marked web.config as read only in hopes that will prevent this should someone inadvertently open a file in VS.  To be clear, I try to stay away from the servers (and generally out of the way) and let the experts do the work, but I was trying to be "helpful" last night.  That'll teach me! 

I'll have to look at Notepad++ again.  Any other recommendations for quality--but harmless--editors?