It all depends on what you mean under 'related'. The projects rebuilt by VS do reference the root project (either directly or indirectly, via other referenced projects). But there is no real need to rebuild them if I change the implementation of a method in the root project - nothing in the output assembly of a dependent project contains links to the code of the modified method.
> -----Original Message----- > From: Discussion of advanced .NET topics. > [mailto:[EMAIL PROTECTED] On Behalf Of Vince P > Sent: Thursday, December 01, 2005 6:02 PM > To: [email protected] > Subject: Re: [ADVANCED-DOTNET] What is the .NET equivalent of > Java's MANIFEST.MF? > > 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 =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
