Could also put he methods from A in a seperate container, and then allow A and B to pick and choose what services they need from the 'method' server.

>It depends whether you want B to be a subclass of A, inheriting its methods and then varying them. This would be the best way if B was a genuine variation of A and any later changes in A should also occur in B.
>
>In this case you can produce variations in behaviour from A to B by coding in B the things that are different, using Dodefault() to run the underlying code from A for the method you are in. However this usually means that you have to breakdown the methods in A into small sections so that it is easy to replace just the code you want.
>
>If, on the other hand, A just happens to have a lot of methods that you would like to use in B but you do not want a permanent connection between them you can copy A in a project using drag and drop to another class library and rename it as B there. This is not a solution that would impress OO purists but it works.
>
>Best regards
>Andrew