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.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">

<dependency> <dependentAssembly> <assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50727.762" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"> </assemblyIdentity> </dependentAssembly> </dependency> </assembly>

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 <assemblyidentity> always in the manifest file.

Now add the below fields in the Win32 Assembly section. Add all the fields in the

win32 assembly section.

<assemblyIdentity type="win32" name="Microsoft.VC80.MFCLOC"

version="8.0.50727.4053" processorArchitecture="x86"

publicKeyToken="1fc8b3b9a1e18e3b"/>

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 <assemblyidentity> field under this .policy file. I am providing the

same below. This will vary from DLL to DLL and Version to Version.

<assemblyIdentity type="win32-policy" name="policy.8.0.Microsoft.VC80.MFCLOC"

version="8.0.50727.4053" processorArchitecture="x86"

publicKeyToken="1fc8b3b9a1e18e3b"/>

Now add all the fields in the above <assemblyidentity> field in the win32 assembly as

mentioned below. Refer below Image.

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.