C# code re-use via namespaces

Question

Hey guys,

I like to create a file full of custom functions which I have made, which I may use in another project or something. Now I don't fully understand how to go about this, normally in a language like php, you'd just create the php file and then go include("cust_lib.php") or whatever the file is called.

Now I think that the process involves the library having its own namespace, then either go using custom_lib; or custom_lib:: within the script (I don't want to get into a discussion over which is the best way to go here).

Is this right? Or should I create the library and convert it to a .dll, if so how do I go about this, what sort of syntax does a dll have inside it etc.

However if its just file within one project then I don't need to go down that route do I? I can just create the namespace and use that?

This is what I'm working for at the moment, and thought it would be something like this

namespace Custom_Lib{
  ~~functions to go here~~
}

However the functions have to exist within a class don't they? So that becomes something like

namespace Custom_Lib{
  class custom_lib{

    public string function1(string input){
      return input;
    }

  }
}

So some help, pointers, examples would be appreciated so I can wrap my head around this

Thanks, Psy.

(Yes I call them functions, that just comes from a long php/js etc background)

Answer 1

The normal approach would be to create a Class Library project, put your classes and methods in that project, making sure that those you want to expose are public. Then you add a reference to the resulting dll file in the client projects and you will have the functionality from the class library available to you.

Even if you decide to put it all into one single file, I would still recommend you to make it a class library since I imagine that will make it easier to maintain. For instance, consider the following scenarios:

• You decide to put it in a file and include a copy of that file in all projects where you want to use it. Later you find a bug in the code. Now you will have a number of copies of the file in which to correct the bug.
• You decide to put it in a file and include that same file in all projects. Now, if you want to change some behaviour in it, you will alter the behavior for all projects using it.

In those two cases, keeping it as a separate project will facilitate things for you:

• You will have only one copy of the code to maintain
• You can decide whether or not to update the dll used by a certain project when you make updates to the class library.

Regarding the syntax issues: yes all methods must exist within a class. However, if the class is merely a container of the methods, you can make it (and the methods static):

public static class CustomLib
{
    public static string GetSomethingInteresting(int input)
    {
         // your code here...
    }
}

That way you will not need to create an instance of CustomLib, but can just call the method:

string meaningOfLife = CustomLib.GetSomethingInteresting(42);

Answer 2

There no question here. You answered it yourself. Yes, you have to construct a class to include all helper methods. And yes, you can either compile it to a dll if you want to reuse in multiple projects it or just add the source file to the project.

Usually I declare the helper class and all functions as static to avoid initiating the class each time I use it.

Answer 3

In addition to Fredrik Mörk's well-written and spot-on response, I'd add this:

• Avoid creating a single class that is a kitchen-sink collection of functions/methods.

Instead, group related methods into smaller classes so that it's easier for you and consumers of your library to find the functionality they want. Also, if your library makes use of class-level variables, you can limit their scope.

Further, if you decide later on to add threading capabilities to your library, or if your library is used in a multi-threaded application, static methods will likely become a nightmare for you. This is a serious concern, and shouldn't be overlooked.