Questions and Suggestions — July 20th Edition

This is the re-occuring post for questions and suggestions.

I will not be able to provide any support beyond the trivial Q&A. For guaranteed quality of support, please contact Microsoft Product Support Service.

Comments (5)

  1. Koby Kahane says:

    The IAssemblyCache, etc., interfaces were recently documented for native Win32 SxS assemblies in sxs.dll, and appear similar to those from fusion.dll. See

    These interfaces are documented as available with Vista and Server 2008’s sxs.dll, but appear to be available in XP as well.

    In the past, it has been stated MSIs are the only supported way to install native Win32 side by side assemblies, due to serviceability issues. Does the documentation of IAssemblyCache::InstallAssembly from sxs.dll change this position? Should custom installers not based on MSI use this to deploy SxS DLLs?

  2. MSI is still the prefered way to install SxS assemblies.

    Since the APIs are documented, you should be able to use them to install Sxs assemblies.

  3. Koby Kahane says:

    Thanks for your answer.

    As a follow-up question, like I mentioned, the APIs are documented as available on Vista and Server 2008, but not XP – even though they seem to be present in that version of sxs.dll as well. Is it simply a documentation oversight or should the use of the SxS API be avoided on XP?

    If I choose to install something like the Visual C++ 2005 redistributables, which are SxS assemblies, directly with the SxS API instead of MSI, that should not prevent their serviceability, right? If a hotfix were to come out, it could still apply whatever policy change is required in the winsxs store for the new revisions to be used even though the original assemblies were not installed with MSI?

  4. The APIs are not tested on XP and Server 2003. That is why they are documented on Vista+.

    I will ask VC questions on VC team’s blog, for example,

  5. Phil Wilson says:

    I wonder if you’d briefly revisit your code to enumerate assembly identity attributes. In the absence of a PublicKeyToken it returns the string "neutral". I’ve double-checked the code and debugged through it, which is my way of saying I believe I’ve copied the code correctly! So internally "neutral" seems to be the actual value, and I was wondering if you could confirm that. Interesting that that it returns a value at all when there isn’t one.

Skip to main content