All my projects share the same base library that I have build up over quite some time. It contains utilities and static helper classes to assist them where .NET doesn't exactly offer what I want. Originally all the helpers were written mainly to serve an internal purpose and it has to stay that way, but sometimes they prove very useful to other assemblies. Now making them public in a reliable way is more complicated than most would think, for example all methods that assume nullable types must now contain argument checking while not charging internal utilities with the price of doing so. The price might be negligible, but it is far from right.

While refactoring, I have revised this case multiple times and I've come up with the following solutions so far:

1. Have an internal and public class for each helper
   The internal class contains the actual code while the public class serves as an access point which does argument checking.
   Cons:
   • The internal class requires a prefix to avoid ambiguity (the best presentation should be reserved for public types)
   • It isn't possible to discriminate methods that don't need argument checking
      
2. Have one class that contains both internal and public members (as conventionally implemented in .NET framework).
   At first, this might sound like the best possible solution, but it has the same first unpleasant con as solution 1.
   Cons:
   • Internal methods require a prefix to avoid ambiguity
      
3. Have an internal class which is implemented by the public class that overrides any members that require argument checking.
   Cons:
   • Is non-static, atleast one instantiation is required. This doesn't really fit into the helper class idea, since it generally consists of independent fragments of code, it should not require instantiation.
   • Non-static methods are also slower by a negligible degree, which doesn't really justify this option either.

There is one general and unavoidable consequence, alot of maintenance is necessary because every internal member will require a public counterpart.

A note on solution 1: The first consequence can be avoided by putting both classes in different namespaces, for example you can have the real helper in the root namespace and the public helper in a namespace called "Helpers".