Real-world solutions typically consist of multiple projects - often many projects. The projects are usually related to each other in some sort of dependency relationship. For example, consider a solution with 3 primary output targets (P1-3), a few intermediate components (I1-5), and a few shared dlls (L1-3). The dependencies might look something like this (totally arbitrary, but plausible example):
Solution: P1, P2, P3
P1: I1, I2
P2: I1, I3, I4
P3: I5, I2
I3: L1, L2
I4: L1, L3
Now, this might be a really big solution. Who knows—it might take an hour or more to build the whole solution. But you probably don’t do full builds every time you make a change. Here, incremental build is your friend. Making a change in P1 only requires a build of P1. No surprise. But what if you make a change in L1? It depends on what kind of change, of course. If you change something in the headers that dependents of L1 use (or idl, etc.), then you’re basically rebuilding the whole world (everything except L2, L3). If you only change an implementation detail, nothing else needs to be rebuilt. That’s the way it’s been for years in the native world.
But suppose you’ve decided to use managed code for part of your solution. Now you have a solution with both native and managed projects. Maybe you started with an existing huge solution, and you added a project written in C++/CLI or your managed language of choice. And maybe this project is a common dependency in your solution—your L1. As before, if you change something in L1 that affects the build of dependents, then all the dependents will build. Ok, but what if you only change a tiny implementation detail? In Visual Studio 2005 and earlier, we would rebuild the entire dependency tree from L1, because the assembly changed! This can really slow down iteration times when making implementation changes in L1. With Managed Incremental Build in Orcas, however, this scenario is greatly improved by not rebuilding anything else when only implementation details changed in L1.
How is this done? With a managed L1, you don’t need headers or idl files for the contact. The assembly is the contract. So there’s no simple file to check to see if it changed to determine whether dependents need to be rebuilt. But now, when a managed dependency changes (even if it’s not in your solution), we reflect over the exposed metadata in the assembly and save it. If there is already a saved version of this data, we compare it. If it is the same, then the assembly hasn’t changed in any way that impacts the build of dependents, so they are not rebuilt. If the metadata is different, then dependents are rebuilt.
Build times in Orcas are now dramatically slashed for solutions where only an implementation detail changed in a dependent assembly.
Visual C++ IDE
Lots of VC++ happening recently (in no particular order): ATL Server is now shared source Marina Polishchuk
Thank u very much for this feature!!!
In our company (medium game developer) we have invested a lot in C++/CLI, all our tools are written in it in top of the native C++ game engine. Because of this dependency problem our average compile time is above 10 minutes, and this is something that degrades productivity, which is precisely the reason we choose .NET and C++/CLI.
Hey again, everyone. I’m Peter-Michael, a program manager with the VC++ compiler team. Continuing with
To allow customers to evaluate and plan for our upcoming "Visual Studio Orcas" release (and to highlight
This should be the best thing since sliced bread! Thank you!
<a href= http://pornositeworld.biz/map.html
[原文地址] VS 2008 Performance Improvements [原文发表时间] Thursday, September 27, 2007 4:52 PM 在 VS 2008 中 ，我们就开发人员所关心的一些常见的使用场景在性能上作了很大的改进
A couple of weeks a go I blogged about the performance improvements in Visual Studio 2008. In response
[原文地址]: VC++ Performance Improvements in VS 2008 [原文发表时间]: Wednesday, October 10, 2007 5:59 PM 几个星期前