Winsxs (Win32) Assemblies handling in MSI Package.
Created By: JS Reddy
Winsxs :-
This is a great puzzle for everybody to understand what exactly the files which installed under Windows\Winsxs. The size of this folder is too big. Many people doesn’t understand why Microsoft invented this folder from XP onwards and what’s its use.
In the below, I am trying to give some information about the Winsxs folder and its unbelievable advantages. This might help you to understand its importance up to some extent at least.
What is Winsxs Called?
These Winsxs called as Win 32 Assemblies or Side by side assemblies.
The main Idea behind the Winsxs folder is implemented by Microsoft is to overcome the DLL Hell problems in windows. In Short, what is DLL Hell? “If any application relies on specific version of DLL, EXE, OCX in one location, another application replacing the resource with same name & some higher. The First application which relies on specific version couldn’t function as Expected and it will not even repair as the DLL as the file is already present in the location (i.e. with higher version is present in the same location). This is called DLL Hell”
So Overcome these issues, Microsoft found an alternative way like different version of the same DLL, OCX, EXE can be resided the system in their own location instead of placing them in the shared locations. The advantage of Winsxs over system32 is that you can have more than one version of a particular DLL with the same name. With system32, you had to overwrite a DLL if you wanted to add a new version with the same name. Winsxs uses directories with version information to isolate DLL's from each other.
Now I will enter in to our main topic (Winsxs) to discuss. In this folder every application creates its own folder with some unique name based on the different factors. So, one application resources cannot be clashed with the other application resources.
You might have seen the folders like below in the Winsxs.
The above highlighted directories contain some set of DLL’s with same name and different versions. So the applications can use their own specific version of DLL when they want to use.
The above directory name contains some pieces of information in how the application identifies its own DLL version.
Take an example of “x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.762_none_10b2f55f9bffb 8f8”
x86 (processor architecture): Built for x86 (32-bit Intel Processor and compatibles) microsoft.vc80.crt (name): Microsoft Visual C 8.0 C RunTime 1fc8b3b9a1e18e3b (public key token): A unique ID for C Runtime 8.0.50727.762 (version): Version of the DLL's (right click on the DLL, select "Properties", and then the "Details" tab, and you should see this number) none (language): The language these DLL's are designed for 10b2f55f9bffb8f8: Not sure, but I assume this is a unique ID for this particular version of the DLL's
So how does an application know what version of a DLL it needs to load? That is where a "manifest" comes into play (Manifest is much required while handling these win32 assembles). A manifest is an XML file that contains information used to create the directory in C:\Windows\winsxs so that a particular DLL can be loaded. If you write an application that uses the C runtime library (99% of the time you will), then you are going to need a manifest. This manifest you will always find under the
Here below is an example of the .Manifest file which will give all the information used to create a folder under the Winsxs directory.
The main required things will be under AssemblyIdentity section. Always look in to this section and get the information required.
Note: - Always use the Manifest file created by default under this location. Do not alter Manifest file unless you have much idea how to modify.
Now, I think you are somewhat familiar about the Winsxs Folder Importance.
How to Handle through MSI Tables :-
These Winsxs files can installed on XP if they are passed as files through the MSI. But they cannot install on windows 7. IN Windows 7, this location is restricted. If they are properly handled in the MSI, then only they can install.
Because of its elevated importance, from Vista onward the WinSxS directory is owned by the Trusted Installer service SID. By default not even administrators can modify its contents (without taking ownership first). Uninstalling applications does not immediately free space in the WinSxS directory; space for unused assemblies is garbage-collected over time by the Installer service
So, here below I am explaining how these files can be handled in ISM/MSI.
Before entering in to the concept, I want let you know some interesting things here.
Policies Folder: - This folder is only useful in Windows XP. This is folder will not be even existed even in the Windows 7. So, when this Folder and its contents are added in the package, don’t forget to conditionalize to install only on Windows XP & 9x operating systems (i.e. Windows 95,98, ME) The location of the above folder is “C:\Windows\Winsxs\Policies”.
If the policies are conditioned to install only on XP, but how they function on windows 7? This question may arise in your mind. Here the answer for your question.
The policies (it contains a .policy file and .cat file in the specific dll location) files in Windows 7 will be installed to the “C:\Windows\Winsxs\Manifests” with their own naming to differ from the manifest file. These .policy file will be installed as .manifest in windows 7 (this will be automatically changes its naming and extension if they handled through the MSI Tables)
In the ISM/MSI, the policy folder (For Windows 7) will look like this.
Later, we will have a deep discussion on the above. Don’t worry. Keep only the directory for Windows 7 will be as above highlighted and for XP, the file will be installed under the \Winsxs\Policies\..\ Folder.
Manifests Folder:- This folder is only useful in Windows XP. This folder will be existed in windows 7 also, but the files are automatically generated in windows 7, so no need to pass as a file in the ISM/MSI. Going on you can get clear IDEA about all these things.
Folders Under Winsxs:- What do you think? Is the folders naming is exactly same in both windows XP and Windows 7. No not at all. They are different in both locations. Got through the below example carefully.
Windows XP:- folder under windows xp.
Windows 7:- Folder under Windows 7.
In the above images, have you observed the content highlighted in “Yellow”. That makes the difference for Windows XP and Windows 7.
“x86_microsoft.vc80.mfcloc_1fc8b3b9a1e18e3b_8.0.50727.762_none_43efccf17 831d131”
x86 (processor architecture): Built for x86 (32-bit Intel Processor and compatibles) microsoft.vc80.mfcloc (name): Microsoft Visual C 8.0 C RunTime 1fc8b3b9a1e18e3b (public key token): A unique ID for C Runtime 8.0.50727.762 (version): Version of the DLL's (right click on the DLL, select "Properties", and then the "Details" tab, and you should see this number) x-ww & none (language): The language these DLL's are designed for. This differs in Windows XP and Windows 7. 43efccf17831d131: Not sure, but I assume this is a unique ID for this particular version of the DLL's
So, as the folder structure in Windows XP and Windows 7 are different, so in the application two folders need to create under the Winsxs as per the requirement. They should be conditioned accordingly on which OS they are to be installed.
Here we are entering in to the ISM/MSI directory view and their specifications.
This is how it appears in ISM/MSI while handling Winsxs (Win32) Assemblies.
These below Manifests, Policies, Files under Windows XP sections are completely relevant for windows XP. So I am dividing these in two main phases as Windows XP Phase and Windows 7 Phase. Windows XP Phase:-
Manifests:
This folder only installs on Windows XP. Make conditionalize the Component to install only on XP and 9x Operating systems. Only the DLL specific .cat and .manifest file should be present in the component. Do not set any one file of these two as a keypath for the component. This component will not be installed on windows 7.
The Key path for the Manifest file component should be as below.
For the key path, \SideBySide\Installations\x86_Micorsoft.-----\downlevel_Manifest.---- “ under this hive, default key should be set as keypath.
Policies:
This policies folder will be only installed on Windows XP not on windows 7. So make sure that you set proper condition for the component.
This below resources highlighted are to be installed in Windows XP only.
Capture the above registry while doing source validation, set the above as the key path. In the above, under “\SidebySide\Installations\x86_Policy.----- \downlevel_Manifest.----“ will be present in the registry hive. Extract the particular version of DLL present in the hive, create “default” key under the hive and set as key path.
Note: Concentrate on blue marked section in red marked content in the registry.
XP Files under Winsxs:
These below mentioned are the files that are installed as files in windows XP. For this, all the files to be present in the single component and no DLL should be set as a key path.
The files are shown as below with an example.
These Files should be installed only on Windows XP or 9X operating systems. So, they should be conditioned accordingly. No File should be set as key path for the component. The key path will be as follows. In the below section, concentrate on blue marked section in the red marked phase. The child hive should be “downlevel_payload.----”
Note: Condition for the components which are targeted for Windows XP or 9X OS only is as follows. (VersionNT < 600) or Version9X
Please go through the above three sections if you are facing any contradiction. I think, you might face some contradiction while setting key path for the components. So, please go through it once again.
Here all the things that are required to handle in windows XP are completed. You might ask, there is no problem with Winsxs in windows XP, so again why it is to follow this much lengthy procedure where it working without any issues. But my intension to make you all perfect in all aspects. This is one of the examples. If everything followed with the best procedure and best quality, it might definitely help you. So are you following the procedure or not? You will. Windows 7 Phase:-
Here below our main task comes in to picture where we are facing some issues with Winsxs\ files. These files need to handled properly through a defined process as I am going to explain. First we will discuss about the directory structures in ISM/MSI and the files inside the folders, key paths, specifications of the files, where they will be installed in windows 7, how to add entries for handling Win32 assemblies.
Windows 7 files under Winsxs:-
These below mentioned are the files are to be installed on Windows 7. You observed the difference between the file which are installing in Windows XP. Check once again.
Have you identified the difference, If not I will tell you.
This Windows 7 location files contains two files extra like .manifest and .cat file along with the files which are installing in windows XP. The location is also different and I already described how the location differs in both Win XP and Win 7.
The files are displayed as below.
Find the .manifest and .cat files are highlighted in the above image. They are going to play a vital role here. The all files should be present in the single component. The key path of the component should be any dll in the component.
After installing the application in Windows 7, the DLL’s will be resided in the same location, Whereas the .manifest and .cat files will be installed under “Winsxs\Manifests”. These files will be automatically redirected in to the specific manifest location if the below procedure is followed.
The Manifest & CAT files are installed under “WinSXS\Manifests” as follows.
The DLL’s will be installed as it is in the directory created in ISM/MSI.
The handling of these manifest and CAT files in the ISM/MSI is as follows.
Step1 (In ISM Only): Go for the Component-- Go for “.NET Settings” ---Always set the attribute as follows for the component “.NET Scan at Build = None”. Sometimes it may set as “.NET Scan at Build = Dependencies and Properties”. Refer the below image.
Step 2:-
Go for the component --- Click on “Advanced Settings”--- Right Click on “Assemblies” ----- Add “Win32 Assembly”. Refer the below image.
Once you done with the above steps, then open the manifest file with “Notepad”.
The manifest file will be as follows. Here I am providing the required in formation only in the below. You can find the
Now add the below fields in the Win32 Assembly section. Add all the fields in the win32 assembly section.
Manifest :- Select the manifest file in which you are using for fetching the information.
File Application:- Always set it as “Global Assembly Cache”
Name:- Get this name from manifest file in the name field.
Type:- Get this type from manifest from the type field. (if the Manifest file is used, always it might be “Win32”.)
Version:- Get this Version from the Version field of the manifest field. preocessArchitechture:- Get this information from relevant field in manifest file. publicToken:- Get this information from the relevant field in the manifest file.
Now this manifest file handling was completed.
Policies Under WinSXS for Windows 7:- Now here the interesting topic starts. There will be no Policies folder under “Winsxs” as Windows XP in Windows 7. But where these policies are reflected in windows 7? This question may arise in your mind. Here I will explain. The Policy Folder contain .policy and .cat file together in Windows XP. While they installed in windows 7, the .policy file will automatically converted as .manifest and the naming convention will also change based on different factors. The .CAT file name also will be same as the .manifest file created by the .policy file. These .manifest and .cat file will be installed under the “Winsxs\Manifests” automatically. These are properly handled in Vendor MSI’s. So, the same procedure should be followed in the repackages applications also.
So, the procedure will be explained below. First how the directory structure will be visible under the ISM/MSI will be as follows.
The Name of the folder starts with “x86_Policy”. You can identify with this. By the way, two file .policy and .cat files should be present in the same component. The .policy file should be set as a key path for the component. The component should be conditioned to install only on windows 7.
Once the above part done do follow the next step to handle this .policy in ISM/MSI.
Go for the component --- Click on “Advanced Settings”--- Right Click on “Assemblies” ----- Add “Win32 Assembly”. Refer the below image.
Once the “Win32” assembly added, then open the .policy file in the “Notepad”.
You can find the
Now add all the fields in the above
Manifest :- Always select “.policy” file in the dropdown.
File Application:- Always set as “Global Assembly Cache”.
Name:- Get this from the name field in the .policy file.
Type:- Get this from the type field of the .policy file.(If you are using .policy file, it might be always “Win32-policy”)
Version:- Get this from the version field from the .policy field. processArchitechture:- Get this from the processArchitechture field from the .policy file. publicToken:- Get this information from the .policy file.
All the above information might change from DLL to DLL and Version to Version. Do not use one DLL information with another. Handle them carefully.
NOTE:- Sometimes, the DLL’s present in the Winsxs folder should be also added in to “System32” location.
Once all the above things are done, now clarify once again in the ISM/MSI tables.
Table Level checking :-
Two table will be reflected for the above all these things.
1. MsiAssembly 2. MsiAssemblyName
MsiAssembly:-
Go for “MsiAssembly” table, the entries should be appeared as follows.
The “File_Application” column should be always empty if you are handling “Win32” Assemblies.
The “Attributes” column should contain the “1” value for “Win32” assemblies.
Don’t worry, these “File_Manifest” contents are looking different as we set in UI. This contents will somewhat modified after building ISM. If you are handling in MSI, They will appear as it is in the UI.
MsiAssemblyName:-
Go for “MsiAssemblyName” table in the ISM/MSI. The entries will be appeared as follows. All the information you added in the UI will be appeared here.
Now, if you are confident you can add the entries directly in the ISM/MSI tables.
Now the choice is yours.
Make sure that the two standard actions for Installing and uninstalling the assemblies present in the “Install Execute Sequence” Table of MSI.
Note: After uninstalling the package, these Winsxs files from the package will not be deleted from the build even though they are not set as permanent. So, no need to think about clean uninstallation for these files.
Here the main concept of handling assemblies is completed.
Why these Win32 Assemblies need to handle through Assembly tables?
These Win32 assemblies are not always mandatory to handle through the Merge Modules. There is no any special or different procedure followed in merge modules. So, the output and the functionality will be exactly same.
So, where the Win32 assemblies are to be handled through the merge modules? Where exactly they make the difference by handling through the merge modules?
1. When the Win32 assemblies might be common for different applications.
Eg: VC Distributable resources.
In this case, it is going to save the time not handle these same assemblies again and again. The merge modules can be used for N number of packages.
2. While creating the directory structure for Win32 assemblies, the Install shield might create some problems. The files which are going to different location will be appeared in single location even though they created properly.
Now, you decide yourself to handle these Win32 assemblies. The decision is up to you whether to handle through MSI tables or Merge modules.
Here below, I will explain brief procedure to create merge modules for Win32 assemblies.
In Install shield, Go to File--- New-- Select “Merge Module Project”
This will exactly look like as ISM only. But the difference is, There will no Feature will be available in Merge Module.
One you select “Merge Module Project”, the window Opens like below. While filling the general information, keep in mind that you are filling the “General Information” properly.
General:
ProdutName: This will be the name of the product you are handling the MSM.
ProductVersion: This you can fill the version you finds in the .manifest file. I think I might not need to mention what is the .manifest file and where it can be available.
Module Language: This you can leave as it is “Language Independent”. If you want to specify any language, you can but with a valid reason.
INSTALLDIR: TARGETDIR
Summary Information Stream:
Tittle: Merge Module
Subject: This is quite important section. This is the name appears in the Merge Modules View when selecting or browsing in the ISM where you want to use.
Eg: Visual C++ 8.0 MFCLOC (x86) Winsxs MSM Beta3
Author: If we are creating the Custom Merge Modules, give the Author name as
“Dell”
Keywords: Leave this field as it is.
Package Code: Generate package Code always.
Template Summary: Mention the architecture if it is only required. Otherwise, set as “;1033”
Summary Information Stream Comments: Not Available
Schema: 200
Here the General Information was filled as per our requirements.
Now, we have to handle the Win32 assemblies in the Merge Module project. This is exactly same as the complete procedure mentioned in the above (How to Handle through MSI Tables).
After completion of your Build, the MSM will be generated as output file.
Keep the MSM in the “C:\Program Files\Common Files\Merge Modules”, browse the MSM in to the ISM where you want to include the MSM, Build the ISM. The required part completed.
The location to browse the Merge Modules is mandatory. This is our standard.
Once the package is completed, do not forget to deliver the MSM files also whichever used in the package. Some common error messages and their resolution:-
1. If you get the below error message, how you think to proceed? What might be the mistake you did in the package while handling Assemblies?
Sol: The error is exactly same installing the MSI without assembly handling. The mistake is, you might not properly conditionalize the components which are to be installed only on Windows XP. Check all the components are properly Conditioned according to their target platforms.
2. This below error message is quite different.
What might error cause in the package?
Sol: This is quite interesting one. Go to “MsiAssembly” table, you can see the entry like this.
As I mentioned in the above theory, the “File_Application” column entry should be empty in MsiAssembly table. So, this is the error causing for the application.
So, to resolve this, please go through below procedure.
Go to component shown above in MsiAssembly table with the File_Application column entry.
The dependencies and Properties might be set to the component. Set it to “None”.
Go for the advanced setting of the same component. Go for the Win32 assemblies section which previously added.
The File Application entry (Marked in RED) was set to dll. It should not be DLL. It Should be set to “Global Assembly Cache”. For more information, read the above theory from starting onwards. Note: While changing this to Global Assembly Cache, take care of the component target directory. The target directory will be changed to “[GlobalAssemblyCache]”. The actual target location will be disappeared. SO again, manually browse the target Location for the component.