Dave Burke : Freelance .NET Web Developer specializing in Online Communities

5/9/2005 8:27:48 PM Permalink

Hey Man, just because you're from Vermont, doesn't mean you get to shut the hell up your fellow developers ;)

Sahil Malik |

5/10/2005 11:52:00 AM Permalink

Some attend to be 'entertained', and some to be 'informed'.  I guess Dave wants #1.  I'll take #2 anytime!  Oh, and thanks for asking my unanswered question again, Dave!

Many of us want the Microsoft reps to go BEYOND the "Wham-Bam-VB-Man Tutorial #1 Oooh and Aaaah Fests" and get to substantive issues that have proved to be roadblocks to otherwise productive tools in MSLand.

Maybe THEY can call ME when a "solution" to my "Solution" is found?  I won't hold my breath (or, for that matter, my nightly build...)

Bob RobinsonTrue |

5/10/2005 7:44:36 PM Permalink

Holy Shit.  I guess I missed a good one .  Too bad I was in the Dominican on vacation.

Ali Aghareza |

5/11/2005 4:50:30 AM Permalink

My appoligies for the double-post.  I got a 'giant' ASP.NET error message both times I submitted and I assumed it didn't get thru; but I see that they both made it after all...

For Thom: "So long, and thanks for all the pizza!"

Bob Robinson |

5/12/2005 1:05:25 PM Permalink

Dave,

Yep, that was it.  On my team we have 6 or 7 people all creating functionality for a single, giant VS6/VS2003 C++/C# application.  When they do that (in VS 2003 .NET now), they generally create a Solution (.sln) file to wrap their individual project(s) into and from which they do development builds and initial testing.  When we want to integrate the new code into the mainline build, we have to do all the same work they did for their initial .sln, only this time in the giant "full build" .sln file.

If we could just "import" or "include" their pre-existing smaller .sln file into the main build, we'd save time and money.  But we can't.  So we have to spend unnecessary time remembering each and every little property 'tweak' and all the other settings issues (some of which have already been forgotten by the time you get a project working) in the main .sln file before it will 'play nice with the other' projects in the build.

Worse yet, we also have to manually handle dependencies of dependencies introduced by the new .sln incorporation.

If this ADDED value, I wouldn't complain.  If it enforced additional checking, or provided a means to 'double-check' the work, something like that.  But it doesn't.  It just breaks the build until all the little tweaks which had been applied by the developer the first time 'round (creating the new .sln) get duplicated a second time (into the main build .sln).

From Thom's remarks, *maybe* the 'Big Build' part of Team Server addresses this; but frankly we've been so dissapointed with "groupware" over the years, that I'm not even inclined to *believe* MS when they say they "have a solution" for that problem.  Also, since we're still running the VS 6.0 compiler for older components, I'll take a stab at guessing that MS's new wiz bang server won't recognize or allow you to include VS 6.0 builds in a 'big build' anyway.

We have a working 'big build' solution ourselves now that we hand-rolled from scratch, and at least know how to modify when new projects are added.  I'm disinclined to trust MS that Team Server will address the problem adequately, ESPECIALLY if that package requires a 'big footprint' server installation as a result.

I'll definately look for you at the next meeting, maybe have more time to hang around then.

Bob Robinson |