How do you like your noodle baked? medium or well done?

The second reason to avoid this is simply because it bakes the noodle of anyone who reads the code. - Eric Lippert

So when I see the following... I want to scream, yell, and run away.

Csla.BusinessListBase:

public abstract class BusinessListBase<T, C> : ExtendedBindingList<C>, IEditableCollection, IBusinessObject, ISupportUndo, IUndoableObject, ICloneable, ISavable, IParent
        where T : Csla.BusinessListBase<T, C>
        where C : Csla.Core.IEditableBusinessObject
    {
     // ... other code
    }

CompanyName.Library.Base:

public abstract class CompanyBusinessBaseCollection<T, TCollection> : BusinessListBase<T, TCollection>
        where T : Csla.BusinessListBase<T, TCollection>
        where TCollection : Csla.Core.IEditableBusinessObject
    {
     // ... other code
    }

Take note... that that's 2 levels of abstract class so far.. climbing the chain we have: Csla.Core.ExtendedBindingList<T> (where T now means C), System.ComponentModel<T>. I only stopped once I hit the framework inheritance chain start.

I just had to get that out...

Now to find references to cite on my rant:

• since inheritance is a very intimate (and encapsulation breaking) relationship, it's easy for subclasses to effectively break their superclasses by, for instance, omitting necessary behavior when they the methods are called - Martin Fowler - Designed Inheritance
• In fact, the Object-Oriented Design Patterns book from "the gang of four" has this to say about inheritance: Prefer object composition to class inheritance
• Inheritance is pretty enticing especially coming from procedural-land and it often looks deceptively elegant. I mean all I need to do is add this one bit of functionality to another other class, right? Well, one of the problems is that inheritance is probably the worst form of coupling you can have. Your base class breaks encapsulation by exposing implementation details to subclasses in the form of protected members. This makes your system rigid and fragile. The more tragic flaw however is the new subclass brings with it all the baggage and opinion of the inheritance chain. Why does a model that enforces validation attributes care how the model is constructed? The answer is it shouldn’t, and to add insult to injury, the better design is actually easier to implement. Listen closely and you may hear the wise whispers of our forefathers… - Inheritance is Evil: The Epic Fail of the DataAnnotationsModelBinder
• Prefer object composition to class inheritance - JsPatterns.com - A case against inheritance
• Joshua Bloch hits it on the nail in his Effective Java book item about “Favoring composition over inheritance.” - The Shyam - Is Inheritance Overrated? Needed even?

Using a local source repo to work on vs2008 projects in vs2012

If the project type can't be opened or worked in the newer Visual Studio then you are still out of luck, but otherwise here we go. Assuming you have Git installed, go to the top level of a directory that would include both your .sln and .proj files.

$ git init

inside that directory then if you don't have a default set of ignores. you will want to set that up. Before opening Visual Studio, do your initial commit.

$ git checkout -b Vs2012

to create the new branch. Open in Visual Studio 2012. Commit the changes. Now you can make all your edits and commit them. When you want to pull the changes to the old VS branch change to that branch and do a git-cherry-pick

$ git cherry-pick SHA

replace SHA with the SHA hash of the commit you want to pick. Or to do them in bulk...

$ git cherry-pick SHA1..SHA2

replace SHA1 with the SHA hash of the commit you want to skip, and SHA2 with the last one you want.