I haven't noticed VS rebuilding projects that were unrelated to the chain of changes... Regarding have to recompile at all.. Well seems to me that it's rather basic why a change to the implementation of a project would require a rebuilding of the DLL/Exe file.
1) I believe the next dependent project uses the code in the compiled assembly and not the source code itself (unless you're steppign through code in VS.. In which case it always complains to me if the source code is changed since the assembly was made) 2) The solution isn't the exclusive owner of that project. Other solutions may be referencing that project too.. So unless the assembly was updated how would the other dependents get to use the new implementation. I'm prolly missing some basic point you made somewhere and I'm probably sounding like an id :) Vince By claiming God As his holy right | He's stealing a God From the Israelites Stealing a God From the Muslim too | There is only one God Through and through - "John the Revelator" - Depeche Mode -----Original Message----- From: Discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Dmitry Shaporenkov Sent: Thursday, December 01, 2005 6:56 AM To: [email protected] Subject: Re: [ADVANCED-DOTNET] What is the .NET equivalent of Java's MANIFEST.MF? Is anybody aware of such an advanced compiler? Offtopic: In my experience, long build time of large C# solutions containing of many projects wich complex dependencies is one of the biggest problems with VS.NET (both 2003 and Whidbey). If one changes the implementation of a method in one of the root projects (that all other projects depend upon) VS performs totally unnecessary rebuild of all other projects, although only implementation changed, not the interface of the root project. I know this is offtopic, but it's interesting what approaches do people use to tackle this problem? It seems for me that Java classfiles are much better suited for incremental build, and hence Java development environments have had such a possibility for a long time already. And we're still in the stone ages... P.S. Many people would object that separating interface and implementation into different assemblies is a solution to the problem. I don't really think so as this is not always applicable and tends to create too many projects. > -----Original Message----- > From: Discussion of advanced .NET topics. > [mailto:[EMAIL PROTECTED] On Behalf Of Ian > Griffiths > Sent: Thursday, December 01, 2005 3:42 PM > To: [email protected] > Subject: Re: [ADVANCED-DOTNET] What is the .NET equivalent of Java's > MANIFEST.MF? > > > (As an implementation detail, there's nothing stopping a compiler > performing some kind of optimization here. For example, your compiler > could compile each individual source file into per-source-file binary > files that it stores as part of its build output. So it wouldn't > actually need to recompile everything. So whether or not the > recompilation really happens depends on the compiler. But that's just > the implementation detail - all that really matters is: does the build > take too long?..) > > > -- > Ian Griffiths - Pluralsight > http://www.interact-sw.co.uk/iangblog/ > =================================== This list is hosted by DevelopMentor. http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
