When I register the assembly System.ServiceModel.dll I get this warning message:
After that I am trying to register Microsoft.Transactions.Bridge.dll and get this warning:
What directory / folder are you trying to pull in those DLLs from? You should only need to create the ServiceModel Assembly. This will require that the Database be set to TRUSTWORTHY ON and that you create the Assembly as UNSAFE.
That being said, you would be better off finding an entirely different approach given that very limited nature of what you are building. SQLCLR is a very restricted environment and does not allow for mixed-mode Assemblies; only pure MSIL Assemblies are allowed. In .NET Framework versions 2.0, 3.0, and 3.5, the ServiceModel library was pure MSIL so importing it did work. However, starting with .NET Framework v 4.0, ServiceModel changed to be a mixed-mode DLL and hence cannot be imported into SQL Server starting with SQL Server 2012 (i.e. the first version of SQL Server to be linked to CLR v 4.0 which uses .NET Framework versions 4.0 through the current 4.7 (I think)). And there is no fix outside of re-writing the code to no longer reference ServiceModel. Please see my answer here for more details on that:
(Unfixable) Assembly exists on SQL Server 2014 but it claims it doesn't have it
Related
How do I change the .NET framework of MS SQL Server 2012?
I have a SSIS package that has a script that cannot target .NET 4.0 due to using WebUtility.UrlEncode().
Will upgrading to 4.5 on the Server interfere with other stored procedures that are currently running (and targeting 4.0)?
I tried setting the target of the Script Task to 4.0 but WebUtility.UrlEncode isnt available for 4.0.
Two things at play here.
The first is the target setting for the SSIS Script Task/Component. You can change that up/down as the item requires.
That's a development setting by the way. When you deploy to the server, would need to ensure that server itself has an equivalent runtime on it.
Now, things get "weird" because for the 4.0 runtime framework, which we both have, there are developer versions within that version, from a Command Prompt if you typed
C:\Windows\Microsoft.NET\Framework\v4.0.30319\csc.exe you'd see what version there. For example, I see
Microsoft (R) Visual C# Compiler version 4.8.4084.0 for C# 5
How do I find the .NET version?
I am attempting to build a SQL CLR project in Visual Studio 2015 and I am calling a wcf service which targets the System.Runtime.Serialization.dll. I am having problems identifying the correct version of .NET to target in order to overcome this.
The sql version is:
name value
directory C:\Windows\Microsoft.NET\Framework64\v4.0.30319\
version v4.0.30319
state CLR is initialized
I attempted to build the CLR against .NET version 4.
SQL refuses to install System.Runtime.Serialization.dll If I build against .NET version 3.5, I get
Msg 6586, Level 16, State 1, Line 8
Assembly 'System.Runtime.Serialization' could not be installed because existing policy would keep it from being used.
What version should I build against to overcome this?
SQL Server 2012 and newer uses CLR 4.0, which in turn is tied to .NET Framework versions 4.0 and above. You cannot use any .NET 2.0, 3.0, or 3.5 libraries in SQL Server 2012 or newer.
System.Runtime.Serialization is not in the Supported .NET Framework Libraries list, so you need to load it manually, and as UNSAFE. However, if that DLL is mixed mode and not pure MSIL, then it won't load since SQL Server's CLR host only works with pure MSIL libraries. I have found it best to just use HttpWebRequest and build the request XML manually and parse the response XML manually.
In the past, the ServiceModel DLL, and all of its dependencies, were pure MSIL and worked in SQL Server 2008 R2 (SQL Server 2005, 2008, and 2008 R2 are tied to CLR 2.0). But then, in CLR version 4.0, Microsoft added some dependencies to ServiceModel. One of them was the new Microsoft.VisualBasic.Activities.Compiler library (not a direct dependency, but via another, most likely Microsoft.Transactions.Bridge), which happens to contain unmanaged code (which cannot be loaded into SQL Server). Hence, everyone who had working WebService SQLCLR stuff running in 2008 R2 had it stop working upon upgrading to SQL Server 2012 or newer. Using HttpWebRequest works with an "approved" library that is guaranteed to always works across upgrades of the .NET Framework.
There are numerous questions already on here regarding these issues. I will try to find some and update this with a few of them.
Also, just FYI, the output shown in the question, which appears to be the results of executing: SELECT * FROM sys.dm_clr_properties;. Please be aware that the "version" shown, while often referred to as the Framework version, is actually just the CLR version, and those two things are not the same thing.
I have a DLL which uses .NET Framework v2.0. and I want to add it to SQL Server 2012 using CREATE ASSEMBLY. But SQL Server 2012 uses .NET Framework v.4.0.
Is it possible to add a .NET Framework v2.0 assembly to SQL Server 2012?
Well, it depends. The question title and question text imply two different questions.
If the question is about a .NET Framework DLL:
No. SQL Server 2012 and 2014 are statically linked to only CLR version 4.0 (meaning .NET Framework versions starting at 4.0 through at least 4.5.2 if not also 4.6 if that has been released). Hence it is not possible to load any Framework DLL that is part of CLR 2.0 (i.e. Framework versions 2.0, 3.0, and 3.5) into SQL Server 2012 or 2014.
However, everything should be backwards compatible and should work just the same if you try to load the CLR 4.0 (i.e. Framework versions 4.0, 4.5, 4.5.1, etc) version of the same Framework DLL. The only reason why this wouldn't work is if the DLL in question, or one of its dependencies, changed to become a mixed-mode DLL in one of the Framework updates that was released after the version that you have been using. The problem in that case would be that SQL Server only supports pure MSIL DLLs.
If the question is about a DLL that you created:
Again, as long as it is not a mixed-mode DLL, everything should be backwards compatible and should work just the same.
If loading the DLL errors with:
Assembly "{AssemblyName}" was built using version vX.Y.ZZZZ of the .NET Framework. SQL Server currently uses version v4.0.30319
then you can probably re-link it to 4.0. Please see my answer to "Cannot register stdole assembly in SQL Server 2012" for an example of doing this.
FYI, I wrote an article that explains the CLR / Framework versions issue in detail: Stairway to SQLCLR Level 5: Development (Using .NET within SQL Server) (free registration required).
I have a Winform App that we uses internally that I publish through ClickOnce with SQL Express 2005. The app also references a couple of Microsoft.SqlServer dll's. I am trying to figure out how the Specific Version settings work. I have SQL 2008 installed on my machine they have 2005.
If I select Specific Version = false will it care that the users have SQL 2005 or does that depend on the dll.
Specifically, If I do not specify Specific Version does that mean it will just look in the GAC for any version of that dll?
"Specific Version" is only relevant when you compile, it has no effect at runtime. When set to False, the IDE won't complain when the [AssemblyVersion] of the reference assembly has changed. Which is not that great an idea, you ought to be aware of the changes you might have to make in your code because the assembly changed.
The CLR will not look for any version of an assembly in the GAC. Only a exact match is accepted. That's the default policy, you can override it with a <bindingRedirect> in the app's .config file.
Afaik, there isn't a provider for SQL Server that's specific to the SQL Server version number. Not quite sure about that.
Someone at MSFT who's related to the SQLExpress product told me today that it's so hard to figure out if it's installed already, they have a program that does it that's part of the bootstrapper package in Visual Studio. (I was ragging him about how difficult it is to install SQLServer.)
Writing code in a .NET application to connect to and use a SQLServer database is not version-specific, and Microsoft is committed to maintaining backward compatibility.
It appears out of the box the v1 of Microsoft Sync Framework would only support synching with a CE db, using the SqlCeClientSyncProvider. I can't find anywhere in the documentation about v2 if we can now sync between two SQL Server databases. Anyone know of hand if this is now possible (without writing my own client provider)?
The following provider is the one that you should be using to sync with a SQL Server database.
Microsoft.Synchronization.Data.Server.DbServerSyncProvider
The Local Database Cache tool could get you up and running fairly quickly without having to worry about these details - you would however be sacrificing some flexibility.
You don't necessarily need Sync Framework 2.0 if you do decide that you want to get a little closer to the metal but it has now been released and is probably your best bet. Just be careful with the DLL versions that you swap into your solution after installing the SDK. Note below that the database DLLs are not versioned consistently with the rest of the framework and that the version of the Microsoft.Synchronization.Data.SqlServerCe DLL actually decreases from 3.5 to 3.0.
Installing Sync Framework - MSDN
All database provider DLLs have a
version number of 3.0 rather than 2.0
because some of the providers were
originally released before Sync
Framework 1.0.
Microsoft.Synchronization.Data.SqlServerCe.dll
was originally released as part of SQL
Server Compact and previously had a
version number of 3.5 to match the SQL
Server Compact version. The version of
this DLL is now 3.0 to match the other
database providers.