About Side-by-Side Assemblies

A Windows side-by-side assembly is described by manifests. A side-by-side assembly contains a collection of resources—a group of DLLs, Windows classes, COM servers, type libraries, or interfaces—that are always provided to applications together. These are described in the assembly manifest.

Typically, a side-by-side assembly is a single DLL. For example, the Microsoft COMCTL32 assembly is a single DLL with a manifest whereas the Microsoft Visual C++ development system run-time libraries assembly contains multiple files. Manifests contain metadata that describes side-by-side assemblies and side-by-side assembly dependencies.

Side-by-side assemblies are used by the operating system as fundamental units of naming, binding, versioning, deployment, and configuration. Every side-by-side assembly has a unique identity. One of the attributes of the assembly identity is its version. For more information, see Assembly Versions.

Starting with WindowsВ XP, multiple versions of side-by-side assemblies can be used by applications running at the same time. Manifests, and the assembly version number, are used by the loader to determine the correct binding of assembly versions to applications. Side-by-side assemblies and manifests work with applications and the side-by-side manager as illustrated in the following figure.

In the preceding example, both Comctl32.DLL version 6.0 and Comctl32.DLL version 5.0 are in the side-by-side assembly cache and available to applications. When an application calls to load the DLL, the side-by-side manager determines whether the application has a version dependence described in a manifest. If there is no relevant manifest, the system loads the default version of the assembly. For WindowsВ XP, version 5.0 of Comctl32.DLL is the system default. If the side-by-side manager finds a dependence on version 6.0 stated in a manifest, that version is loaded to run with the application.

Several key system assemblies are being made available from Microsoft as side-by-side assemblies. For more information, see Supported Microsoft Side-by-side Assemblies. Application developers can also create their own side-by-side assemblies. For more information, see Guidelines for Creating Side-by-side Assemblies. In many cases it is possible to update existing applications to use side-by-side assemblies without having to change the application code.

Developers are encouraged to use side-by-side assemblies to create isolated applications, and to update existing applications into isolated applications for the following reasons:

• Side-by-side assemblies reduce the possibility of DLL version conflicts.
• Side-by-side assembly sharing enables multiple versions of COM or Windows assemblies to run at the same time.
• Applications and administrators can update assembly configuration on either a global or per-application configuration basis after deployment. For example, an application can be updated to use a side-by-side assembly that includes an update without having to reinstall the application.

Side-by-Side Execution in the .NET Framework

Side-by-side execution is the ability to run multiple versions of an application or component on the same computer. You can have multiple versions of the common language runtime, and multiple versions of applications and components that use a version of the runtime, on the same computer at the same time.

The following illustration shows several applications using two different versions of the runtime on the same computer. Applications A, B, and C use runtime version 1.0, while application D uses runtime version 1.1.

The .NET Framework consists of the common language runtime and a collection of assemblies that contain the API types. The runtime and the .NET Framework assemblies are versioned separately. For example, version 4.0 of the runtime is actually version 4.0.319, while version 1.0 of the .NET Framework assemblies is version 1.0.3300.0.

The following illustration shows several applications using two different versions of a component on the same computer. Application A and B use version 1.0 of the component while Application C uses version 2.0 of the same component.

Side-by-side execution gives you more control over which versions of a component an application binds to, and more control over which version of the runtime an application uses.

Benefits of Side-by-Side Execution

Prior to Windows XP and the .NET Framework, DLL conflicts occurred because applications were unable to distinguish between incompatible versions of the same code. Type information contained in a DLL was bound only to a file name. An application had no way of knowing if the types contained in a DLL were the same types that the application was built with. As a result, a new version of a component could overwrite an older version and break applications.

Side-by-side execution and the .NET Framework provide the following features to eliminate DLL conflicts:

Side-by-side execution uses strong-named assemblies to bind type information to a specific version of an assembly. This prevents an application or component from binding to an invalid version of an assembly. Strong-named assemblies also allow multiple versions of a file to exist on the same computer and to be used by applications. For more information, see Strong-Named Assemblies.

Version-aware code storage.

The .NET Framework provides version-aware code storage in the global assembly cache. The global assembly cache is a computer-wide code cache present on all computers with the .NET Framework installed. It stores assemblies based on version, culture, and publisher information, and supports multiple versions of components and applications. For more information, see Global Assembly Cache.

Using the .NET Framework, you can create applications and components that execute in isolation. Isolation is an essential component of side-by-side execution. It involves being aware of the resources you are using and sharing resources with confidence among multiple versions of an application or component. Isolation also includes storing files in a version-specific way. For more information about isolation, see Guidelines for Creating Components for Side-by-Side Execution.

Version Compatibility

Versions 1.0 and 1.1 of the .NET Framework are designed to be compatible with one another. An application built with the .NET Framework version 1.0 should run on version 1.1, and an application built with the .NET Framework version 1.1 should run on version 1.0. Note, however, that API features added in version 1.1 of the .NET Framework will not work with version 1.0 of the .NET Framework. Applications created with version 2.0 will run on version 2.0 only. Version 2.0 applications will not run on version 1.1 or earlier.

Versions of the .NET Framework are treated as a single unit consisting of the runtime and its associated .NET Framework assemblies (a concept referred to as assembly unification). You can redirect assembly binding to include other versions of the .NET Framework assemblies, but overriding the default assembly binding can be risky and must be rigorously tested before deployment.

Locating Runtime Version Information

Information on which runtime version an application or component was compiled with and which versions of the runtime the application requires to run are stored in two locations. When an application or component is compiled, information on the runtime version used to compile it is stored in the managed executable. Information on the runtime versions the application or component requires is stored in the application configuration file.

Runtime Version Information in the Managed Executable

The portable executable (PE) file header of each managed application and component contains information about the runtime version it was built with. The common language runtime uses this information to determine the most likely version of the runtime the application needs to run.

Runtime Version Information in the Application Configuration File

In addition to the information in the PE file header, an application can be deployed with an application configuration file that provides runtime version information. The application configuration file is an XML-based file that is created by the application developer and that ships with an application. The Element of the section, if it is present in this file, specifies which versions of the runtime and which versions of a component the application supports. You can also use this file in testing to test an application’s compatibility with different versions of the runtime.

Unmanaged code, including COM and COM+ applications, can have application configuration files that the runtime uses for interacting with managed code. The application configuration file affects any managed code that you activate through COM. The file can specify which runtime versions it supports, as well as assembly redirects. By default, COM interop applications calling to managed code use the latest version of the runtime installed on the computer.

For more information about the application configuration files, see Configuring Apps.

Determining Which Version of the Runtime to Load

The common language runtime uses the following information to determine which version of the runtime to load for an application:

The runtime versions that are available.

The runtime versions that an application supports.

Supported Runtime Versions

The runtime uses the application configuration file and the portable executable (PE) file header to determine which version of the runtime an application supports. If no application configuration file is present, the runtime loads the runtime version specified in the application’s PE file header, if that version is available.

If an application configuration file is present, the runtime determines the appropriate runtime version to load based on the results of the following process:

The runtime examines the Element element in the application configuration file. If one or more of the supported runtime versions specified in the element are present, the runtime loads the runtime version specified by the first element. If this version is not available, the runtime examines the next element and attempts to load the runtime version specified. If this runtime version is not available, subsequent elements are examined. If none of the supported runtime versions are available, the runtime fails to load a runtime version and displays a message to the user (see step 3).

The runtime reads the PE file header of the application’s executable file. If the runtime version specified by the PE file header is available, the runtime loads that version. If the runtime version specified is not available, the runtime searches for a runtime version determined by Microsoft to be compatible with the runtime version in the PE header. If that version is not found, the process continues to step 3.

The runtime displays a message stating that the runtime version supported by the application is unavailable. The runtime is not loaded.

You can suppress the display of this message by using the NoGuiFromShim value under the registry key HKLM\Software\Microsoft\.NETFramework or using the environment variable COMPLUS_NoGuiFromShim. For example, you can suppress the message for applications that do not typically interact with the user, such as unattended installations or Windows services. When this message display is suppressed, the runtime writes a message to the event log. Set the registry value NoGuiFromShim to 1 to suppress this message for all applications on a computer. Alternately, set the COMPLUS_NoGuiFromShim environment variable to 1 to suppress the message for applications running in a particular user context.

After a runtime version is loaded, assembly binding redirects can specify that a different version of an individual .NET Framework assembly be loaded. These binding redirects affect only the specific assembly that is redirected.

Partially Qualified Assembly Names and Side-by-Side Execution

Because they are a potential source of side-by-side problems, partially qualified assembly references can be used only to bind to assemblies within an application directory. Avoid partially qualified assembly references in your code.

To mitigate partially qualified assembly references in code, you can use the element in an application configuration file to fully qualify partially qualified assembly references that occur in code. Use the element to specify only fields that were not set in the partial reference. The assembly identity listed in the fullName attribute must contain all the information needed to fully qualify the assembly name: assembly name, public key, culture, and version.

The following example shows the application configuration file entry to fully qualify an assembly called myAssembly .

Whenever an assembly load statement references myAssembly , these configuration file settings cause the runtime to automatically translate the partially qualified myAssembly reference to a fully qualified reference. For example, Assembly.Load(«myAssembly») becomes Assembly.Load(«myAssembly, version=1.0.0.0, publicKeyToken=. culture=neutral»).

You can use the LoadWithPartialName method to bypass the common language runtime restriction that prohibits partially referenced assemblies from being loaded from the global assembly cache. This method should be used only in remoting scenarios as it can easily cause problems in side-by-side execution.

Side by Side Configuration Is Incorrect Error in Windows 10 [FIXED]

Last Updated: 4 years ago

If you are on Windows 10, and you are seeing a “side by side configuration is incorrect” error, you are not alone. Many Windows 10 users have reported that they have encountered this error after they tried to launch, install or uninstall a program.

But the good news is you can fix this error. Here are four fixes you can try. You may not have to try them all. Just work from the top down until you find the one that works.

Method 1: Try another installer

If you see this error when you try to install a program, it is possible the installer or installation package is corrupted. In this case, you should download a correct installer to set up the program. You can download its latest version from the program’s official website. Then try installing it on your computer. If the error came from the original installer, you won’t see the error now.

Method 2: Reinstall the problem program

If the error occurs when you are launching a program, the program may be corrupted. Reinstalling the problem program is helpful for fixing your problem. To do so:

1) On your keyboard, press the Windows logo key and R at the same time to invoke the Run box.

2) Type “control” and press Enter to open Control Panel.

3) Select Large icons in the View by drop-down menu.

4) Click Programs and Features.

5) Right click the problem program and select Uninstall.

6) Download the latest version of your program from the its official website and install it on your computer.

7) Launch your program and see if this fixes the error.

Method 3: Reinstall the Microsoft Visual C++ Redistributable Packages

The “side by side configuration is incorrect” error may occur because the Visual C++ Runtime on your computer is corrupted or missing. Reinstalling the Microsoft Visual C++ Redistributable Packages on your computer can help you restore the corrupted or missing Runtime. To do so:

1) On your keyboard, press the Windows logo key and R at the same time to invoke the Run box.

2) Type “control” and press Enter to open Control Panel.

3) Select Large icons in the View by drop-down menu.

4) Click Programs and Features.

5) Delete every Visual C++ Redistributable (right-click on each of the programs with the name of “Microsoft Visual C++ XXXX Redistributable” and then select Uninstall).

6) Go to the Microsoft Visual C++ downloads website to download the programs you have just uninstalled. Then install them on your computer.

7) Restart your computer. If this method works for you, the error won’t bother you again.

Method 4: Run system checks

The error may also occur because there are corrupted system files on your Windows 10 system. You should run some system checks to scan your computer and perform a repair. To do so:

1) Click the Start menu (the Windows logo) at the bottom left of your screen, then type “cmd“.

2) Right-click “Command Prompt” and select “Run as administrator“.

3) Type “sfc /scannow” and press Enter on your keyboard.

4) Wait for the scan to complete. Then check to see if the error is gone.

5) If the problem persists, go back to Command Prompt, and then type “DISM.exe /Online /Cleanup-image /Restorehealth” and press Enter.

6) Wait until the process completes. Then check to see if this fixes the error.

Method 5: Reset your system

If none of the methods above can help you, you should try resetting your Windows 10 to fix the error.

IMPORTANT: This will remove all your files and programs. So before you go on, you should create a backup of your important files and put it into a safe place.

To reset your Windows 10:

1) Click the Start menu (the Windows logo) at the bottom left of your screen, then select Settings (the gear icon).

2) Click Update & Security.

3) Select Remove everything.

4) Wait for the system to complete the resetting process.

5) Install and launch the program that caused the error. If this method works, you won’t see the error any more.