Has anyone else had a problem with this setting in VS.Net? We are seeing huge pain in the rear issues with this property setting. We have a multi- tier application. For development purposes, we have all tiers on each developer's machine. We have a case where the webservice facade layer access both middle-tier and data tier. Obviously, the middle-tier also reference the data tier. This copy local properties on assembly references causes so much pain in building, debugging, and intellisense. What we see is VS.Net automatically using the older, cached version of an assembly. If you have multi-solutions, you have to find out which assembly is the problem and then go through and refresh it in all solutions. This is such a pain.
Turning it off helps significantly, but the default of this property is "true". Also clicking on the resync button in the solution browser helps. It doesn't make sense, this was put in there to help speed development, but it slows us down with it's inability to work right. This property seems like a quick hack for quick builds in monolithic applications. Anybody got suggestions on getting around VS.Net's inability to determine which assembly version to use during builds, debug, and intellisense? Or are we stuck with this tedious feature till version 2.0? This feature reminds me of the problem with incremental compilation and linking with COM projects. Why couldn't MS keep it simple? (kinda rhetorical based on their history) Why cache something that only saves 2 secs on the build time for simple projects? It ends up adding 1 hr to development time on big projects. Perhaps we don't know the best practices yet. -Loc You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
