Ian:
I know this is the intention. The problem is that the unhooking of the *.config files doesn't seem to always work according to intention. This and other similar settings stay in there and then you accidentally check them in (surprise :-). As we all know there are potentially a zillion possible reasons for things not to work as intended and automagicas are particularily plaqued by this.
I am just wondering whether this one has someting to do with/or is correlated with the fact that we had too cloak the bin dirs The reason we had to cloak the bin dirs was that the bi(nary) products where beeing added to source control all the time. You don't want your bin/*s checked into source control. I mean its called SOURCE control isn't it Actually theres an awful lot of stuff that by default gets added that in an ideal world probably shouldn't be like web references, app_offline.htm etc.. The app_offline.htm is a rarity but it happens. It gets created from time to time and then it gets added to SCC. Haven't seen a lot of this behaviour since RTM though but I saw it yesterday. To be precise I saw it get created, getting the yellow plus sign saying added to FS and then it vanished again, so probably there has been a fix in this area.
Anyway, I'm rambling on. Do you suppose we are dealing with sideeffects of the fact that we started building this solution on VS Beta 2 Maybe a good trick would be to make copies of the existing configs and ask VS to make us some new ones and then carefully put back the things we actually want there like EntLib etc. I wonder...
Brumlemann Solution Architect
PS Wouldn't it be better if the cassini server or the code cov, instrumentation and/or test processes just knew where the assemblies it needed where Does it really need to be refered to from my config Just asking.
PPS Alternatively is there any tool or command out there (or in here) that can help me unhook the hooks when VS forgets to unhook it :-)
|