IBM Rational ClearCase is a Software Configuration Management system, i.e. it contains a version control system (like SourceSafe, Subversion/CVS, Perforce, Continuus).
Unique to ClearCase is the concept of the so-called "dynamic view", that is a virtual file system mounted as a network volume containing an individual selection of source element versions.
The underlying technology is similar to NFS and allows configuring and mounting from both Windows and Unix systems.
Similar to Unix, for each element, three groups of access rights can be configured (owner, group, other) and the rights comprise read, write and execute permissions.
Read and write permissions are obvious, but execute is not.
Usually, this permission is used to prevent accidental loading and execution of untrusted, unsuitable or unexecutable code, e.g. shell-script snippets, binaries for another platform, et al. In turn, it must be set for files that should be loaded and executed by the operating system.
The system will not load an executable or load a library into a process without the execute permission, but abort and throw an "Access denied" error instead.
Ignorant of the technological wonders that ClearCase uses to communicate the execute permission to the Windows loader, I dare say it usually suffices to assign execute just to executables and, only under uncertain circumstances, to the libraries.
However, for some distorted reason, on a ClearCase dynamic view, to invoke a .NET executable that is accompanied by a (checked in) config file, this config file needs execute permission, too.
I know it’s questionable why the "configuration" file is checked in, but let’s not get into this zealous discussion now.
What I’m thinking about this is, that the config file needs to be accessed (by the loader) before the actual executable is loaded, so the executing runtime can be willfully chosen. This happens in the execution context of the loader and, thus, is somehow considered to be "execution".
The question remains why the behavior is limited to executables and config files checked in into a ClearCase dynamic view and can not be reproduced using view-private files or files on Window file shares.
Totally unrelated to file-level execute permissions, but one more note for completeness:
Due to .NET code access security, for each framework version a machine-level code group must be configured that grants appropriate permissions for .NET code to be startable from the ClearCase virtual network drive; otherwise, a SecurityException is likely to occur and invoke Dr. Watson or your debugger; unless you have planted your deep understanding of partial trust carefully into all the assemblies involved.