Best practice for getting app name/id

Question

What's the best way for a common library to know what context - a.k.a. the calling app - it is in? I'm in a very controlled enterprise environment... is there a better way for the library to know what application it is getting called from than reading a setting in the config file? What do you use for this type of thing?

//the rest of the story
I work on the Intranet team for a Fortune 500 manufacturing company. I have created a common library that all of our new .Net applications will make use of. It queries a common database for information about the application and a bunch of other things that are irrelevant to the question. As you can imagine, the common library needs to know what application is calling it. I could just force every application to set a property on some static class or something, but instead I wanted to make it a little more behind the scenes. Currently it requires the developer to put a setting in the app.config or web.config with a key of ApplicationName and a value of - you guessed it - the application name (which is a unique non changing id for us). It then uses Currently it uses ConfigurationManager.AppSettings["ApplicationName"] to pull this in.

Answer 1

There may be a way to do it. I will most likely get down votes for this since I don't plan to answer your actual question at all, but I just couldn't move on without saying something. To me this is an example of the worst sort of coupling possible. Your actually has to look at a DB and behave differently depending on the application that is calling it?

Answer 2

getenv() will get you environment variables, which in turn should should give you what you want. But generally, having different behavior depending on the name of the calling program is not considered a best practice. An exception would be if you wanted to print out the calling program's name in a log message. There are of course other exceptions, and your situation may be one of them.

You can also probably get the information via the process id (w/ getpid()).

Answer 3

I'm agreeing with EBGreen here. This is a red flag question to me.

That said, I suggest to do exactly the opposite of what you're suggesting, and simply pass the key (application name or whatever) as a parameter to the function you're calling. You could bake it into the program as public static property on whatever you're entry point is, and make a little helper function that basically overloads the call to the repository. That would hide it and reduce error prone repetition..

Better yet, you could also make your entry point classes implement an interface that has a method to get the application name (it just returns a string constant) and methods for setting the values returned from the database.. Call it "IIntranetApp" or something. Then you just pass "this" to a function expecting "IIntranetApp", and it magically fills in the blanks needed from your central repo.

Something like:

public interface IIntranetApp
{
    string GetApplicationName();
    void SetConnectionString(string connectionString);
    // etc... add methods as necessary
}

Answer 4

You could also just call Assembly.GetEntryAssembly within the common library class.

Then use the .Name property from the returned assembly.

That means those, that your appsettings table (or whatever it is) needs to be keyed by the assembly name, and that if assembly name should change it'd all break. It means you're slightly less flexible on your naming/key choices here.