Without your having defined an interface that's being both implemented and referenced, there's no (easy) way for the compiler to know that your "change [to] the implementation" didn't (for example) remove a method, or change the datatype of a parameter or the number of parameters to a method.
Pascal dialects (Delphi, Chrome) have an "interface" section that's logically separate from the "implementation" section (though stored in the same source file), and the compiler can keep enough info about the interface to be able to detect whether the interface has changed, and re-compile dependent files only if it did. In C# it would be possible, but considerably harder, to do so. (It's the same problem as "do we need to run the routine to re-generate the documentation?" You do if the public interface changed, but not otherwise.) At 10:24 AM 12/1/2005, Dmitry Shaporenkov wrote >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/ J. Merrill / Analytical Software Corp =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
