Fog Creek Software
Discussion Board

Welcome! and rules

Joel on Software

Different component version – Same app

I’m new to .Net so I’m kind of stuck.  What I’m trying to do is this:  I want to create two (none visual) versions of the same component and switch between them at runtime. So, if one component performs a given action and returns result X when result Y was expected, the client can then ask the other version of the component to perform the same action.  Am I making sense?

I believe these two versions can be placed into separate assemblies.  But can I  reference these assemblies directly?

I know it sound like a strange question but I’m trying to implement functionality that allows me to plug in a new component version, run it along side the old version.  The objective is to be able use the new version unless the result given by the old version differs.  If this happens the client switches to the old version.

If assembly1..Component1.MyMethod() = X then
End If

I would really appreciate any help with this.

shaun bethell
Wednesday, April 14, 2004

If I understand you correctly...

You need to consider using a base class (or an interface). There's no need to use different assemblies, just use Component1 and Component2 (or whatever) in the same assembly.

Create an abstract base class which defines the method, then inherit this base class when you define Component1 and Component2.

You'll need to implement MyMethod in both of your derived classes.

Then, you can do (in pseudocode):

if component1.MyMethod() = X then
end if

Sorry this is in the language of C# (I've been using it so long I've forgotten how to say it in VB terms, but hopefully this makes some sense).

Steve Jones (UK)
Thursday, April 15, 2004

Hi Steve, thanks for replying.

The component-based application that I am trying to create is part of my dissertation.  The subject is about improving the confidence in the upgrading of third party components. 

The scenario is: I am a component vendor who is attempting to produce components that can be sold to customers that they can test in there live systems without compromising the system.

That’s why I have to be able to plug in the new component and run it along side the old one.  If the new one fails then the system switches back to the old one.  I had it stuck into my head that the new and old components will have the same name but different versions (which is true) but of course…. I can temporarily rename the new component while they are executing along side each other.  As you said I can use an interface class to access both.

In the client (possibly another component), I can use a flag to indicate the existence of the upgrade.  So:

bool upgrade_present;

If upgrade_present then
If  RenamedComponent.MyMethod() = X then
end if
    Original_Compnent.MyMethod();  //no upgrade component present
End If

This way I could change the name of the upgrade component to the predefined name in the code and simply change the flag to true.

I know it’s ugly but it should work don’t you think?  I suppose I could inheritance and override the default code if the upgrade is present but I have to implement the option of monitoring and recording the results and component interactions of both the original and upgrade components at runtime.

For This I’ll probably use some sort of control component to divert data to a monitoring utility.

Thanks for your help and sorry if this all sound like inane babbling.  Sleep deprivation I think :-)


shaun bethell
Thursday, April 15, 2004

Just me (Sir to you)
Thursday, April 15, 2004

google for smart base factory pattern

The basic idea is that with the right code, you can select, load, and use DLL at runtime instead of needing explicit references at compile time.

Based on the author's justification (select calculation type at runtime), it sounds tailor-made for what you describe.

Ron Porter
Thursday, April 15, 2004

Thanks for the help guys it was really appreciated.

I followed the URL and read the article.  They were using  polymorphism which would be the ideal answer. But were one component accesses the old and new components, I would have to implement the super-class in the calling component and the sub-classes in the old and new ones.  This would lead to "cross-boundary inheritance".  Sadly, I've been told to avoid this by my project supervisors.

But, fortunately, the idea is sound and can be easily adapted to a none inheritance solution.  So I'm definitely going to use some of that stuff.

Thanks again for replying and for the help.  You have saved me days of work and a few grey hairs. 

shaun bethell
Saturday, April 17, 2004

*  Recent Topics

*  Fog Creek Home