[Bug 30681] Microsoft SQL Server Management Studio Express 2008 installer fails (some .NET assemblies are not updated/patched by .NET service packs containing .msp)

wine-bugs at winehq.org wine-bugs at winehq.org
Tue May 15 15:58:21 CDT 2012


http://bugs.winehq.org/show_bug.cgi?id=30681

Anastasius Focht <focht at gmx.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
                 CC|                            |focht at gmx.net
          Component|-unknown                    |msi
            Summary|Microsoft SQL Server        |Microsoft SQL Server
                   |Management Studio Express   |Management Studio Express
                   |2008 installer fails        |2008 installer fails (some
                   |                            |.NET assemblies are not
                   |                            |updated/patched by .NET
                   |                            |service packs containing
                   |                            |.msp)
     Ever Confirmed|0                           |1

--- Comment #1 from Anastasius Focht <focht at gmx.net> 2012-05-15 15:58:21 CDT ---
Hello,

confirming.
For unattended/silent install you can use:

--- snip ---
$ SQLManagementStudio_x86_ENU.exe /q /FEATURES=SSMS /ACTION=Install
--- snip ---

If you want to see progress, you can replace the /q option with /qs.

This is the culprit in log:

--- snip ---
Method not found: 'Void
System.Xml.Xsl.Xslt.Compiler..ctor(System.Xml.Xsl.XsltSettings, Boolean,
System.String)'.
--- snip ---

The "System.Xml.Xsl.Xslt.Compiler" class ought to live in
"System.Data.SqlXml.dll" assembly.

The assembly info after executing all .NET recipes:

--- snip ---
Location:
Z:\home\focht\.wine\drive_c\windows\assembly\GAC_MSIL\System.Data.SqlXml\2.0.0.0__b77a5c561934e089\System.Data.SqlXml.dll 
Name: System.Data.SqlXml, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089 
Type: Library 

// Assembly System.Data.SqlXml, Version 2.0.0.0

[assembly: AssemblyVersion("2.0.0.0")]
[assembly: AssemblyDescription("System.Data.SqlXml.dll")]
[assembly: AllowPartiallyTrustedCallers]
[assembly: AssemblyDefaultAlias("System.Data.SqlXml.dll")]
[assembly: AssemblyTitle("System.Data.SqlXml.dll")]
[assembly: CLSCompliant(true)]
[assembly: ComVisible(false)]
[assembly:
Debuggable(DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints)]
[assembly: CompilationRelaxations(8)]
[assembly: AssemblyDelaySign(true)]
[assembly: NeutralResourcesLanguage("en-US")]
[assembly: AssemblyCompany("Microsoft Corporation")]
[assembly: Dependency("System.Xml,", LoadHint.Always)]
[assembly: RuntimeCompatibility(WrapNonExceptionThrows=true)]
[assembly: AssemblyKeyFile(@"f:\RTM\Tools\devdiv\EcmaPublicKey.snk")]
[assembly: AssemblyInformationalVersion("2.0.50727.42")]
[assembly: AssemblyProduct("Microsoft\x00ae .NET Framework")]
[assembly: SatelliteContractVersion("2.0.0.0")]
[assembly: InternalsVisibleTo("System.Xml,
PublicKey=00000000000000000400000000000000")]
[assembly: AssemblyFileVersion("2.0.50727.42")]
[assembly: AssemblyCopyright("\x00a9 Microsoft Corporation.  All rights
reserved.")]
[assembly: SecurityPermission(SecurityAction.RequestMinimum,
SkipVerification=true)] 
--- snip ---

Dumping the assembly using .NET reflector reveals it defines this class but
with a different constructor signature:

--- snip ---
public Compiler(XsltSettings settings);

Declaring Type: System.Xml.Xsl.Xslt.Compiler 
Assembly: System.Data.SqlXml, Version=2.0.0.0  
--- snip ---

A typical Microsoft ... although the assembly version remains the same (even
with newest .NET Frameworks) public API/classes were restructured.

At some point the constructor signature changed to
"ctor(System.Xml.Xsl.XsltSettings, Boolean, System.String)" and this what SSMS
imports.

The obvious thing is the very low assembly file version "2.0.50727.42".
This is from original .NET 2.0 Framework.
Almost any other assembly (reference and GAC) has a much higher version - of
course there are several newer .NET Frameworks/Service Packs applied.

Using ORCA to dump the original 2.0 Framework installer .msi gives:

--- snip ---
c:\Windows\Installer\1236.msi (original .NET 2.0 Framework)
--- snip ---

--- snip ---
FL_System_Data_SqlXml_dll_____X86.3643236F_FC70_11D3_A536_0090278A1BB8   
SYS_DATA_SQLXML_DLL_____X86.3643236F_FC70_11D3_A536_0090278A1BB8   
173281|System.Data.SqlXml.dll    716800    2.0.50727.42    1033    17408    295
--- snip ---

Unfortunately ORCA currently crashes under Wine when trying to load a .msp
(patch) file on top of a base .msi file (I remember this worked).

Dumping manually in hex editor gives:

>From .NET 2.0 SP1: NetFX_Core.msp

--- snip ---
173281 System.Data.SqlXml.dll 2.0.50727.1433  1033 
--- snip ---

>From .NET 2.0 SP2: NetFX_Core.msp:

--- snip ---
173281 System.Data.SqlXml.dll 2.0.50727.3053 1033
--- snip ---

So the .NET 2.x service packs definitely patch this assembly.

Tracing .NET 2.0 SP1 install gives:

--- snip ---
0029:Call version.GetFileVersionInfoW(01a8bdd0
L"C:\\windows\\Microsoft.NET\\Framework\\v2.0.50727\\System.Data.SqlXml.dll",00000000,0000078c,026695f8)
ret=7d689ee1 
...
0029:trace:msi:calculate_install_state new L"2.0.50727.1433" old 2.0.50727.42
...
005f:Call version.GetFileVersionInfoW(026321e0
L"C:\\windows\\assembly\\tmp\\2BRZ7GOY\\System.Data.SqlXml.dll",00000000,0000078c,02623938)
ret=7a00706d 
...
005f:Call version.GetFileVersionInfoSizeW(02632418
L"C:\\windows\\assembly\\GAC_MSIL\\System.Data.SqlXml\\2.0.0.0__b77a5c561934e089\\System.Data.SqlXml.dll",028dc920)
ret=7a006ed3 
...
005f:Call KERNEL32.MoveFileW(028dc0cc
L"C:\\windows\\assembly\\GAC_MSIL\\System.Data.SqlXml\\2.0.0.0__b77a5c561934e089",028dc2d8
L"C:\\windows\\assembly\\temp\\M7Q9TCVFYH") ret=7a126499
005f:Ret  KERNEL32.MoveFileW() retval=00000001 ret=7a126499 
...
005f:Call KERNEL32.SetFileAttributesW(028dbea0
L"C:\\windows\\assembly\\temp\\M7Q9TCVFYH\\System.Data.SqlXml.dll",00000080)
ret=7a164ecc
005f:Ret  KERNEL32.SetFileAttributesW() retval=00000001 ret=7a164ecc
005f:Call KERNEL32.DeleteFileW(028dbea0
L"C:\\windows\\assembly\\temp\\M7Q9TCVFYH\\System.Data.SqlXml.dll")
ret=79f9a1ff
005f:Ret  KERNEL32.DeleteFileW() retval=00000001 ret=79f9a1ff 
...
005f:Call KERNEL32.CreateDirectoryW(028dc750
L"C:\\windows\\assembly\\GAC_MSIL\\System.Data.SqlXml",00000000) ret=7a1648cd
005f:Ret  KERNEL32.CreateDirectoryW() retval=00000001 ret=7a1648cd 
...
005f:Call KERNEL32.MoveFileW(02631fd4
L"C:\\windows\\assembly\\tmp\\2BRZ7GOY",028dd3fc
L"C:\\windows\\assembly\\GAC_MSIL\\System.Data.SqlXml\\2.0.0.0__b77a5c561934e089")
ret=7a126499
005f:Ret  KERNEL32.MoveFileW() retval=00000001 ret=7a126499 
...
005f:Call advapi32.RegCreateKeyExW(80000002,026239c8
L"Software\\Microsoft\\Fusion\\References\\System.Data.SqlXml, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089,
processorArchitecture=MSIL\\{2EC93463-B0C3-45E1-8364-327E96AEA856}",00000000,00000000,00000000,00020006,00000000,028dd454,028dd44c)
ret=79ee231d
005f:Ret  advapi32.RegCreateKeyExW() retval=00000000 ret=79ee231d 
...
005f:Call KERNEL32.RemoveDirectoryW(02631fd4
L"C:\\windows\\assembly\\tmp\\2BRZ7GOY") ret=7a1437a8
005f:Ret  KERNEL32.RemoveDirectoryW() retval=00000000 ret=7a1437a8 
...
005f:Call msi.MsiRecordSetStringW(00000001,00000000,0105a3c8 L"05/15/12
00:19:26 DDSet_Status: Assembly '[2]' successfully added to the cache")
ret=0103052d 
...
005f:trace:msi:MSI_ProcessMessage (nil) 0x3a0b01b5 0x39e64ac4 7fdf 10 L"1: 0 2:
C:\\windows\\Microsoft.NET\\Framework\\v2.0.50727\\System.Data.SqlXml.dll 3:
2.0.50727.1433 4: 3 5:  6:  7:  8:  9:  10:  " 
...
--- snip ---

Even if the messages indicate an update - it's still .42 instead of .1433

The reference assembly in
"C:\\windows\\Microsoft.NET\\Framework\\v2.0.50727\\System.Data.SqlXml.dll" and
in GAC are not replaced/patched by newer versions in SP1 installer.

For many other assemblies one can see "cabinet_copy_file" after transforms
applied to replace the target but not for this one (and few others which
probably also suffer from this bug).
Just a guess: maybe this is a problem of Wine msi not supporting patch
ordering/sequencing.

Regards

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.



More information about the wine-bugs mailing list