MichaelD!'s Tech Blog

Code. Life. Art.

Visual Studio Connected Projects (CodePlex Projects)

For some time now I’ve been thinking about this concept for Visual Studio that I feel would help out development workflow tremendously.  I will preface this entry by saying that it’s very unlike me to suggest an idea without actually implementing it myself.  I am currently maxed out with my personal project and adding “one more thing” to it would exceed my level of personal time for commitments (yes, that’s me learning how to say “no!”).

I’m hoping that with this post, an influential mind over at Microsoft (ScottGu, perhaps??? J) will see this and create an “actionable item,” (my new favorite phrase) or perhaps spawn a new CodePlex workspace.

The Problem

Consider creating a codebase that consists of common utilities and helper methods.  Over time, this codebase grows as you add new classes and functionality to this base, ultimately ending in a variety of projects that tackle different problems (Web, UI, etc.).  Now consider porting this codebase over to a new solution entirely, and this solution lies on a new Team Foundation Server.

You have to copy the entire codebase.  There’s no way to have one TFS server “point” to another codebase on another server.

You now have two different sources to maintain and manage, one for each TFS server.  Bummer.  You could of course maintain one codebase on one server, compile it whenever there's a change, and then copy the dll over to the other server (along with the subsequent checkins and outs), but that workflow is a bit cumbersome and tedious, at best.  There is still a considerable disconnect between the two solutions.

Now consider the current process for incorporating a 3rd-party assembly such as the Ajax Control Toolkit or Enterprise Library into your project:

1)      Find out about the assembly (somehow).

2)      Download the assembly (or package that places a versioned assembly onto your machine).

3)      Add assembly into project.

4)      Develop based on assembly in project.

Pretty straight forward, right?  Well it is, in fact.  That is, until another version of the assembly is published and made available for consumption.  Then things get a little trickier, especially if the assembly is installed by an install package.  If you have a team of developers each developer must download the new package, and install the old one.

The Ajax Extensions framework is a perfect example of this.  I’ve witnessed four or five instances where developers were in .dll hell (yes, in a .NET project!) trying to figure out why their project failed due to an incorrect assembly version within their project.  Granted, this was during the CTP and beta bits of this project, so shame on us for developing on pre-release bits, but it really made me think a little bit about the nature of assemblies and how they are used in development.

The other problem with this paradigm is that when a 3rd-party assembly is used within a project, it is a static versioned copy that is shared across many machines.  That is, it’s not “live” or there’s no easy way of knowing when a new version of that assembly is available, and when there is a new version, there’s no easy way of incorporating that assembly into the project.

The Solution: Connected Projects

So what I’ve been thinking for some time is an add-on project type for Visual Studio that I like to call a Connected Project.  A Connected Project works much like a regular project.  It is a project you can include in your solution and reference from other projects in your solution.  The major difference is that it doesn’t include source code (although access to code would be in the same way that the Core .NET libraries are now accessed), and it pulls its compiled assemblies from CodePlex.

So let’s say I install my Connected Project package and everything is set and ready to go.

In the world of Connected Projects, I would right-click my solution and Add Connected Project.  I then get an Open Dialog box that peers into the world of CodePlex (much like the web reference dialog box).  I can then search for my project or browse for projects.  Once I have found my project I can add it to my solution.

Once it’s added to my solution, it functions just like a regular project in Visual Studio.  I can check it into source control.  It has references to all the assemblies it needs to operate correctly.  The key here is that this project sits on CodePlex and is downloaded on my machine on the first compile (or whenever I rebuild).  Of course we can cache the assembly output so that the different versions are available locally so that CodePlex isn’t being hammered more than it already is. J

This Connected Project then becomes a live, dynamic project in my solution, in the sense that whenever a new version of this project is available (beta or otherwise), I can then go into the Properties of this project and update the version that my solution is using.  I can also set up my debug configuration to always use latest (Automatic) and my release configuration to always use a specific version, for production purposes.

Breaking changes in the latest nightly build version of the Connected Project?  No problem.  Just revert to the previous version of the project (this is controlled by a new tab/control in the Remote Project’s Property Pages).  No need to muck with code or bug regression.

This solves the problem of having to subscribing to an RSS feed or blogs to know when a new version of a project is available.  I can have the latest build (public, beta, or otherwise) directly in my solution without even having to open a web browser to download it first.

I also don’t have to worry about copying code over to different servers, or maintaining more than one codebase.  Every solution points to the same project, and is connected to its updates and check-ins.

While we’re at it, we can use Connected Projects as a hub to bolt CodePlex functionality right into Visual Studio (I’m a big fan of CodePlex’s vision!).  So you can get the latest news and updates for the CodePlex project straight from the Connected Project.  Maybe just for the sake of branding and identity we can just stop the foreplay and call these projects CodePlex Projects. J

I hope I’ve explained the problem and have done a decent job proposing a solution for this.  I’d really like to get some discussion on this.  Perhaps this already exists in some form and I’m completely ignorant on its existence (this does happen from time to time!) 

If this makes sense to you, please vote for this on CodePlex!

 

Comments

- jbuch said:

What you're describing adds at least an application dependency and a storage convention to a technology agnostic project framework.

it's a fine idea for an open source project, but not for the core site.

the issue tracker on codeplex is for posting features and issues applicable to the core site, not ideas for open source projects -- however, there are numerous communities dedicated to oss discussion, including hot project ideas.

Good luck with your project, it sounds pretty fun!

# February 11, 2008 3:48 PM

bucho said:

yes i read it. punk. :) Good idea.

# February 13, 2008 1:22 PM

Team System News said:

Martin Kulov on Get latest does not work in TFS. The Teams WIT Tools Blog on Value Propositions, Experiences,...

# February 14, 2008 11:06 AM

aidan said:

== able to be action-ed?

# February 14, 2008 12:06 PM

Mo said:

In the Java World what you asking for is called Mavin:

http://maven.apache.org/

# February 25, 2009 2:10 PM
Leave a Comment

(required) 

(required) 

(optional)

(required)