views:

997

answers:

9

As the Title says, I've got a multi-project solution.

I've got a "core" project that is loaded with most of the other projects.

So my question is this, I have a few utility functions such as FormatPhoneNumber(..) that I would like to be able to access in the following manner from anywhere.

(in Project_B which depends on Core) string str = FormatPhoneNumber(inputString);

At worst, I suppose I could live with a qualifier of some sort: string str = util.FormatPhoneNumber(inputString);

I come from a non-ASP.NET VB-single-project world, so I apologize for the lame question :)

+4  A: 

The best way of doing this is to create a dll project (maybe called something like "CommonCode"?), that you can then reference this dll from all of your other projects and access the classes and methods therein.

You will have to have some sort of "qualifier" (as you call it) somewhere, but to reduce the impact use the using statement at the top of each file, e.g.

using util;
Calanus
I would rather say "Don't use using" as a general guideline. Especially if you import a set of unrelated utility classes this way. You have Intellisense for long names. Other than that, your answer is fine.
OregonGhost
I usually favour leaving true utils outside of a namespace entirely - extensions to .NET classes usually counts here too
annakata
A: 

If you are using C# 3.0, you can bind them all into one single static class use them as Extension Methods.

this. __curious_geek
But note the guidelines on when you should use extension methods: only if it belongs as a member of the target class (if you were writing the target type yourself).
Richard
You still have to put them in a class somewhere and share it between projects. Extension methods wouldn't work unless you're using their namespace and of course a reference. Also, by limiting yourself to extension methods you don't have your own design. People do need classes.
Kobi
I think a string extension method to format the string would be fine. There is no point in having a separate class for a function that is exclusively used with another class, especially if both the only parameter and the return value are of that other type.
OregonGhost
A: 

There are no global functions in .NET, so you will have to put your utility functions into a class. You can make the methods static, so you can call them without having to instantiate the utility class:

public class Utility
{
  public static string FormatPhoneNumber(string input)
  {
    ...
  }
}

// usage:
string output = Utility.FormatPhoneNumber(input);

Put these methods into your core library or a separate utility library that can be used (referenced) by all other libraries and applications.

M4N
A: 

You need to put the functions in static classes. You cannot avoid the qualification (there are no global functions in C#):

<%= Formatters.PhoneNumber(rawData) %>

The utility functions should be grouped as per normal methods: similar methods go together, unrelated methods should go into different classes (event with static classes aim for low coupling and high cohesion).

The assembly each belongs in should be obvious: formatting functions only used by the presentation layer (ASP.NET project itself) belong there. Truly common functions could go into core.

Richard
+1  A: 

If you really must have such utility functions (you know, you shouldn't, but sometimes it's the best/easiest solution), I suggest having them either in the Core (assuming that every single project is dependent on the Core anyway), or in a separate utility assembly. If you don't want to have a separate assembly lying around, consider using ILMerge.

The qualifier should be no problem at all. I suggest not putting unrelated function into an Utils class, but rather use e.g. a Formatting class for all formatting functions. On the other hand, as s_ruchit in the meantime suggested, extension methods (e.g. for the string class) might come in handy as well.

(Did I mention that this §%$& MarkDown editor does not allow typing an [at] symbol on a German keyboard layout, because it instead creates a blockquote? Sigh.)

OregonGhost
+1  A: 

Try creating your own util library.
Create a Class Library project and put your util classes in there.

I myself try to adhere a naming convention like [companyName].Util.[subdomain] Your example would probably fit in my [CompanyName].Utils.StringHelpers

You would then create a static class StringHelper with a static method FormatPhoneNumber. You will see that these personal libraries quickly grow bigger. By grouping them you don't have to load all your code if you only need a subset of functions.

borisCallens
A: 

If the function you are implementing can only be used in context of your application, i would recommend you to place it into the Core assembly (under a separate namespace like "Utils" for example) or a new DLL library of your application solution. Only if the function can be used across multiple projects it makes sense to create a utility library. But always keep in mind that a utility library only make sense if it's maintained regularly.

Alexander
A: 

If you want all code to access these methods then go with extension methods, otherwise I would go with Util class in core assembly.

FWIW, if you follow a more formalised namespace as boris sugguests (recommended to avoid conflicts) you can abbreviate with the using keyword:

using Util = [CompanyName].Utils.StringHelpers;

I tend to follow the DRY principle and create an alias as soon as I need it more than once.

Si
+1  A: 

Use an extension method to make it easier to call the method without using the class name.

public static class Util {
    public static string FormatPhoneNumber(this string input) {
     :
    }
}

The method will now appear on every string object. You do not need to know which class it comes from. However, if the extension class is declared in another namespace, you must still import the namespace.

string formattedString =  inputString.FormatPhoneNumber();
anonymous