Dealing with dependencies in a large project... Is it possible to reliably alter build order without using project dependencies in C#/VS2008?

views:

answers:

Dealing with dependencies in a large project... Is it possible to reliably alter build order without using project dependencies in C#/VS2008?

I've got a legacy project in VS2008 that we're about to start refactoring for better componentization. The references between the 150 projects in the solution are messy, so as a starting point, I'm trying to at least get to a point I can have a few projects use binary references to other projects while others use project references. (For build time reasons)

To Illustrate, given projects A, B, and C, I'd like to see...

A references C.dll

B references C.csproj

Now the problem is I need to make sure that C.csproj builds before A.csproj. I know I can control build order using project dependencies, but this appears to cause exactly the behavior I'm trying to avoid... building A always causes C to build. I'm sure I can monkey with the proj or sln files directly to get things to build in the order I want, but I'm also sure that will get overwritten in short order by VS's automatic magic.

Is there some way to control this order reliably, or am I missing something obvious here?

Thanks...

+1 A:

You could make custom msbuild files instead of relying on the .csproj and .sln files, such that, depending on the target chosen, it will only build certain assemblies. It would require learning msbuild if you don't know it already though.

SnOrfus 2009-12-03 03:55:18

Here's a link to the MSBuild reference. http://msdn.microsoft.com/en-us/library/0k6kkbsd.aspx

Chuck 2009-12-03 04:03:17

That's what I'm thinking, just hoping there might be a "quick" answer.

Jim Leonardo 2009-12-03 06:34:31

Also note that the MSBuild reference is pretty close to terrible. Check out http://www.amazon.com/Inside-Microsoft%C2%AE-Build-Engine-PRO-Developer/dp/0735626286 - It's dry and redundant, but informative.

SnOrfus 2009-12-03 15:44:02

+1 A:

Separate related components (.csproj) into individual solutions. This enforces binary references across package boundaries. It also forces you and other developers to group components by layer.

Then use your build process to build solutions in correct order starting with the least dependent packages.

In my estimation, from an SCM standpoint Solution == UML Package == Merge Module (all solutions create a merge module)

dkackman 2009-12-03 03:58:24

That's my preferred solution as well, I just have some handcuffs on right now that keep me from getting there.

Jim Leonardo 2009-12-03 06:29:50

Personally I would find using a mix of project and binary references to assemblies within the same solution confusing. I would start with the very obviously leaf component projects (those without references to other projects) and move them out into a separate solution. It's a start at least on getting the project per solution count closer to reasonable number.

dkackman 2009-12-03 15:17:38

There's a top level project in the solution that seems to reference almost everything directly that's giving the most grief here. I ended up creating a second solution with a second project for that and so was able to have a second fast build solution and the older slow solution. We're trying to get to where you suggest.

Jim Leonardo 2009-12-03 17:08:59

good luck! In my experience efforts like these pay big dividends.

dkackman 2009-12-03 17:47:57

ansaurus

tags:

views:

answers:

Dealing with dependencies in a large project... Is it possible to reliably alter build order without using project dependencies in C#/VS2008?

related questions