|
Short Description
|
Assembly.Load* will prefer the serviced version of the assembly in the GAC to enable the central servicing scenario. |
Affected APIs
|
Assembly.LoadFrom, Assembly.LoadFile, Assembly.Load(Byte[]) |
Severity
|
Low |
Compat Switch Available
|
No |
|
Description
|
The change is to have Assembly.Load* (LoadFrom, LoadFile, Load(Byte[])) to prefer the (serviced) GAC version of an assembly. This change fixes the loophole in the policy mechanism for dynamic loads that earlier allowed Assembly.Load* to bypass policy. The change enables central servicing in Assembly.Load* scenarios. This change has two components: 1. We will enable policy to be applied on dynamic loads with Assembly.Load*. Assembly.Load* will prefer the serviced version of the assembly in the GAC if policy exists in the GAC that redirects the old version to the serviced version. 2. To enable central servicing of in-place updates, LoadFrom and LoadFile will always prefer the GAC copy of the assembly. This is a special case of (1) above. |
|
User Scenario
|
Anyone not intending to use the serviced version, but the exact version of the assembly by using Assembly.Load* will be affected (they will get the serviced version if policy redirection exists). |
|
Work Around
|
ReflectionOnlyLoad can be used to load a file without policy (Note that bypassing policy is OK for just checking metadata, and not running actual code). |
|
|
Short Description
|
Changed assembly textual identity (display name parsing/generation rules. |
Affected APIs
|
Assembly.Load(String), AssemblyName.AssemblyName, Type.AssemblyQualifiedName, AssemblyName.ToString(), Assembly.ToString(), AssemblyName.FullName, Type.GetType(), AppDomain.AssemblyResolve |
Severity
|
Medium |
Compat Switch Available
|
No |
|
Description
|
Assembly identity parsing will now be stricter, and can fail in a number of conditions that it did not previously. In particular, the following are examples of particular conditions that will cause failures (previously these errors were ignored): 1) Attributes in the assembly identity that are not understood (e.g. "myAssembly, version=1.0.0.0, foo=baz") 2) Empty attributes (e.g. mistyped identities such as:"system,,Version=2.0.3500.0, Culture=neutral, PublicKeyToken=b77a5c561934e089") 3) Attribute values that are not understood. This may occur because of typos, or random text that appear in identity (e.g. 5 part version number instead of 4 part in "myAssembly, version=1.0.0.0.0") 4) Duplicate attributes (e.g. "myAssembly, culture=neutral, culture=en-us") 5) Assembly names containing characters which now must be escaped, including: comma, apostrophe, quote, equals, backslash. APIs that generate or use assembly textual identities (e.g. assembly resolve hook) may now get strings that have certain characters (see #3) now escaped. Any code which compared these strings to the old (unescaped) form, would be broken. |
|
User Scenario
|
This change may cause exceptions to be generated when calling APIs that parse assembly textual identities. This change may also cause the textual identity of an assembly to appear differently than it has previously, which can affect any code which does comparisons on these strings (e.g. resolve hook). Badly authored .MSI files (e.g. MSIAssemblyName table) may now also fail to install. |
|
Work Around
|
There is an environment variable setting that can be set to force the old parsing behavior. This environment variable will be called USE_LEGACY_IDENTITY_FORMAT and when set to 1, will cause Fusion to use the old parsing code. Additionally, there is a registry key setting that also can revert to the old behavior: [HKLM\Software\Microsoft\Fusion!UseLegacyIdentityFormat] (DWORD) When set to 1, the old format parser will be used. |
|