| Comments

i ran across a potential snag some of you may be experiencing in visual studio web developer release version.

one of the goals with vs2005 was “intellisense everywhere” — and it was incorporated everywhere, even web.config files.  here in lies the issue.

create a new web.config file — by default it is created correctly and you should have intellisense.  save it and close it.  now open the web site administration tool (Website menu…ASP.NET Configuration) and make some changes.  go back to your web.config file and you may notice that the root node <configuration> now has an xmlns in it (which is the namespace for the config environment). 

now, try to use intellisense in that modified web.config.  does it work?  if so, great.  if not, you hit the snag i did — i’ve been able to repro it but haven’t been able to isolate if i’m the only one.  the workaround is to remove the xmlns attribute on the configuration node to get the intellisense back…which leads me to potential bug #2.

put your web.config in source control and check it in.  close the file.  now go back to the web site administration tool — do you get a message saying you need to have web.config be editable?  or does the file get automatically checked out (because of your settings)?  the WSAT tool for some reason needs the web.config to be editable (i don’t think it does, it just thinks it does) all the time, even when you aren’t modifying web.config properties.  this is an annoying issue, but the workaround (if no changes are made to web.config) is to either (1) undo checkout (if you don’t want erroneous source control audits) or (2) checkin the file again.  again, this is annoying because of bug #1.

i want to point out these are DESIGN TIME issues only — no runtime execution is affected (with or without the xmlns, the web.config is readable).  if they are annoying to you and you want them fixed, please submit your vote for the existing ladybug requests.

bug #1 feedback

bug #2 feedback

Please enjoy some of these other recent posts...