The CurrentWorkingDirectory is...a tar pit for people looking to emulate VB6's AppDir (or whatever it was called).
It's true that Process sets it to the app's startup dir when starting an application...but its absolutely the last thing to rely on as a quick AppDir property.

Why? Because other things change it -- such as FileDialog:

<<<
Anyhow, to cut a long story short, the FileDialog changes the current working directory to the last selected directory (unless a property is set: RestoreDirectory). This causes the assembly loader to look in the incorrect directory.
>>>

His solution was to instead rely on AppDomain.CurrentDomain.SetupInformation.ApplicationBase which solves some of the problems

Note that it works for PC, ASP.NET, but not CF, as demonstrated here: http://demos.xact-solutions.com/Investigations/ASP.NET/AppDir/Default.aspx

Getting a cross platform solution to entry assembly and startup path is more complicated really...requires precompiler directives, P/Invoke on CF, etc.

Link:

• AppDomain ExecuteAssembly problem

I'm used to this approach:

System.Environment.Version

which gives

2.0.50727.3053

but I've just bumped into this (again...but I had totally forgotten about it):

string s = 
System.Runtime.InteropServices.RuntimeEnvironment.GetSystemVersion();

which gives:

"v2.0.50727"

Still like the the Environment property better, but the RuntimeEnvironment has some other juicy properties and methods that that may come in handy some day. For example:

System.Runtime.InteropServices.RuntimeEnvironment.SystemConfigurationFile;

c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\config\machine.config

System.Runtime.InteropServices.RuntimeEnvironment.GetRuntimeDirectory();

gave me:

c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\

Can't see how this could be useful to me any time soon...but park just in case.

Links:

• RuntimeEnvironment Class (System.Runtime.InteropServices)

A complete list of Environment Variables (eg: %ALLUSERSPROFILE%, etc) that are sometimes needed...