On a 64-bit platform: C:\Program Files (x86)\Microsoft SQL Server\90\SDK\Assemblies C:\Program Files (x86)\Microsoft SQL Server\100\SDK\Assemblies
On a 32-bit platform: C:\Program Files\Microsoft SQL Server\90\SDK\Assemblies C:\Program Files\Microsoft SQL Server\100\SDK\Assemblies
Microsoft.SqlServer.Dts.Design.dll Microsoft.SQLServer.ManagedDTS.dll Microsoft.SqlServer.ScriptTask.dll Microsoft.SqlServer.SQLTask.dll Microsoft.SqlServer.TxScript.dll Microsoft.SqlServer.VSTAScriptingLib.dll
The build of the .Net application may report the following Warnings in the Error List pane:
The primary reference "Microsoft.SqlServer.Dts.Design, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL" could not be resolved because it has an indirect dependency on the .NET Framework assembly "mscorlib, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" which has a higher version "2.0.3600.0" than the version "2.0.0.0" in the current target framework. The primary reference "Microsoft.SQLServer.ManagedDTS, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL" could not be resolved because it has an indirect dependency on the .NET Framework assembly "mscorlib, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" which has a higher version "2.0.3600.0" than the version "2.0.0.0" in the current target framework. The primary reference "Microsoft.SqlServer.ScriptTask, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL" could not be resolved because it has an indirect dependency on the .NET Framework assembly "mscorlib, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" which has a higher version "2.0.3600.0" than the version "2.0.0.0" in the current target framework. The primary reference "Microsoft.SqlServer.SQLTask, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=x86" could not be resolved because it has an indirect dependency on the .NET Framework assembly "mscorlib, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" which has a higher version "2.0.3600.0" than the version "2.0.0.0" in the current target framework. The primary reference "Microsoft.SqlServer.TxScript, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL" could not be resolved because it has an indirect dependency on the .NET Framework assembly "mscorlib, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" which has a higher version "2.0.3600.0" than the version "2.0.0.0" in the current target framework. The primary reference "Microsoft.SqlServer.VSTAScriptingLib, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL" could not be resolved because it has an indirect dependency on the .NET Framework assembly "mscorlib, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" which has a higher version "2.0.3600.0" than the version "2.0.0.0" in the current target framework. WindowsFormsApplication1
The primary reference "Microsoft.SqlServer.Dts.Design, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL" could not be resolved because it has an indirect dependency on the .NET Framework assembly "mscorlib, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" which has a higher version "2.0.3600.0" than the version "2.0.0.0" in the current target framework.
The primary reference "Microsoft.SQLServer.ManagedDTS, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL" could not be resolved because it has an indirect dependency on the .NET Framework assembly "mscorlib, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" which has a higher version "2.0.3600.0" than the version "2.0.0.0" in the current target framework.
The primary reference "Microsoft.SqlServer.ScriptTask, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL" could not be resolved because it has an indirect dependency on the .NET Framework assembly "mscorlib, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" which has a higher version "2.0.3600.0" than the version "2.0.0.0" in the current target framework.
The primary reference "Microsoft.SqlServer.SQLTask, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=x86" could not be resolved because it has an indirect dependency on the .NET Framework assembly "mscorlib, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" which has a higher version "2.0.3600.0" than the version "2.0.0.0" in the current target framework.
The primary reference "Microsoft.SqlServer.TxScript, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL" could not be resolved because it has an indirect dependency on the .NET Framework assembly "mscorlib, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" which has a higher version "2.0.3600.0" than the version "2.0.0.0" in the current target framework.
The primary reference "Microsoft.SqlServer.VSTAScriptingLib, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL" could not be resolved because it has an indirect dependency on the .NET Framework assembly "mscorlib, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" which has a higher version "2.0.3600.0" than the version "2.0.0.0" in the current target framework. WindowsFormsApplication1
This problem affects machines where SQL Server 2005 was once installed. Even if SQL Server 2008 or SQL Server 2008 R2 is currently installed, if at some point SQL Server 2005 was installed in the past, the problem assembly may exist in the Globally Assembly Cache (GAC).
The problem is related to the way the aforementioned assemblies reference the SQL Server 2005 version of Microsoft.SQLServer.msxml6_interop.dll. That msxml_interop assembly in turn references mscorlib.dll that is version 2.0.3600, which is the prerelease Beta 2 of .NET 2.0.
SSIS uses the MSXML6 interop assembly for SSIS managed components and tasks for serialization (when calling LoadFromXML). Other places that use MSXML6 explicitely for the lookup GUI and SQL Task in SSIS.
Visual Studio 2010 warns about references to that beta build of the 2.0 .Net core library, and the warning appears during the build action.
What’s really interesting is that the SQL Server 2008 copy of Microsoft.SQLServer.msxml6_interop.dll does not have this problem, but people still have this problem after SQL Server 2008 is installed. The twist is if you install SQL Server 2008 on a machine where SQL Server 2005 is currently or previously installed, the problem file does not get upgraded during setup to the corrected version of the file because its already in the GAC, and it has the same version 6.0.0.0 (since the version didn’t change between 2005 and 2008).
My Setup logs confirm this behavior:
C:\Program Files\Microsoft SQL Server\100\Setup Bootstrap\Log\<date> Sql_bids_Cpu64_1.log MSI (s) (10:A4) [16:04:43:963]: Verifying accessibility of file: Microsoft.SqlServer.msxml6_interop.dll sql_engine_core_shared_Cpu64_1.log MSI (s) (10:7C) [15:46:57:096]: Verifying accessibility of file: Microsoft.SqlServer.msxml6_interop.dll sql_is_Cpu64_1.log MSI (s) (10:B8) [15:55:32:658]: Verifying accessibility of file: Microsoft.SqlServer.msxml6_interop.dll sql_ssms_Cpu64_1.log MSI (s) (10:10) [15:56:31:406]: Verifying accessibility of file: Microsoft.SqlServer.msxml6_interop.dll Sql_tools_Cpu64_1.log MSI (s) (10:B0) [15:58:21:572]: Verifying accessibility of file: Microsoft.SqlServer.msxml6_interop.dll
C:\Program Files\Microsoft SQL Server\100\Setup Bootstrap\Log\<date> Sql_bids_Cpu64_1.log MSI (s) (10:A4) [16:04:43:963]: Verifying accessibility of file: Microsoft.SqlServer.msxml6_interop.dll
sql_engine_core_shared_Cpu64_1.log MSI (s) (10:7C) [15:46:57:096]: Verifying accessibility of file: Microsoft.SqlServer.msxml6_interop.dll
sql_is_Cpu64_1.log MSI (s) (10:B8) [15:55:32:658]: Verifying accessibility of file: Microsoft.SqlServer.msxml6_interop.dll
sql_ssms_Cpu64_1.log MSI (s) (10:10) [15:56:31:406]: Verifying accessibility of file: Microsoft.SqlServer.msxml6_interop.dll
Sql_tools_Cpu64_1.log MSI (s) (10:B0) [15:58:21:572]: Verifying accessibility of file: Microsoft.SqlServer.msxml6_interop.dll
Therefore due to this twist, you may also have the problem if SQL Server 2008 is presently installed on the same machine as Visual Studio 2010, if SQL Server 2005 was ever installed on the same machine.
What’s inside the Culprit File that causes this problem?
Open it in .Net Reflector to see the dependencies… the rogue reference to mscorlib.dll that is version 2.0.3600, which is the prerelease Beta 2 of .NET 2.0!
For comparison, the SQL 2008 file from 100\DTS\Binn doesn’t have this rogue dependency. v 2.0.0.0 is the corrected RTM of .Net framework 2.0 as shown below:
Update the version of the Microsoft.SQLServer.msxml6_interop.dll in the GAC with a copy of the file from SQL Server 2008 installation that has the correct references to .Net 2.0 RTM (ie. get rid of the beta reference).
Install a copy of the single SQL Server 2008 file Microsoft.SQLServer.msxml6_interop.dll into the GAC on the machine where Visual Studio 2010 is used to build the solutions.
On Windows Vista, Windows 7, Windows 2008 and WIndows 2008 R2, the GAC can be seen in folder C:\Windows\Assembly. You may drag and drop the file Microsoft.SQLServer.msxml6_interop.dll into the GAC folder C:\Windows\Assembly.
Easier said than done!
Problem 1: One complication is that you may receive the following error on some operating systems when assemblies in the GAC are protected by UAC. Problem 2: Because this file is installed by the SQL installer (Microsoft Installer) it is locked by windows so you cannot remove the old version from the GAC until you remove the registry value associated with it. Therefore you must manually edit the registry to unprotect this file. Access is denied: 'Microsoft.SqlServer.msxml6_interop.dll'.
Problem 1: One complication is that you may receive the following error on some operating systems when assemblies in the GAC are protected by UAC.
Problem 2: Because this file is installed by the SQL installer (Microsoft Installer) it is locked by windows so you cannot remove the old version from the GAC until you remove the registry value associated with it. Therefore you must manually edit the registry to unprotect this file.
Access is denied: 'Microsoft.SqlServer.msxml6_interop.dll'.
Let me know if you have problems with these, so I may correct any mistakes…
Locate the following key and value:
Temporarily rename the registry value name (left column in rightmost pane) by adding an underscore '_' in front of the name.
Example: _Microsoft.SqlServer.Msxml6_interop,fileVersion="6.0.0.0",version="6.0.0.0",culture="neutral",publicKeyToken="89845DCD8080CC91",processorArchitecture="MSIL" After rename…
Example: _Microsoft.SqlServer.Msxml6_interop,fileVersion="6.0.0.0",version="6.0.0.0",culture="neutral",publicKeyToken="89845DCD8080CC91",processorArchitecture="MSIL"
After rename…
A. Review the output from dir. If you only have one .dll file in the dir output, proceed to the next step 3, skipping step 2B.
B. Review the output from dir. If and only if you have two copies of Microsoft.SQLServer.msxml6_interop.dll in the GAC then you can remove the oldest one from the GAC. If you have more than one copy of this file in the GAC and if the "Last Modified" date of the file is before year 2006 (it should be dated in 2005).
{
Note: Both the good and bad copy of the file have the same version number 6.0.0.0, so version alone is not a good indicator of which file can be used to workaround the problem. Then… Manually remove the SQL 2005 version of Microsoft.SqlServer.msxml6_interop.dll from the GAC. There are 3 possible approaches: ALTERNATIVES (don’t need to do all of these) i. Right click on the assembly in the C:\Windows\Assembly folder to remove it, or use the gacutil command line utility that ships with the SDK. This fails with Access Denied on UAC enabled machines though :-( ii. Gacutil command line tool from an UAC elevated command prompt. Locate the Gacutil.exe utility in one of the Microsoft SDK folders… You can use the Visual Studio command prompt to easily find gacutil. Start > Programs > Microsoft Visual Studio 2010 > Visual Studio Tools > Visual Studio Command Prompt (2010). Make sure to run as Administrator (UAC nag) Run this command to uninstall the extra copy from the GAC Gacutil /uf Microsoft.SQLServer.msxml6_interop If needed, you can manually find the GACUtil in folders such as C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\x64 or C:\Program Files (x86)\Microsoft Visual Studio 8\SDK\v2.0\Bin iii. Only if Gacutil fails… brute force delete of the assembly from the GAC. From an elevated command prompt, delete the MSIL folder that contains the problem assembly as follows: rmdir C:\WINDOWS\assembly\GAC_MSIL\Microsoft.Sqlserver.msxml6_interop\6.0.0.0__89845dcd8080cc91\ /s
Note: Both the good and bad copy of the file have the same version number 6.0.0.0, so version alone is not a good indicator of which file can be used to workaround the problem.
Then… Manually remove the SQL 2005 version of Microsoft.SqlServer.msxml6_interop.dll from the GAC. There are 3 possible approaches:
ALTERNATIVES (don’t need to do all of these)
i. Right click on the assembly in the C:\Windows\Assembly folder to remove it, or use the gacutil command line utility that ships with the SDK. This fails with Access Denied on UAC enabled machines though :-(
ii. Gacutil command line tool from an UAC elevated command prompt. Locate the Gacutil.exe utility in one of the Microsoft SDK folders…
You can use the Visual Studio command prompt to easily find gacutil. Start > Programs > Microsoft Visual Studio 2010 > Visual Studio Tools > Visual Studio Command Prompt (2010). Make sure to run as Administrator (UAC nag)
Run this command to uninstall the extra copy from the GAC Gacutil /uf Microsoft.SQLServer.msxml6_interop
If needed, you can manually find the GACUtil in folders such as C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\x64 or C:\Program Files (x86)\Microsoft Visual Studio 8\SDK\v2.0\Bin
iii. Only if Gacutil fails… brute force delete of the assembly from the GAC. From an elevated command prompt, delete the MSIL folder that contains the problem assembly as follows: rmdir C:\WINDOWS\assembly\GAC_MSIL\Microsoft.Sqlserver.msxml6_interop\6.0.0.0__89845dcd8080cc91\ /s
}
On a 32-bit machine check the folder: "C:\Program Files\Microsoft SQL Server\100\DTS\Binn\Microsoft.SqlServer.msxml6_interop.dll" On a 64-bit machine check the folder: "C:\Program Files (x86)\Microsoft SQL Server\100\DTS\Binn\Microsoft.SqlServer.msxml6_interop.dll" You have to find the good one under 100\DTS\Binn. The file from 90\DTS\Binn is the bad one. Note: this file does not get installed if SQL Server 2005 was already installed on the machine at the time when SQL Server 2008 was installed. Therefore, you may only find this file if you have a separate machine where SQL Server 2008 is installed without SQL Server 2005 having been present.
On a 32-bit machine check the folder: "C:\Program Files\Microsoft SQL Server\100\DTS\Binn\Microsoft.SqlServer.msxml6_interop.dll" On a 64-bit machine check the folder: "C:\Program Files (x86)\Microsoft SQL Server\100\DTS\Binn\Microsoft.SqlServer.msxml6_interop.dll"
You have to find the good one under 100\DTS\Binn. The file from 90\DTS\Binn is the bad one.
Note: this file does not get installed if SQL Server 2005 was already installed on the machine at the time when SQL Server 2008 was installed. Therefore, you may only find this file if you have a separate machine where SQL Server 2008 is installed without SQL Server 2005 having been present.
Install the new Microsoft.SqlServer.msxml6_interop.dll from SQL2008 using the GacUtil.exe utility. You can drag and drop the file into C:\Windows\Assembly on some OSes, but I get an Access denied error, so I have to use GACUtil. Finding Gacutil is always too difficult… you can use the Visual Studio command prompt to easily find gacutil. Start > Run > Microsoft Visual Studio 2010 > Visual Studio Tools > Visual Studio Command Prompt (2010). Alternatively you can manually locate the Gacutil.exe utility in one of the Microsoft SDK folders, such as: C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\x64 or C:\Program Files (x86)\Microsoft Visual Studio 8\SDK\v2.0\Bin Run the Installation of the 2008 assembly: Gacutil /i "C:\Program Files (x86)\Microsoft SQL Server\100\DTS\Binn\Microsoft.SqlServer.msxml6_interop.dll" The successful output is "Assembly successfully added to the cache"
Install the new Microsoft.SqlServer.msxml6_interop.dll from SQL2008 using the GacUtil.exe utility.
You can drag and drop the file into C:\Windows\Assembly on some OSes, but I get an Access denied error, so I have to use GACUtil.
Finding Gacutil is always too difficult… you can use the Visual Studio command prompt to easily find gacutil.
Start > Run > Microsoft Visual Studio 2010 > Visual Studio Tools > Visual Studio Command Prompt (2010).
Alternatively you can manually locate the Gacutil.exe utility in one of the Microsoft SDK folders, such as: C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\x64 or C:\Program Files (x86)\Microsoft Visual Studio 8\SDK\v2.0\Bin
Run the Installation of the 2008 assembly:
Gacutil /i "C:\Program Files (x86)\Microsoft SQL Server\100\DTS\Binn\Microsoft.SqlServer.msxml6_interop.dll"
The successful output is "Assembly successfully added to the cache"
Open the Registry Editor:
Remove the temporary underscore '_' that was added in front of the name.
Many thanks! Spent most of yesterday trying to sort this out, so very happy to find your solution. n.b. On my "good" install the dll wasn't in ...\100\DTS\Binn, so I copied it out of the GAC instead.
Thank you! Your workaround made my day! My situation was slightly different: I had a Visual Studio 2008 project targeting .NET 3.5 which referenced a SSIS 2005 dll (Microsoft.SQLServer.ManagedDTS.dll version 9.0.242.0) and I have never installed SQL 2008. Migrating to Visual Studio 2010, I initially made it target the .NET 4.0 framework, but then decided to undo this change and the project wouldn't compile anymore. I used the DLL linked in connect.microsoft.com/.../cannot-build-project-in-2010-when-project-has-reference-to-ssis-2008-dlls-sqltask-manageddts-etc as the "good" one
I'm a seasoned *nix programmer, but a mere babe in the MS world. This article has just saved me a LOT of time. Now I just need to find a machine with the 'good' 2008 DLL on it, as all of ours, so far as I can tell, were upgraded from 2005 and therefore don't have the DLL in the 100/Binn folder. Thanks
I solved the problem (for SQL Server 2005) by building my project against .Net version 4 instead of 2.
Hi,
I've the latest version of Microsoft.SqlServer.Msxml6_interop dated 29/11/2010 18:17:26. it still doesn't work. Can you please help?
My scenarios is same as building against .net3.5 in vs2010. If I change it to .net4, it works. But I can't change it due to business requirements. The Microsoft.SqlServerManagedDts version is 10.0.0.0 dated 10.06/12/2010 08:17:06.
If you don't have a clean installation of SQL 2008, and can't spare a machine to make a new one, you can also use the SQL 2008 installation utility to get a fresh copy of Microsoft.SqlServer.msxml6_interop.dll
You need to do the first two steps Jason outlines above to get rid of the existing 2005 copy of Microsoft.SqlServer.msxml6_interop.dll. Then run the installation tool in repair mode (select "Maintenance", then "Repair"). When the tool prompts you for an instance, just select "shared features only" so it doesn't take too long. The repair tool won't find an old copy of msxml6_interop.dll, so it will put a new (non-beta) copy into the GAC. It will also put back the registry entry to protect the file, so you don't have to restore the registry keys either (I deleted the one renamed in Step 1 once I verified everything was working)
Everything compiled cleanly after that. HTH