[code lang=text]
Title: "Branching" on 2008-06-17 12:11:56
Categories: "General"
– "Source Control"
Originally posted at

I’ve developed in 3 main situations, University, Personally and Professionally, which I believe is probably similar for most developers. I’ll freely admit that for my personal projects I’ve rarely (if ever) utilised source control solutions, even though I know that there are plenty of free solutions available. It’s just never been an issue (though I am going to rethink that).

University taught me squat all about how to use source control, I think I gained an inkling of what it was somewhere towards the end of my time there, when another project team lead mentioned to me that they were using it. I really came into the source control circle in my first professional role.

I never really realised how important source control was until then, and now I recognise proper usage of source control as a core part of the development process. I’d almost go as far as to say, the core part of the process. A crap coder can write crap code, delete good code, whatever they like, and as long as it’s source controlled – we can see what was changed, when, and importantly rollback if required.

Most devs I’ve worked with have really only ever used source control to do the usual checkin/checkout gubbins, which for 90% of the time is great. Most have heard of branching, but never actually used it, some people don’t even want to use it. It’s a big scary concept that people fear. Personally I think a lot of the fear is due to the complexity of the tools used to do the job. Well. One tool in particular. Visual SourceSafe 6 & 2005.
Branching shouldn’t be (too) scary!

Why should branching be used?

Imagine we’ve developed our program, EmailXtreme (a spiffy email app if you must know), and we’ve reached version 1, our first release! Now, to get to the first release, we’ve taken some short cuts, and some features we wanted have been cut to make the release date. But we’re in the moment, who cares?
Time passes, and development of the extra features begins.

More time…

OH NOES! Bug!!! One of our customers has discovered a bug in the app – and wouldn’t you know it – it’s a critical bug, EmailXtreme doesn’t actually Email (thanks testers!).

All developers get working on the fix, fortunately it’s a one liner, fixed, tested – out it goes to the customers (with apologies).

5 minutes after…

During congratulations, pizza and beer, a lone voice can be heard:

“guys, errr, what about that new feature we were working on, it’s not finished, and [cough] will break, well, everything.”

Silence. A beer can drops on the floor. Someone cries.

Quick rewind

  • Release v.1 done, all good (yay).
  • Dev team branch into a version 1 branch, then get developing on the trunk.
  • Bug comes in.
  • Bug is fixed in maintenance branch, released to the customer and finally the fix is merged into the development trunk.
  • Customer and devs happy, this time they get their pizza and beer. Good job!

This is a bit of an oversimplification of how branching can work, but it’s also a good example of why branching is useful.


That’s really all down to the tool you’re using. I have used sourcesafe to do this, and it pained me, and the guys I was working with. I can only really comment on one other tool – Vault, and that makes branching a doddle.

It’s worth checking your current Source Code Control (SCC) to see what you can do.

Managed Application Framework – Part 2 – Basic Versioning!

Soooo… A post from a while ago covered the basic Managed Addin Framework (MAF from here-in) and how to set up a basic addin with host and pipeline.

One of the big problems of an Addin situation is if we change the contract between our Addins and our host. This can happen for a number of reasons – added functionality, removed functionality, the dreaded security etc… So, we change our contract and OH NOES! break all the AddIns we’ve carefully nurtured to maturity.

Luckily the guys who developed the MAF have come up with a solution to this, and it all lies with the pipeline………

Previously we had the IHelloMAF contract:

public interface IHelloMAF : IContract
string HelloMAF();

Obviously this gives us a limited set of functionality, so lets add a little bit more:

public interface IHelloMAF : IContract
string Hello(string name);

This will give us the power to accept inputs! Of course, this is just the contract, the detail is in the actual implementation itself.

If I simply update the contract and rebuild the pipeline, then my previously created AddIn will stuff up as it implements the old contract, I would have to change the AddIn to implement the new version, but I don’t or maybe can’t do that.

What does that mean for the development? Basically, we need to create another adapter, one to convert version 1 addins to work as a version 2 addin. To do this, we use the Pipeline builder, it saves a lot of time and effort in the long run. We need to be able to tell the Pipeline builder that, actually, generate a new AddInView, not overwrite the existing one. To do this, we reference in the PipelineHints dll (this is in the location you installed the PipeLine builder – in my case: C:\Program Files\Microsoft\Visual Studio Pipeline Builder\PipelineHints.dll).

Once we have the hints dll referenced we can go to our Contract file and put the following in:

[assembly: PipelineHints.SegmentAssemblyName(PipelineHints.PipelineSegment.AddInView, “AddInView2”)]

** Put this ABOVE the namespace declaration (if you have one)!! **

What this effectively does is force the Pipeline builder to create the AddInView segment for this contract, but name it ‘AddInView2’ rather than it’s default ‘AddInView’.

If we now run the Pipeline builder, we will generate some new projects, including ‘AddInView2’, note – the ‘AddInView’ project is still there, aces!

After this we need to update the host to cope with the new contract (** IF we changed the contract name, if we didn’t then no updates required **), should be pretty simple.

We can then create a new AddIn, based off of the new contract, and once we’ve done that, run the host and load up our new AddIn. All should be working!

But the version 1 addin isn’t showing – this is expected at the moment. The pipeline builder has only created a pipeline for the new style of Addin. What we need to develop is a v1 addin to v2 addin adapter. The easiest thing to do is copy from the AddInSideAdapters project.

We create a new Class Library project, calling it something like AddInV1ToV2Adapter, which gives us a good start point.
Add in references to:
AddInView (the version 1 addin!)
(Again, Copy to local = FALSE!!)

Then opening the AddInSideAdapters project, copy the IXXXViewToContractAddIn.cs contents and paste them into your ‘Class1.cs’ file. Now we just need to edit the code to do our translation, so.. first things first, rename the class, doesn’t really matter what it’s called!

You should find the only thing you really need to change is the implementation of the methods, so in our example, we’d have:

public virtual string Hello(string msg)
return _view.HelloWorld();

Rebuild the entire solution and run the host… Now our host detects 2 AddIns, which is perfect!

I would attach the code to this post, but my blog host doesn’t allow attachments at the moment, I am in the process of looking into this!
If you want it, please email me: cs7kardon [-=At=-] xc7lave . c7o . uk (remove the ‘7’s and compress!)