How to resolve failed assembly verification when installing assembly into SQL Server - c#

I need to do SFTP from within a SQL Server context. I can do FTP with MS libraries, but they do not support SFTP.
So I downloaded Rebex, and put together a sample project, and tried to install it into SQL Server as a CLR stored procedure.
When doing this, SQL Server gives the following message:
Msg 6218, Level 16, State 2, Line 3
CREATE ASSEMBLY for assembly 'RebexTest' failed because assembly 'Rebex.Common' failed verification. Check if the referenced assemblies are up-to-date and trusted (for external_access or unsafe) to execute in the database. CLR Verifier error messages if any will follow this message
[ : Rebex.Security.Certificates.CertificateStore::Exists][mdToken=0x60003b0]
[offset 0x000000C7] Method is not visible.
Is there a way to fix this so I can install it into SQL Server?

Unfortunately, Rebex components can only be used in CLR procedures with the PERMISSION_SET = UNSAFE option. See detailed explanation on the Rebex support forum.

Related

SQL Server 2017: Failed To Create Assembly. Check if referenced assemblies are up-to-date and trusted

I found this same issue in my research, but no solution was found: Research Link
This .dll is System.net.http, and it is pulled from the 4.6.1 .NET Framework. I am trying to create an assembly out of it in SQL Server 2017.
I've done the following steps:
Create a certificate (THIS TELLS ME WARNING: Certificate is expired)
Create a login
Grant unsafe assembly
Also set the database I'm running this on to TRUSTWORTHY
Set CLR security to 0, tried installing assembly (failed)
This is the code I'm executing:
CREATE CERTIFICATE [MS.NETcer]
FROM EXECUTABLE FILE =
'C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\System.net.http.dll';
CREATE LOGIN [MS.NETcer] FROM CERTIFICATE [MS.NETcer];
GRANT UNSAFE ASSEMBLY TO [MS.NETcer];
create ASSEMBLY [System.Net.Http]
FROM 'C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\System.net.http.dll'
WITH PERMISSION_SET = UNSAFE
This is my issue:
Msg 6218, Level 16, State 2, Line 15
CREATE ASSEMBLY for assembly 'System.Net.Http' failed because assembly 'System.Net.Http' failed verification. Check if the referenced assemblies are up-to-date and trusted (for external_access or unsafe) to execute in the database. CLR Verifier error messages if any will follow this message
[ : System.Net.Http.SR::.ctor][mdToken=0x6000001][offset 0x00000000] Code size is zero.
[ : System.Net.Http.SR::get_ResourceManager][mdToken=0x6000002][offset 0x00000000] Code size is zero.
[ : System.Net.Http.SR::get_Culture][mdToken=0x6000003][offset 0x00000000] Code size is zero.
[ : System.Net.Http.SR::set_Culture][mdToken=0x6000004][offset 0x00000000] Code size is zero.
[ : System.Net.Http.SR::get_net_http_argument_empty_string][mdToken=0x6000005][offset 0x00000000] Code size is zero.
[ : System.Net.Http.SR::get_net_http_client_absolute_baseaddress_required][mdToken=0x6000006][offset 0x00000000] Code size is zero.
[ : System.Net.Http.SR::get_net_http_client_content_headers][mdToken=0x6000007][offset 0x00000000] Code size is zero.
[ : System.Net.Http.SR::get_net_http_client_execution_error][mdToken=0x6000008][offset 0x00000000] Code size is zero.
[ : System.Net.Http.SR::get_net_http_client_http_baseaddress_required][mdToken=0x6000009][offset 0x00000000] Code size is zero.
[ : System.Net.Http.SR::get_net_http_client_invalid_requesturi][mdToken=0x600000a][offset 0x00000000] Code size is zero.
[ : System.Net.Http.SR::get_net_http_client_request_already_sent][mdToken=0x600000b][offset 0x00000000] Code size is zero.
[ : System.Net.Http.SR::get_net_http_client_request_headers][mdToken=0x600000c][offset 0x00000000] Code size is zero.
[ : System.Net.Http.SR::get_net_http_client_response_headers][mdToken=0x600000d][offset 0x00000000] Code size is zero.
[ : System.Net.Http.SR::get_net_http_client_send_canceled][mdToken=0x600000e][offset 0x00000000] Code size is zero.
[ : System.Net.Http.SR::get_net_http_client_send_completed][mdToken=0x600000f][offset 0x00000000] Code size is zero.
[ : System.Net.Http.SR::get_net...
Edit 1: If I use the .dll from the 4.7.2 framework instead, I get the following error:
Msg 6586, Level 16, State 1, Line 18
Assembly 'System.Net.Http' could not be installed because existing policy would keep it from being used.
Edit 2: If I follow the advice below and pull the .dll (instead of from the reference folders) from C:\Windows\Microsoft.NET\Framework64\v4.0.30319, I get this problem instead.
Msg 6522, Level 16, State 1, Procedure DataRobot.pDataUpload, Line 0 [Batch Start Line 47]
A .NET Framework error occurred during execution of user-defined routine or aggregate "pDataUpload":
System.IO.FileLoadException: Could not load file or assembly 'System.Net.Http, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. Assembly in host store has a different signature than assembly in GAC. (Exception from HRESULT: 0x80131050) See Microsoft Knowledge Base article 949080 for more information.
System.IO.FileLoadException:
at DataRobot.DataUpload.Upload(String directory, String proxyAddress, String apiToken)
Edit 3: Following up #Solomon to provide additional context. I build my project on my work computer. The SQL Server is hosted on a different server. The .NET libraries I use are on my local C:\ drive. These are the facts so far:
I compile my project as a .dll to a SQL Server shared drive
I copy and paste the System.net.http.dll library to the same SQL Server shared drive.
I add the System.net.http.dll as a certificate. Database is also set to TRUSTWORTHY.
I create assemblies and stored procedure to run the methods in my compiled project .dll.
You are probably pointing to a reference assembly and not the actual assembly with the actual code in it (hence the "Code size is zero." error message).
If you are using SQL Server 2012 or newer, then the following does work (and does not require setting the DB to TRUSTWORTHY ON, so turn TRUSTWORTHY back to OFF):
USE [master];
CREATE CERTIFICATE [MS.NETcer]
FROM EXECUTABLE FILE =
'C:\Windows\Microsoft.NET\Framework64\v4.0.30319\System.Net.Http.dll';
CREATE LOGIN [MS.NETcer] FROM CERTIFICATE [MS.NETcer];
GRANT UNSAFE ASSEMBLY TO [MS.NETcer];
USE [SomeUserDB];
CREATE ASSEMBLY [System.Net.Http]
FROM 'C:\Windows\Microsoft.NET\Framework64\v4.0.30319\System.Net.Http.dll'
WITH PERMISSION_SET = UNSAFE;
Regarding Edit:
If I use the .dll from the 4.7.2 framework instead, I get the following error:
Do not try to use a specific .NET Framework version of a .NET Framework library. You need to use what is currently on the server running SQL Server since the version that SQL Server is using must match the version that the OS is using. So, for system assemblies it is best to pull from disk (i.e. C:\Windows\Microsoft.NET\Framework64\v4.0.30319\ ).
Regard Edit 2:
If I follow the advice and pull the .dll from C:\Windows\Microsoft.NET\Framework64\v4.0.30319, I get this problem instead.
Assembly in host store has a different signature than assembly in GAC.
Hmm. I would think the GAC would get its version from that same directory. Is it possible that there was a Windows Update that updated the version on disk and the GAC hasn't been refreshed yet? Or something like that? Can you rebooting the server and then try loading the assembly again?
Regarding Edit 3:
I copy and paste the System.net.http.dll library to the same SQL Server shared drive.
No, no, no. Do not copy/paste any .NET Framework DLL. You need to use the version that is on the same server as SQL Server. This is why you need to execute the statements that I provided above (i.e. CREATE ASSEMBLY [System.Net.Http] FROM 'C:\Windows\Microsoft.NET\Framework64\... ). It doesn't matter if you compile your project against .NET 4.5.2 and the server hosting SQL Server has .NET 4.8 installed. Just load the .NET Framework DLL from the server running SQL Server, then load your DLL. The only time a version difference matters between what you compile against and what SQL Server is using (based on the server it's running on) is if you are developing on a machine with a newer version of .NET Framework that has a new feature not found in the version being used by SQL Server. And in that case (which is rare to happen), you simply need to update the version of .NET Framework on the server running SQL Server.

SQL Server and Visual Studio: how to cope with different Microsoft.SqlServer.Types versions

In Visual Studio (2019) I've made an assembly that is using Microsoft.SqlServer.Types, and I compiled it without error messages.
Now I try to import this assembly into my SQL Server (2019) database with T-SQL, but this message appears:
Msg 10300, Level 16, State 2, Line 1 Assembly "MyAssembly" references assembly 'microsoft.sqlserver.types, version=15.100.0.0,
culture=neutral, publickeytoken=89845dcd8080cc91.', which is not
present in the current database. SQL Server attempted to locate and
automatically load the referenced assembly from the same location
where referring assembly came from, but that operation has failed
(reason: another assembly with same SQL name is already present in the
current database). Please load the referenced assembly into the
current database and retry your request.
In SSMS (18.5.1) I see that the microsoft.sqlserver.types that SQL Server is using has a different version: 15.0.0.0.
If I try to remove this from SQL Server before importing the 15.100.0.0 version I get a message saying that deleting is not possible because it is a system assembly.
What is the best I can do now? I am brand new to this stuff.

Could not load file or assembly 'Microsoft.SqlServer.BatchParser

Currently we moved our Web Applications to a new server so now we have a Database and Web + App Server. Before moving everything was working fine.
But now as we have installed SQL Server on the DB Server we are getting errors related to:
Microsoft.SqlServer DLL files.
So basically the code runs a script on the DB server to create a New Database.
First I was getting the Error, related to: Microsoft.SqlServer.ConnectionInfo.dll
So I installed, the nuget Package: Shared Management Objects
Which seemed to have fix the Problem.
BUT now I am getting an error related to Microsoft.SqlServer.BatchParser
I followed the links online and they suggest to install:
Shared Management Objects from here; https://www.microsoft.com/en-pk/download/confirmation.aspx?id=29065
Note; we are using SQL server 2012 standard.
So I installed Shared Management Objects and also restarted the server, but I am still getting the same error.
Could not load file or assembly 'Microsoft.SqlServer.BatchParser, Version=11.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' or one of its dependencies. The system cannot find the file specified.
If I navigate to: C:\Windows\assembly I can see that Microsoft.SqlServer.BatchParser:
The Exception occurs on this line of code:
server.ConnectionContext.ExecuteNonQuery(script);

ADOMD Connection Error

I am receiving the following error from ADOMD while trying to connect to my SSAS Server.
An unhandled exception of type 'System.Xml.XmlException' occurred in
Microsoft.AnalysisServices.AdomdClient.dll
Additional information: Element 'return' was not found. Line 5,
position 2.
I can confirm the following:
My Connection String Is:
Data Source=<MyServer>;Catalog=<My SSAS DB>; UID=<MyDomain>\<MyDomainUser>;PWD=<MyPassword>;
I can confirm that my connection string is correct ( or at least the data I am using in the connection string above is correct). If I change any part of the connection string to an incorrect value the ADOMDConnection will return "Cannot connect to server". I have also looked at the audit logs on the server itself and confirm that I am successfully logging onto the server. And the contrary, with incorrect credentials the server logs confirm a failed login.
I am trying to connect to SSAS 2014 Enterprise
The failed connection returns within a few seconds. A few posts out on the internet suggest increasing the Connection Timeout property. This does not seem to be my issue as I have increased it to 120 and its failing within 5.
I am using ADOMD 12.0 Runtime 2.0.50727
My domain user is a domain admin and has been added to an admin role in the SSAS.
Im not sure what else could be wrong or how to debug this or is this a known bug in ADOMD?
Any advice would greatly appreciated.
thanks!
Jason
This happens routinely when the version of the ADOMD client DLL is not a version that matches the target version of the server instance. For example, Azure Analysis Services as of 09/13/2017 does not work with Microsoft.AnalysisServices.AdomdClient.dll version 13. Only version 14 and above.
For reference, the ADOMD DLL for Azure Analysis Service is available in the link below:
https://learn.microsoft.com/en-us/azure/analysis-services/analysis-services-data-providers
Double check to make sure the client DLL is the exact version needed for the target server instance. That solved this exact issue in my case.

Can't get sql server compact 3.5 / 4 to work with ASP .NET MVC 2

I'm using Visual Studio 2008 Pro.
I'm probably missing something very obvious here, but I've been trying to get the CTP for Sql Server compact 4 to work in my asp.net mvc application. I can find next to no instruction on how to set this up or a working example application. My goal is a private install so I can just include it in my web app without having to do sql server setup on my domain hosting. This is really just me shooting the breeze and trying to figure this out. I don't plan to host a market or anything with this.
So, I've copied all the dll's that install in the base 4.0 direction (c:\Program Files\Sql Server compact\v4.0) to a lib folder in my application. I've set the copy to output direction option to 'Copy if Newer'. I then reference the System.Data.SqlServerCE dll and set 'Copy Local' to True.
I created an sdf file via Sql Studio Express. An important note is that I did not see an option for creating a CE 4.0 version of this file, so it was created using CE 3.5. I create a few tables, add a few rows to those tables, copy the *.sdf file to my App_Data directory. It's worth mentioning that, from inside VS 2008, this file never appears in my project, but it does exist in the physical location of the App_Data directory. I'm not sure why this is.
Next, I just try making a basic connection to my sdf file via:
SqlCeConnection conn = new SqlCeConnection("DataSource=rpg.sdf");
This yields the error below:
Unable to load the native components of SQL Server Compact corresponding to the ADO.NET provider of version 8402. Install the correct version of SQL Server Compact. Refer to KB article 974247 for more details.
I figure from here, I'd just try getting Sql CE 3.5 to work. I upgrade my local installation of Sql CE 3.5 to sp2. I copy the dlls at the base location (c:\Program Files\Sql Server compact\v3.5), including removing and readding the version of the System.Data.SqlServerCE dll from my project references.
The curious thing here is when I right click and look at the properties of the referenced SqlServerCE dll, it always says it's version 4.0.0.1.
Guys, I really could use some direction here. I have searched stack overflow, the help docs, books online, and googled. I really haven't found anything that takes this from the very top for either CE 3.5 or 4.0 and tells me exactly what dll's to add, where to put them, how to reference them, how to add the .sdf file to my project, connect to it, and query from it. I did come across a few mentions of an IBuySpy portal sample app that was supposed to use Sql CE 3.5, but can't actually navigate the msdn download maze to get to it. Ideally, I want to setup a private deploy for CE 4.0.
I'm all ears. Suggestions, points, whatever would be highly appreciated. Thank you!
YES I DID SEE THE KB. IT DIDN'T HELP
See it here: http://support.microsoft.com/kb/974247
RESULTS FROM CORFLAG
Okay, tried that and these are my results:
C:\Development\Mvc2MessingAround\Mvc2MessingAround\bin\Lib>corflags System.Data.
SqlServerCe.dll
Microsoft (R) .NET Framework CorFlags Conversion Tool. Version 3.5.21022.8
Copyright (c) Microsoft Corporation. All rights reserved.
Version : v2.0.50727
CLR Header: 2.5
PE : PE32
CorFlags : 9
ILONLY : 1
32BIT : 0
Signed : 1
I would have sworn I installed the x86 version of both versions of Sql CE (3.5/4). The installer might have gotten confused somehow because my processor is 64bit capable, but i'm running Windows xp sp 3 32 bit. The results seem to indicate it's 64 bit. Is that the case?
ADDED DETAILS
To date the configurations below have been tried on 2 machines. Both are Windows xp sp3 32 bit with a 64 bit capable processor. The development environment on both is VS 2008 Pro. The results on machine 2 come after a fresh install of the Sql CE 4 Ctp.
CONFIGURATION #1
myapp\bin\
System.Data.SqlServerCe.dll
myapp\bin\private
amd64
x86
myapp\bin\private\x86
sqlceca40.dll
sqlcecompact40.dll
sqlceer40EN.dll
sqlceme40.dll
sqlceqp40.dll
sqlcese40.dll
myapp\bin\private\amd64
sqlceca40.dll
sqlcecompact40.dll
sqlceer40EN.dll
sqlceme40.dll
sqlceqp40.dll
sqlcese40.dll
Error:
An exception of type 'System.Data.SqlServerCe.SqlCeException' occurred in System.Data.SqlServerCe.DLL but was not handled in user code
Additional information: Unable to load the native components of SQL Server Compact corresponding to the ADO.NET provider of version 8402. Install the correct version of SQL Server Compact. Refer to KB article 974247 for more details.
Code:
SqlCeConnection conn = new SqlCeConnection();
CONFIGURATION 2
Same as #1, but with System.Data.SqlServerCE.Entity.dll at myapp\bin direction.
The page errors before hitting the code above. This is the message:
Could not load file or assembly 'System.Data.SqlServerCe.Entity' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.BadImageFormatException: Could not load file or assembly 'System.Data.SqlServerCe.Entity' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.
I've checked the project settings in VS 2008 Pro and the .Net 3.5 framework is set as the target.
CONFIGURATION 3
Same as #1, except the System.Data.SqlServerCE.dll is referenced from the myapp\bin\private folder.
Results are the same as CONFIGURATION #1 (error message is 100% same and the error occurrs on the same line of code).
CORRECT CONFIGURATION
Per Erik's instructions (had I followed them more carefully), the setup should be
myapp\bin
x86
amd64
System.Data.SqlServerCE.dll
Reference the System.Data.SqlServerCE.dll directly from the bin folder for the code. My folly was thinking the Private folder needed to be included, but it doesn't. Do not put the System.Data.SqlServerCE.Entity.dll in the bin folder unless you are using a .net 4.0 solution. I don't think that dll works w/ 3.5.
Helpful link:
Link
SQL CE 3.5 does not work with ASP.NET, you must use 4.0 CTP.
Download from here.
Install the runtime.
Copy the following directory contents (including the x86 and amd64 folders) to the bin folder of your ASP.NET app:
C:\Program Files\Microsoft SQL Server Compact Edition\v4.0\Private
UPDATE: Use System.Data.SqlServerCe.dll from the Desktop folder to avoid Medium Trust issues
myapp\bin\
System.Data.SqlServerCe.dll
myapp\bin\x86
sqlceca40.dll
sqlcecompact40.dll
sqlceer40EN.dll
sqlceme40.dll
sqlceqp40.dll
sqlcese40.dll
myapp\bin\amd64
sqlceca40.dll
sqlcecompact40.dll
sqlceer40EN.dll
sqlceme40.dll
sqlceqp40.dll
sqlcese40.dll
Add a reference to the System.Data.SqlServerCe.dll file you just put in your /bin folder.
Place the SQL Compact sdf file in your App_Data folder.
Add connection string:
<connectionStrings>
<add name ="NorthWind"
connectionString="data source=|DataDirectory|\Nw40.sdf" />
</connectionStrings>
Connect! :-)
using System.Data.SqlServerCe;
protected void Page_Load(object sender, EventArgs e)
{
using (SqlCeConnection conn = new SqlCeConnection())
{
conn.ConnectionString = ConfigurationManager.ConnectionStrings["Northwind"].ConnectionString;
conn.Open();
using (SqlCeCommand cmd = new SqlCeCommand("SELECT TOP (1) [Category Name] FROM Categories", conn))
{
string valueFromDb = (string)cmd.ExecuteScalar();
Response.Write(string.Format("{0} Time {1}", valueFromDb, DateTime.Now.ToLongTimeString()));
}
}
}
If your using a connection string that uses a providerName and you haven't installed the SDK, then you also need to add this to you web.config (or app.config)
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.Data.SqlServerCe" publicKeyToken="89845dcd8080cc91" culture="neutral"/>
<bindingRedirect oldVersion="4.0.0.0-4.0.0.1" newVersion="4.0.0.1"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
<system.data>
<DbProviderFactories>
<remove invariant="System.Data.SqlServerCe.4.0"/>
<add name="Microsoft SQL Server Compact Data Provider 4.0" invariant="System.Data.SqlServerCe.4.0" description=".NET Framework Data Provider for Microsoft SQL Server Compact" type="System.Data.SqlServerCe.SqlCeProviderFactory, System.Data.SqlServerCe, Version=4.0.0.1, Culture=neutral, PublicKeyToken=89845dcd8080cc91"/>
</DbProviderFactories>
</system.data>
NOTE: the "remove" is needed in case you installed the SDK, as that will put this info in your machine.config
OK, here's a guess, since you're fishing for them.
Run corflags.exe on the assembly you copied to your references directory. What type of machine are you building for? If you're on a 64-bit machine and you're compiling to x64 or anyCpu, make sure that corflags tells you that your references are not 32-bit only references. Maybe it's "falling back" to an the wrong version in your GAC or something. If it tells you that the referenced assembly is 32-bit only, either compile your project as a 32-bit project or find a 64-bit version of the DLL?
If you are installing the SQL CE provider using NuGet, the simplest solution is to add a post-build step to copy these from the NuGet package NativeBinaries folder
The key for me was realizing that the version of System.Data.SqlServerCe.Entity.dll in the Private directory (C:\Program Files\Microsoft SQL Server Compact Edition\v4.0\Private) is 4.0.0.1, where the version beneath the Desktop directory (C:\Program Files\Microsoft SQL Server Compact Edition\v4.0\Desktop\System.Data.SqlServerCe.Entity) is 4.0.0.0. The version of System.Data.SqlServerCe.dll in the Private directory is 4.0.0.0.
I think it was a mistake on the part of Microsoft to distribute an updated SqlServerCe.Entity.dll without a corresponding update to SqlServer.dll.
I build an asp.net web api and hosted it on azure and faced some issues with sql server compact I fix it by:
first remove all system.data.sqlserverce.dll and any dll use it then
installed these tow packages :
Install-Package SqlServerCompact then rebuild
Install-Package EntityFramework.SqlServerCompact -Version 4.3.6 then rebuild
after I did it just worked fine for me + install any NuGet package that depends on system.data.sqlserverce.dll they all just work great
I hope this will help some one
reference

Categories

Resources