Best approach to build C# DLLs for different editions of a software? -

i have build 3 different editions of dll contain api calls of our software. have far figured out following way of doing using inheritance. can please confirm if i'm using inheritance correct way (or if have suggestion doing proper/better way?) new still learning c# project programming.

so far have main class of api_calls (which common dll editions) follows:

namespace apicalls {   public partial class api_calls   {     public void common_function1()     {     }      public void common_function2()     {     }   } } 

then have 3 .cs class files following in each of them (edition_a, edition_b, , edition_c differing factors each edition of dll), additional calls included in partial class api_calls follows:

namespace dll_edition {  public class edition_a  {     public edition_a()     {       // code here checking if current dll authorized       // otherwise throw exception     }  } }  namespace apicalls {   public partial class api_calls : edition_a   {     public void additional_edition_a_function1()     {     }      public void additional_edition_a_function2()     {     }   } } 

in each assembly build include edition_a file, or edition_b file, or edition_c file , build 3 assemblies gives me 3 dlls.

my question: proper way of doing it? there negative how have done it? or there better way of doing this? ultimate goal have 3 editions of dll common api calls in them , various api calls specific each dll type.

thank input may have!

-dd

from understand, have set of common functions in common base class used different other classes.

there various ways of doing own pros , cons:-

1) creating seperate libraries each type doing, in limited functionality goes end user , size of dll small.this better suited if have dlls working on plus , play model dump dll in bin amd new functiinality in place.

this makes changes centric, know changes are. if have distributed dll end clients , need method in other dll, again have republish changes.

2) doing in 1 dll, unwanted functionality exposed client, deployment package heavy. have functionality readily available.

to summarize depend on business , deployment model.