Re: WinSxS, functional under 2k ?

Do you recall the term "DLL Hell"? The new(er) Side-by-Side Assembly technology was introduced with Windows XP to help reduce or eliminate DLL Hell. In short, Side-by-Side Assemblies permit the use of different versions of the same shared system DLLs.

If you recall earlier Windows versions, like Windows 95, when you installed an application you were (usually) warned if the installer tried to replace a DLL from the system folder with an older version and you were asked if you wanted to accept the change. Those with enough Windows experience knew of the consequences of replacing DLLs in the system folder with older ones, those who didn't have enough experience quickly learned of the consequences of replacing DLLs with older versions!

With private DLLs there are few or no problems with DLL versioning as private DLLs are placed in the program's folder. If you have different versions or releases of the same program simply installing the different versioned programs in different folder eliminates private DLL version conflicts. Until Windows XP it wasn't so easy to use different versions of shared system DLLs, that is what the new Side-by-Side assemblies attempts to resolve.

This business of applications replacing system DLLs wily-nilly and the DLL Hell that ensued was somewhat fixed with the Windows File Protection feature (WFP) introduced with Windows 2000 but the shared DLL versioning problem was not really fixed or properly addressed. Considering WFP and the fact that WinSxS is a protected folder I am somewhat surprised that you could "delete" this folder or manually delete/replace files in the folder, on Windows XP and later WFP does not easily permit this.


Wikipedia's concise explanation of SxS is one of the better one:

"A common issue in previous versions of Windows was that users frequently suffered from DLL hell, where more than one version of the same Dynamically Linked Library (DLL) was installed on the computer. As software relies on DLLs, using the wrong version could result in non-functional applications, or worse. Windows XP solved this problem by introducing side-by-side assemblies. The technology keeps multiple versions of a DLL in the WinSxS folder and runs them on demand to the appropriate application keeping applications isolated from each other and not using common dependencies."

http://en.wikipedia.org/wiki/Features_new_to_Windows_XP#Application_isolation_.26_side-by-side_assemblies


The rest of this post consists of excerpts and explanations from Microsoft articles:

[Quote]

Side-by-Side Sharing

The workings of the new (XP) UI rely on a side-by-side sharing requirements structure. As a solution for versioning problems and DLL Hell, Microsoft strongly suggests that applications adopt a side-by-side versioning strategy. As seen in the implementation of ComCtl version 6, side-by-side components are the future of Windows development. This section gives you an overview about what's new for side-by-side sharing for Windows XP. For an in-depth look into this topic, see How To Build and Service Isolated Applications and Side-by-Side Assemblies for Windows XP. For background on side-by-side component sharing issues and DLL redirection, see Implementing Side-by-Side Component Sharing in Applications (Expanded).

With side-by-side components, multiple versions of a component are installed simultaneously. An application is bound to the version of the component with which it was designed and tested.

With Windows XP, there's an infrastructure to support assemblies and isolated applications (both COM+ and Win32). A code change should not be required to get at side-by-side assemblies from Win32 applications. Applications can use the latest system assemblies without global impact.

In short, isolated applications are valuable because they are more reliable. They are built and shipped with all needed components and are not affected by changes that other applications make. Isolated applications use a manifest, which is an XML file containing information that self-describes an assembly or an application. All binding and activation metadata, such as COM classes, interfaces, and type libraries, is now stored in the manifest, rather than the registry. There are two types of manifest files: applications manifests, which describe isolated applications, and assembly manifests, which describe individual assemblies.

An isolated application may use side-by-side assemblies. Assemblies are the fundamental units of naming, binding, versioning, deployment, and configuration. They come in two varieties, shared and private. A shared assembly is available for use by multiple applications on the computer, installed in the WinSxS folder in the Windows directory. A private assembly is only visible to that application and is deployed within the directory structure of the application.

There's another benefit for application developers in using side-by-side sharing; your schedule can be much clearer. Your development schedules are not affected by the release schedules of the components you use.

[end quote]

http://msdn.microsoft.com/en-us/library/ms997638.aspx


Windows 2000 doesn't understand diddly squat of these new Side-by-Side Assemblies, here are more passages from Microsoft articles:

"If you install your application on a computer that is running Microsoft Windows 2000 or earlier versions of Windows, do not ship the side-by-side assembly in your application folder to those operating systems. Instead, the side-by side assemblies should be used from the system folder. If you install a shared component to the system folder as part of your setup, make sure that you are not downgrading the version if one is previously present."

http://msdn.microsoft.com/en-us/library/ms997620.aspx

and:

"On versions of Windows that do not support deployment of shared side-by-side assemblies, such as Windows 98 and Windows 2000 Server, the Visual C++ libraries are installed in the System32 folder and WinSxS folder under the operating system root directory. This setup enables running Visual C++ applications on these operating system versions because they do not support manifest-based binding of applications to dependent DLLs. On these operating systems, when an application is loaded, the corresponding manifest file is ignored and the operating systems searches for dependent DLLs using paths set in the current running environment. However, on upgrading the operating system to a version that support manifest-based binding, such as Windows XP, Windows Server 2003, or Windows Vista, applications built with manifests start using the DLLs installed in the WinSxS folder."

http://msdn.microsoft.com/en-us/library/ms235624(VS.80).aspx

John

someone watching wrote:

Hi John

Thanks for the useful information. Curious, what exactly is the purpose
of the WinSxS (side by side?) implementation for? Is it redundancy? I
noticed numerous DLL's in there are also in system32 (or elsewhere) but
are sometimes even different versions!

I found (in XP) .NET didn't work after deleting some DLL's in WinSxS
even though they were in system32. A registry check showed pointers for
those specific DLL's to WinSxS... (and these were common shared DLL's)

Well everything is restored once again but beets me why yet another
directory with seemingly duplicated files!
__
"John John (MVP)" <audetweld@xxxxxxxxxxx> wrote in message
news:#mowc$QxIHA.3384@xxxxxxxxxxxxxxxxxxxxxxx

someone watching wrote:

Steph, I know in XP if MS .NET framework is installed and you change

the

WinSxS name, delete it etc. any time .NET goes to start it will

throw an

error message and fail to start. I do not have .NET installed in W2K

so

don't know if the same holds true for that OS but would imaging so!

No, not at all. The new Side-by-Side Assemblies require XP or better

to

work, Windows 2000 does not support this. Deployments on Windows 2000
only include this folder from upgrade purposes.



In other words, if you have programs dependant on .NET, changing the
WinSxS folder may cause it to fail.

Not at all. Windows 2000 does not load *any* files from the
Side-by-Side assembly cache, Windows 2000 does not recognize WinSxS.
Deployments on Windows 2000 require that the files be placed in the
%systemroot%\system32 folder or in the program's folder.

John



.

Relevant Pages

  • Re: Service pack 3 problem
    ... Opening the regsvr32 file is as you say, no dll specified, followed by the ... and no dllcache folder exists, ... After show hidden files, folders, and system files, use WINDOWS Explorer ...
    (microsoft.public.windowsxp.general)
  • Re: Location of custom DLL for use with MSAccess
    ... folder as the MDB, they should be found. ... I have developed a DLL in C++ for use with an Access 97 database ... development environment) and Windows XP. ... containing the MDB file, ...
    (microsoft.public.access.formscoding)
  • Re: Location of custom DLL for use with MSAccess
    ... it has to be in the same folder as the FE of your app. ... I'm not sure why the OP states that placing the DLL ... The rules for Windows to search/find DLL's are clearly stated on the MSDN ...
    (microsoft.public.access.formscoding)
  • Re: Windows file protection
    ... earlier versions of Windows. ... Many programs use common DLL ... XP retrieves the file from the DLLCache folder or ServicePackFiles ... Many people recommend SFC /Scannow as a problem solver. ...
    (microsoft.public.windowsxp.general)
  • Re: Deploying with Custom References
    ... When loading Assemblies, the Framework uses its own set of rules ... about where to look and the DefaultLocation folder is one of those places. ... so the Normal search sequence that the Framework uses found the Dll. ...
    (microsoft.public.dotnet.languages.vb)