What's the difference between Application and AppDomain.CurrentDomain

Question

I am little confused about usage of Application class and AppDomain class.
For example Application.StartupPath is equal to AppDomain.CurrentDomain.BaseDirectory

I usually used Application class and recently discovered AppDomain - Can someone explain to me AppDomain class and its usage?

Accelerate

An Application class is highly specific to a GUI app. A console mode app or service doesn't have one. But every .NET app has an AppDomain. The WPF Application class is very different from the Winforms Application class. Sure, there's a bit of duplication, not excessively so. – Procryptic

Can you provide more information about exactly what classes you are referring to, with namespaces? It would make the question more clear. – Elamite

Answer 1

They have nothing in common, really.

Application is a class specific to Windows Forms, a .NET GUI technology. The Application.StartupPath is handled by the Kernel32 function GetModuleFileName. Through not passing a pointer to a module, the main module's path is returned - that is the exe file, basically.

AppDomain is a core .NET concept for domain isolation. Basically, it allows you to isolate (imperfectly of course) multiple applications in a single native process. Most applications only have a single AppDomain, but you can create as many as you like. The base path of an application domain is handled by Fusion, a .NET assembly loading technology. A very typical example would be ASP.NET applications hosted in IIS - each application has its own AppDomain, but they're all hosted in a single native process ("application pool"). Each logical application can be restarted without touching the others, and they don't have (simple) access to each other, but a process-tearing exception (e.g. StackOverflowException) will still kill the whole pool.

Another interesting class that's somewhat related is Environment. You can use Environment.CommandLine to get the process command line (which includes the path to the executable, including the name of the executable). This is basically a communication interface between the CLR and the underlying system - in this case, it takes care of saving the arguments for the application (which are passed by the OS to the Main function) and making them available at any time in the future.

Environment.CommandLine is somewhat clunky to parse (it's the raw command-line, basically - I assume it will have different conventions on Windows than on Linux, for example), but it's the only way you can always get to the executable. Again, Application.StartupPath is Winforms specific, and you can have more than one AppDomain - and possibly, the AppDomain might not even have a reasonable BaseDirectory.

The .NET Reflection APIs also give you a few ways. For example, Assembly.GetEntryAssembly() will give you the executable assembly - however, this only works for the main AppDomain - other domains will have their own entry assemblies (in fact, they'll usually just return null :)). You can get the path to an assembly through the Assembly.CodeBase property, but do note that this might not always be what you expect. You can also use Assembly.Location, or get the FullyQualifiedName of any of the assembly's modules (again, most assemblies only have a single module; and again, ASP.NET is one of the prime examples of when this isn't the case).

Laparotomy

Oh, I forgot about System.Diagnostics.Process. damn, there are so many ways – Width

@Width As far as I can tell, it uses the same logic as Application.StartupPath - except that it always iterates over all the modules rather than picking the main module from the get go. But yeah, it's yet another way. I wonder how many we've still missed... I mean, this wasn't meant to be an exhaustive list, but it's funny how many ways to break the egg there are, each with their own subtle differences. I hope noöne asks which is the best (at least it's off topic on SO, whew). – Laparotomy