Application Configuration Files
An application configuration file is an XML file used to control assembly binding. It can redirect an application from using one version of a side-by-side assembly to another version of the same assembly. This is called per-application configuration. An application configuration file applies only to a specific application manifest and dependent assemblies. Isolated components compiled with an embedded ISOLATIONAWARE_MANIFEST_RESOURCE_ID manifest require a separate application configuration file. Manifests managed with CreateActCtx require a separate application configuration file.
The redirection specified by an application configuration file can override the assembly versions specified by application manifests and publisher configuration files. For example, if a publisher configuration file specifies that all references to an assembly be redirected from version 1.0.0.0 to 1.1.0.0, an application configuration file can be used to redirect a particular application to use version 1.0.0.0. An application configuration file applies only to the specified application manifest and dependent assemblies.
For a complete listing of the XML schema, see Application Configuration File Schema.
Application configuration files have the elements and attributes shown in the following table.
| Element | Attributes | Required |
|---|---|---|
| configuration | Yes | |
| windows | Yes | |
| publisherPolicy | Yes | |
| apply | Yes | |
| runtime | No | |
| assemblyBinding | Yes | |
| probing | No | |
| privatePath | Yes | |
| dependency | No | |
| dependentAssembly | Yes | |
| assemblyIdentity | Yes | |
| type | Yes | |
| name | Yes | |
| language | No | |
| processorArchitecture | Yes | |
| version | Yes | |
| publicKeyToken | No | |
| bindingRedirect | Yes | |
| oldVersion | Yes | |
| newVersion | Yes |
File Location
Application configuration files must be installed in the same location as the application’s application manifest.
File Name Syntax
The name of an application configuration file is the name of the application executable followed by .config.
For example, an application configuration file that refers to Example.exe or Example.dll would use the file name syntax shown in the following example. You can omit the field for if installing the configuration file as a separate file or if the resource ID is 1.
example.exe. .config
example.dll. .config
Elements
Names of elements and attributes are case-sensitive. The values of elements and attributes are all case-insensitive, except for the value of the type attribute.
configuration
A container element for the windows and runtime elements of an application configuration file. Required.
windows
Includes the parts of the application configuration file that apply to the redirection of Win32 assemblies.
The author of an application should not include a configuration file with a windows subelement as part of their application. This may be permitted if the configuration file’s only purpose is to enable the privatePath functionality of a probing element. The probing element is unavailable on systems earlier than Windows Server 2008 R2 and Windows 7.
publisherPolicy
Specifies whether to apply publisher policy.
This element has the attributes shown in the following table.
| Attribute | Description |
|---|---|
| apply | A value of «yes» applies the publisher policy. This is the default setting. The value «no» does not apply the publisher policy. |
runtime
Includes the parts of the application configuration file that apply to redirection of .Net assemblies.
assemblyBinding
Includes the redirection information for the application and the assembly affected by this application configuration file. The first subelement of assemblyBinding must be an assemblyIdentity that identifies the application.
Starting with Windows Server 2008 R2 and Windows 7 an assemblyBinding element can include a probing subelement.
probing
An optional subelement of an assemblyBinding element that extends the search for assemblies into additional directories. The additional directories are not required to be subdirectories of the directory of the assembly.
This element is unavailable on systems earlier than Windows Server 2008 R2 and Windows 7 and can only be used within a windows element.
This element has the attributes shown in the following table.
| Attribute | Description |
|---|---|
| privatePath | Specifies the relative paths of subdirectories of the application’s base directory that might contain assemblies. A maximum of nine subdirectory paths can be specified. Delimit each subdirectory path with a semicolon. |
You can use the double-dots special specifier in a path to denote the parent directory of the current directory. No more than two levels above the current directory can be specified using double-dots. Do not use triple-dots. For example, an application using the following probing element checks additional directories for an assembly.
dependency
A container element for at least one dependentAssembly. Every dependentAssembly can be inside exactly one dependency. This element has no attributes. Optional.
dependentAssembly
The first subelement must be an assemblyIdentity element that identifies the side-by-side assembly being redirected by the application configuration file. A dependentAssembly has no attributes.
assemblyIdentity
As the first subelement of an assemblyBinding element, assemblyIdentity describes and uniquely identifies an application. The application configuration file redirects the binding of this application to side-by-side assemblies. For example, the following assemblyIdentity indicates that the application configuration file affects the binding of the application mysampleApp to side-by-side assemblies. The assemblies being redirected would be identified in a dependentAssembly.
As the first subelement of a dependentAssembly element, assemblyIdentity describes a side-by-side assembly on which the application depends. The application configuration file reconfigures the identity of this required assembly. For example, the following assemblyIdentity and bindingRedirect reconfigures a dependency on Microsoft.Windows.SampleAssembly from version 2.0.0.0 to version 2.1.0.0.
Note that every assemblyIdentity included in a dependentAssembly must exactly match the assemblyIdentity in the assembly’s own assembly manifest.
The assemblyIdentity element has the following attributes. It has no subelements.
| Attribute | Description |
|---|---|
| type | The value must be win32 (lower case). Required. |
| name | The name attribute identifies the application being affected by the application configuration file or the assembly being redirected. Use the following format for the name: Organization.Division.Name. Required. For example: Microsoft.Windows.MysampleApp or Microsoft.Windows.MysampleAsm. |
| language | Identifies the language. Optional. For an assemblyIdentity referring to an assembly, if the assembly is language-specific, specify the DHTML language code. If the assembly is for worldwide use (language neutral) set the value as «*». |
| processorArchitecture | Specifies the processor running the application. |
| version | Specifies the version of the application or assembly. Use four-part version syntax: mmmm.nnnn.oooo.pppp. Required. |
| publicKeyToken | For an assemblyIdentity referring to an assembly, a 16-character hexadecimal string representing the last 8 bytes of the SHA-1 hash of the public key under which the assembly is signed. The public key used to sign the catalog must be 2048 bits or greater. Required for all shared side-by-side assemblies. |
bindingRedirect
The bindingRedirect element contains redirection information for the binding of the assembly. Each bindingRedirect must be included in exactly one dependentAssembly. The four-part version syntax of the new version and the old version must specify the same major and minor versions.
This element has the attributes shown in the following table.
| Attribute | Description |
|---|---|
| oldVersion | Specifies the assembly version being overridden and redirected. Use the four-part version syntax nnnnn.nnnnn.nnnnn.nnnnn. Specify a range of versions by a dash without spaces. For example, 2.14.3.0 or 2.14.3.0 2.16.0.0. Required. |
| newVersion | Specifies the replacement assembly version. Use four-part version syntax nnnnn.nnnnn.nnnnn.nnnnn. |
Remarks
Application configuration files do not specify files.
Where to find system, global and local Git config files on Windows and Ubuntu Linux
Community driven content discussing all aspects of software development from DevOps to design patterns.
- 5 Steps to Alleviate Endpoint Management Tool Sprawl –HCL Technologies Limited India
- 3 Security Best Practices for CI/CD –CircleCI
One of the five basic Git commands beginners need to learn is git config , if for no other reason than to perform an initial commit without the Git tool pestering for a user.name and user.email address. But the git config command commonly used to initialize these fields typically employs a global switch, which gets users wondering about Git’s competing local and system scopes.
That then leads to the question about where all of these variously scoped Linux and Windows git configuration files can be found. Here we will answer all of those questions about Git config file locations and where the various gitconfig files are stored.
Full list of where the Git configuration files config, gitconfig and .gitconfig are located on Windows and Ubuntu Linux.
Listed in descending order of specificity, Git provides four standard scopes for storing configuration data, plus a portable scope on Windows:
Note: You will notice a ‘portable scope’ mentioned in the Windows Git config table above. This scope was pointed out to me by a reader after this article first published. The portable scope is the most general and is overridden by all other scopes.
The scopes are cascading with the most specific file taking precedence over the most general. Local scope overrides global scope. Global scope overrides system scope.
If you set up multiple Git worktrees on the same computer, you can also use the Git worktree scope, although doing so requires this scope to be enabled. Worktree scope is the most specific and will override local.
Just to make life a bit more complicated, the variously scoped Git configuration files all have different names:
- gitconfig – the extensionless system Git config file
- .gitconfig – the global Git config file has no name, but is instead just an extension
- config – the local Git configuration file is simply named config, and like the system Git config file, has no extension
- config.worktree – the Git worktree configuration file flaunts both a name and an extension
Here is where you will find Git configuration files on Windows:
| Location of Windows Git Config Files | ||
|---|---|---|
| Scope | Location and Filename | Filename Only |
| System | \mingw64\etc\gitconfig | gitconfig |
| Global | C:\Users\username\.gitconfig | .gitconfig |
| Local | \.git\config | config |
| Worktree | \.git\config.worktree | config.worktree |
| Portable | C:\ProgramData\Git\config | config |
As for the location of the Linux Git configuration files, here is where you’ll find them on Ubuntu:
| Ubuntu Linux Git Config File Locations | ||
|---|---|---|
| Scope | Location and Filename | Filename Only |
| System | gitconfig | |
| Global | .gitconfig | |
| Local | /.git/config | config |
| Worktree | /.git/config.worktree | config.worktree |
To find the Git config file setting a given variable to a particular value, the –list and –show-origin switches of the git command can be useful. In the following example you can see the command indicating that the user.email property is set in the portable, system, local and global scopes. It also states exactly where those files Git config files are located.
Here is the git config command with list and show-origin swtiches run on Windows:
Here is the same command run on Ubnutu where the Git user.name property is set in three separate scopes:
On StackOverflow, the following command was suggested to help developers find the location of the Git config files:
The animated GIF below, pulled from 1998 when such things were cool, shows the above command being run on Ubuntu 20. Note how the command above lists the home directory as the location for the global Git config file, but when the sudo command is used below the global Git config file is in
Git config file locations on Ubuntu Linux.
Sometimes users go looking for the global and system Git config files and can’t find them. If you can’t find gitconfig or .gitconfig, it’s probably because it’s not there.
Git doesn’t actually create the gitconfig or .gitconfig files until they are referenced for the first time. Just asking Git to edit the file will force its creation, but until that happens, efforts to find the .gitconfig or gitconfig file will be fruitless.
The following operation will likely require sudo rights on a Linux distribution as you may be creating files in privileged \etc or \root directories. But when run with elevated permissions, these commands are sufficient enough to force the creation of global and system gitconfig and .gitconfig files:
Each of these Git commands will open the corresponding Windows or Linux Git config file in the configuration specified editor. You may edit the file if you please, or simply close the editor immediately to force config file creation.
Figure 2. The three main locations of Windows Git configuration files.
On the topic of editors, if you’d like to switch the Git editor to Notepad++, just issue the following command:
Always be careful editing the Git config files, because if you incorrectly edit any of these files, you just might ruin your entire Linux or Windows Git configuration.
Want to become a powerful Git user? Then take a look at the following Git articles and tutorials:
