Here is one point of view. The dll locking problem may be at times an indication of too many classes in a single compilation unit. At 64K, this is certainly *not* always true, but it has always been an annoyance to me that in VS.Net, one project = one dll. It seems like a relatively simple option would be to allow a project to specify that folders in vs.7 projects *could* compile to their own dll. It would accomplish a few useful things.
- large projects would have another combining point between solution, project and file that would make it a little easier to manage patch rather than full deployments of dlls. - the number of projects and project references could go down in a solution - Until the 64K dll size problem is resolved, developers would have an additional technique to keep dlls sizes smaller. - Strongly typed datasets, kept in a separate folder could have the xml documentation feature turned off, so the project as a whole could have it turned on without those massive numbers of xml comment warnings. --- Eric Gunnerson <[EMAIL PROTECTED]> wrote: > Tomas, > > I appreciate your frankness. > > One of the things that I now own is the project system for future > versions. I think I understand many of the problems with it, but I'd > like your perspective to make sure I know all of them, and which ones > are the most important. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
