Sqlclient: System.TypeInitializationException: The type initializer for 'Microsoft.Data.SqlClient.TdsParser' threw an exception.

Created on 23 Sep 2019  Â·  42Comments  Â·  Source: dotnet/SqlClient

Hi, I am encountering an issue while trying to use Microsoft.Data.SqlClient with EF Core v2.2.6. I am using this for Always Encrypted and it implemented based on this comment: https://github.com/dotnet/SqlClient/issues/11#issuecomment-493091283.
My scenario might be a little unique since we have some old code with a custom ORM that is using the old library System.Data.SqlClient. This old code is not using any columns that are encrypted so it is my understanding that nothing needs to change there. EF Core is the only ORM that is reading/updating the encrypted column.

I tested Always Encrypted on my local machine and there were no problems. It was only after the code was merged and deployed to the dev environment did the error below occur. It is important to note that the exception is only thrown when viewing any pages in the application that use EF Core. If the page uses the custom ORM there is no problem. I briefly had the error occur on my local machine but after doing a clean/rebuild in VS the error disappeared. I then went to the server for the dev and deleted everything in the bin folder (hopefully mimicking the clean process) and redeployed but that did not resolve the issue for us.

I did find this issue: https://github.com/dotnet/corefx/issues/30518 but since the server is Windows Server 2016 and System.Data.SqlClient is v4.6.1 I do not believe that the issue is the same even if the exception appears to be similar.

I am not really sure where to go from here.
Info:
App: Asp.Net MVC 5, .Net Framework 4.6.1
EF Core v2.2.6 is in a .Net Standard 2.0 project
SQL Server Enterprise 64 bit 13.0.5426.0
Server: Windows Server 2016 version 1607
``` System.TypeInitializationException: The type initializer for 'Microsoft.Data.SqlClient.TdsParser' threw an exception. ---> System.TypeInitializationException: The type initializer for 'Microsoft.Data.SqlClient.SNILoadHandle' threw an exception. ---> System.TypeInitializationException: The type initializer for 'Microsoft.Data.SqlClient.SNINativeMethodWrapper' threw an exception. ---> System.ComponentModel.Win32Exception: Failed to load C:\inetpub\wwwroot\Simplifyed\bin\x64\SNI.dll at Microsoft.Data.SqlClient.SNINativeMethodWrapper..cctor() in E:\agent1\_work\31\s\src\Microsoft.Data.SqlClient\netfx\src\Microsoft\Data\Interop\SNINativeMethodWrapper.cs:line 66 --- End of inner exception stack trace --- at Microsoft.Data.SqlClient.SNINativeMethodWrapper.SNIInitialize() at Microsoft.Data.SqlClient.SNILoadHandle..ctor() in E:\agent1\_work\31\s\src\Microsoft.Data.SqlClient\netfx\src\Microsoft\Data\SqlClient\TdsParserSafeHandles.cs:line 31 at Microsoft.Data.SqlClient.SNILoadHandle..cctor() in E:\agent1\_work\31\s\src\Microsoft.Data.SqlClient\netfx\src\Microsoft\Data\SqlClient\TdsParserSafeHandles.cs:line 16 --- End of inner exception stack trace --- at Microsoft.Data.SqlClient.TdsParser..cctor() in E:\agent1\_work\31\s\src\Microsoft.Data.SqlClient\netfx\src\Microsoft\Data\SqlClient\TdsParser.cs:line 156 --- End of inner exception stack trace --- at Microsoft.Data.SqlClient.TdsParser..ctor(Boolean MARS, Boolean fAsynchronous) in E:\agent1\_work\31\s\src\Microsoft.Data.SqlClient\netfx\src\Microsoft\Data\SqlClient\TdsParser.cs:line 32 at Microsoft.Data.SqlClient.SqlInternalConnectionTds.LoginNoFailover(ServerInfo serverInfo, String newPassword, SecureString newSecurePassword, Boolean redirectedUserInstance, SqlConnectionString connectionOptions, SqlCredential credential, TimeoutTimer timeout) in E:\agent1\_work\31\s\src\Microsoft.Data.SqlClient\netfx\src\Microsoft\Data\SqlClient\SqlInternalConnectionTds.cs:line 1548 at Microsoft.Data.SqlClient.SqlInternalConnectionTds.OpenLoginEnlist(TimeoutTimer timeout, SqlConnectionString connectionOptions, SqlCredential credential, String newPassword, SecureString newSecurePassword, Boolean redirectedUserInstance) in E:\agent1\_work\31\s\src\Microsoft.Data.SqlClient\netfx\src\Microsoft\Data\SqlClient\SqlInternalConnectionTds.cs:line 1442 at Microsoft.Data.SqlClient.SqlInternalConnectionTds..ctor(DbConnectionPoolIdentity identity, SqlConnectionString connectionOptions, SqlCredential credential, Object providerInfo, String newPassword, SecureString newSecurePassword, Boolean redirectedUserInstance, SqlConnectionString userConnectionOptions, SessionData reconnectSessionData, ServerCertificateValidationCallback serverCallback, ClientCertificateRetrievalCallback clientCallback, DbConnectionPool pool, String accessToken, SqlClientOriginalNetworkAddressInfo originalNetworkAddressInfo, Boolean applyTransientFaultHandling, SqlAuthenticationProviderManager sqlAuthProviderManager) in E:\agent1\_work\31\s\src\Microsoft.Data.SqlClient\netfx\src\Microsoft\Data\SqlClient\SqlInternalConnectionTds.cs:line 425 at Microsoft.Data.SqlClient.SqlConnectionFactory.CreateConnection(DbConnectionOptions options, DbConnectionPoolKey poolKey, Object poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningConnection, DbConnectionOptions userOptions) in E:\agent1\_work\31\s\src\Microsoft.Data.SqlClient\netfx\src\Microsoft\Data\SqlClient\SqlConnectionFactory.cs:line 123 at Microsoft.Data.ProviderBase.DbConnectionFactory.CreatePooledConnection(DbConnectionPool pool, DbConnection owningObject, DbConnectionOptions options, DbConnectionPoolKey poolKey, DbConnectionOptions userOptions) in E:\agent1\_work\31\s\src\Microsoft.Data.SqlClient\netfx\src\Microsoft\Data\ProviderBase\DbConnectionFactory.cs:line 143 at Microsoft.Data.ProviderBase.DbConnectionPool.CreateObject(DbConnection owningObject, DbConnectionOptions userOptions, DbConnectionInternal oldConnection) in E:\agent1\_work\31\s\src\Microsoft.Data.SqlClient\netfx\src\Microsoft\Data\ProviderBase\DbConnectionPool.cs:line 870 at Microsoft.Data.ProviderBase.DbConnectionPool.UserCreateRequest(DbConnection owningObject, DbConnectionOptions userOptions, DbConnectionInternal oldConnection) in E:\agent1\_work\31\s\src\Microsoft.Data.SqlClient\netfx\src\Microsoft\Data\ProviderBase\DbConnectionPool.cs:line 1807 at Microsoft.Data.ProviderBase.DbConnectionPool.TryGetConnection(DbConnection owningObject, UInt32 waitForMultipleObjectsTimeout, Boolean allowCreate, Boolean onlyOneCheckConnection, DbConnectionOptions userOptions, DbConnectionInternal& connection) in E:\agent1\_work\31\s\src\Microsoft.Data.SqlClient\netfx\src\Microsoft\Data\ProviderBase\DbConnectionPool.cs:line 1293 at Microsoft.Data.ProviderBase.DbConnectionPool.TryGetConnection(DbConnection owningObject, TaskCompletionSource1 retry, DbConnectionOptions userOptions, DbConnectionInternal& connection) in E:\agent1_work\31\s\src\Microsoft.Data.SqlClient\netfx\src\Microsoft\Data\ProviderBase\DbConnectionPool.cs:line 1190
at Microsoft.Data.ProviderBase.DbConnectionFactory.TryGetConnection(DbConnection owningConnection, TaskCompletionSource1 retry, DbConnectionOptions userOptions, DbConnectionInternal oldConnection, DbConnectionInternal& connection) in E:\agent1\_work\31\s\src\Microsoft.Data.SqlClient\netfx\src\Microsoft\Data\ProviderBase\DbConnectionFactory.cs:line 302 at Microsoft.Data.ProviderBase.DbConnectionInternal.TryOpenConnectionInternal(DbConnection outerConnection, DbConnectionFactory connectionFactory, TaskCompletionSource1 retry, DbConnectionOptions userOptions) in E:\agent1_work\31\s\src\Microsoft.Data.SqlClient\netfx\src\Microsoft\Data\ProviderBase\DbConnectionInternal.cs:line 683
at Microsoft.Data.SqlClient.SqlConnection.TryOpenInner(TaskCompletionSource1 retry) in E:\agent1\_work\31\s\src\Microsoft.Data.SqlClient\netfx\src\Microsoft\Data\SqlClient\SqlConnection.cs:line 1618 at Microsoft.Data.SqlClient.SqlConnection.TryOpen(TaskCompletionSource1 retry) in E:\agent1_work\31\s\src\Microsoft.Data.SqlClient\netfx\src\Microsoft\Data\SqlClient\SqlConnection.cs:line 1599
at Microsoft.Data.SqlClient.SqlConnection.Open() in E:\agent1_work\31\s\src\Microsoft.Data.SqlClient\netfx\src\Microsoft\Data\SqlClient\SqlConnection.cs:line 1250
at Microsoft.EntityFrameworkCore.Storage.RelationalConnection.OpenDbConnection(Boolean errorsExpected)
at Microsoft.EntityFrameworkCore.Storage.RelationalConnection.Open(Boolean errorsExpected)
at Microsoft.EntityFrameworkCore.Query.Internal.QueryingEnumerable1.Enumerator.BufferlessMoveNext(DbContext _, Boolean buffer) at Microsoft.EntityFrameworkCore.SqlServer.Storage.Internal.SqlServerExecutionStrategy.Execute[TState,TResult](TState state, Func3 operation, Func3 verifySucceeded) at Microsoft.EntityFrameworkCore.Query.Internal.QueryingEnumerable1.Enumerator.MoveNext()
at System.Linq.Enumerable.WhereSelectEnumerableIterator2.MoveNext() at Microsoft.EntityFrameworkCore.Query.Internal.LinqOperatorProvider.<_TrackEntities>d__172.MoveNext()
at Microsoft.EntityFrameworkCore.Query.Internal.LinqOperatorProvider.ExceptionInterceptor1.EnumeratorExceptionInterceptor.MoveNext() at System.Collections.Generic.List1..ctor(IEnumerable1 collection) at System.Linq.Enumerable.ToList[TSource](IEnumerable1 source)
....
`````

Most helpful comment

Sorry it took so long with an update; the missing Microsoft Visual C++ 2015 Redistributable was the issue. Not sure how these kinds of issues are usually handled but it might be useful to list this prerequisite somewhere (NuGet, here?) and a link or set of instructions on how to validate if this package is installed. Anyway, thank you every one for your help with this issue 😄

All 42 comments

The important part is:

Win32Exception: Failed to load C:\__source_code\repo1\Simplified\bin\x86\SNI.dll

So it's trying to load the 32 bit version of sni.dll and it isn't present.

That makes me suspect that you build it on a 64 bit system and then just transferred the files to the other machine. You need to publish the project for an x86 target to get the right native dependency resolved. Give it a try.

Sorry, I took the exception from my local machine. I update my comment to the one from the Dev environment.

Essentially the same thing I'm afraid, the important bit is:

.Win32Exception: Failed to load C:\inetpub\wwwroot\Simplifyed\bin\x64\SNI.dll

I am using Azure DevOps for build and deployment with BuildPlatform set to any cpu. The SNI.dll file exists in both \bin\x64 and \bin\x86 at the IIS site path on the server.

EDIT: I was looking at the file information and it appears that the date modified is 9/23/2019 6:44 PM. The current server time is 9/23/2019 5:19 PM. I remember that modified file times in the future caused an issue when I was testing time zone related changes. Does this sound like a likely culprit?

@THammond9
What is the Microsoft.Data.SqlClient version in use? We had the issue before in previews. Please confirm if the issue occurs with Stable v1.0.19249.1?

If yes, can you wrap up a repro app and provide us to reproduce error? A basic architecture app with just a connection object should be good starting point to look into.

I can confirm that I am using v1.0.19249.1. I will try to repro the error but I am going to have to rewrite my Always Encrypted quires to use ADO.Net before I can work on the repro app.

@THammond9

Curious to know if the timezone issue was the root cause, did you happen to test again in next days?

@cheenamalhotra I don't think that was the issue. When I took a closer look that the server I noticed that all files deployed by Azure DevOps have a modified date in the future, which is likely UTC (I am EST). The site does not seem to have a problem with this for all of the other files so it seems unlikely that this would be the issue for only this library. Unfortunately I had to revert the changes so that dev could move forward, so I am unable to test further at the moment. I am still planning on trying to get a repro app but the earliest I could work on it would be next week.

That makes me suspect that you build it on a 64 bit system and then just transferred the files to the other machine. You need to publish the project for an x86 target to get the right native dependency resolved. Give it a try.

Just to clarify the above, It shouldn't matter whether the app is targeting x86 or x64. When building/deploying a .NET Framework target with a M.D.SqlClient dependency, both x86SNI.dll and x64SNI.dll files should be written to the output path (done by a targets file in the SqlClient NuGet package). This enables Microsoft.Data.SqlClient.dll to support AnyCPU by dynamically loading the appropriate native SNI.dll at runtime.

It looks like SqlClient could do a better job of reporting the underlying error about why it failed to load the dll.

Hi @THammond9

Let us know if you can provide us a repro app for this issue that can inspect further.

Also to add, as per @David-Engel 's comment above, PR #225 has been merged and released in latest driver version 1.1.0-preview1. Please give it a try if you can gather more info on why the SNI.dll is failing to load.

I haven't forgotten about this, just been a little busy. I will try this today with 1.1.0-preview1 and see if there is more information when the exception throws.

Here is the updated exception. Does not seem that much different to me. I verified that the Microsoft.Data.SqlClient.dll was the preview version and that the SNI.dll file exists in both folders. It was deployed with Azure DevOps:

System.TypeInitializationException: The type initializer for 'Microsoft.Data.SqlClient.TdsParser' threw an exception. ---> System.TypeInitializationException: The type initializer for 'Microsoft.Data.SqlClient.SNILoadHandle' threw an exception. ---> System.TypeInitializationException: The type initializer for 'Microsoft.Data.SqlClient.SNINativeMethodWrapper' threw an exception. ---> System.ComponentModel.Win32Exception: Failed to load C:\inetpub\wwwroot\dev2.verityiq.com\bin\x64\SNI.dll ---> System.ComponentModel.Win32Exception: The specified module could not be found
   --- End of inner exception stack trace ---
   at Microsoft.Data.SqlClient.SNINativeMethodWrapper..cctor() in E:\agent1\_work\28\s\src\Microsoft.Data.SqlClient\netfx\src\Microsoft\Data\Interop\SNINativeMethodWrapper.cs:line 67
   --- End of inner exception stack trace ---
   at Microsoft.Data.SqlClient.SNINativeMethodWrapper.SNIInitialize()
   at Microsoft.Data.SqlClient.SNILoadHandle..ctor() in E:\agent1\_work\28\s\src\Microsoft.Data.SqlClient\netfx\src\Microsoft\Data\SqlClient\TdsParserSafeHandles.cs:line 36
   at Microsoft.Data.SqlClient.SNILoadHandle..cctor() in E:\agent1\_work\28\s\src\Microsoft.Data.SqlClient\netfx\src\Microsoft\Data\SqlClient\TdsParserSafeHandles.cs:line 17
   --- End of inner exception stack trace ---
   at Microsoft.Data.SqlClient.TdsParser..cctor() in E:\agent1\_work\28\s\src\Microsoft.Data.SqlClient\netfx\src\Microsoft\Data\SqlClient\TdsParser.cs:line 166
   --- End of inner exception stack trace ---
   at Microsoft.Data.SqlClient.TdsParser..ctor(Boolean MARS, Boolean fAsynchronous) in E:\agent1\_work\28\s\src\Microsoft.Data.SqlClient\netfx\src\Microsoft\Data\SqlClient\TdsParser.cs:line 33
   at Microsoft.Data.SqlClient.SqlInternalConnectionTds.LoginNoFailover(ServerInfo serverInfo, String newPassword, SecureString newSecurePassword, Boolean redirectedUserInstance, SqlConnectionString connectionOptions, SqlCredential credential, TimeoutTimer timeout) in E:\agent1\_work\28\s\src\Microsoft.Data.SqlClient\netfx\src\Microsoft\Data\SqlClient\SqlInternalConnectionTds.cs:line 1743
   at Microsoft.Data.SqlClient.SqlInternalConnectionTds.OpenLoginEnlist(TimeoutTimer timeout, SqlConnectionString connectionOptions, SqlCredential credential, String newPassword, SecureString newSecurePassword, Boolean redirectedUserInstance) in E:\agent1\_work\28\s\src\Microsoft.Data.SqlClient\netfx\src\Microsoft\Data\SqlClient\SqlInternalConnectionTds.cs:line 1628
   at Microsoft.Data.SqlClient.SqlInternalConnectionTds..ctor(DbConnectionPoolIdentity identity, SqlConnectionString connectionOptions, SqlCredential credential, Object providerInfo, String newPassword, SecureString newSecurePassword, Boolean redirectedUserInstance, SqlConnectionString userConnectionOptions, SessionData reconnectSessionData, ServerCertificateValidationCallback serverCallback, ClientCertificateRetrievalCallback clientCallback, DbConnectionPool pool, String accessToken, SqlClientOriginalNetworkAddressInfo originalNetworkAddressInfo, Boolean applyTransientFaultHandling, SqlAuthenticationProviderManager sqlAuthProviderManager) in E:\agent1\_work\28\s\src\Microsoft.Data.SqlClient\netfx\src\Microsoft\Data\SqlClient\SqlInternalConnectionTds.cs:line 465
   at Microsoft.Data.SqlClient.SqlConnectionFactory.CreateConnection(DbConnectionOptions options, DbConnectionPoolKey poolKey, Object poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningConnection, DbConnectionOptions userOptions) in E:\agent1\_work\28\s\src\Microsoft.Data.SqlClient\netfx\src\Microsoft\Data\SqlClient\SqlConnectionFactory.cs:line 145
   at Microsoft.Data.ProviderBase.DbConnectionFactory.CreatePooledConnection(DbConnectionPool pool, DbConnection owningObject, DbConnectionOptions options, DbConnectionPoolKey poolKey, DbConnectionOptions userOptions) in E:\agent1\_work\28\s\src\Microsoft.Data.SqlClient\netfx\src\Microsoft\Data\ProviderBase\DbConnectionFactory.cs:line 167
   at Microsoft.Data.ProviderBase.DbConnectionPool.CreateObject(DbConnection owningObject, DbConnectionOptions userOptions, DbConnectionInternal oldConnection) in E:\agent1\_work\28\s\src\Microsoft.Data.SqlClient\netfx\src\Microsoft\Data\ProviderBase\DbConnectionPool.cs:line 955
   at Microsoft.Data.ProviderBase.DbConnectionPool.UserCreateRequest(DbConnection owningObject, DbConnectionOptions userOptions, DbConnectionInternal oldConnection) in E:\agent1\_work\28\s\src\Microsoft.Data.SqlClient\netfx\src\Microsoft\Data\ProviderBase\DbConnectionPool.cs:line 2024
   at Microsoft.Data.ProviderBase.DbConnectionPool.TryGetConnection(DbConnection owningObject, UInt32 waitForMultipleObjectsTimeout, Boolean allowCreate, Boolean onlyOneCheckConnection, DbConnectionOptions userOptions, DbConnectionInternal& connection) in E:\agent1\_work\28\s\src\Microsoft.Data.SqlClient\netfx\src\Microsoft\Data\ProviderBase\DbConnectionPool.cs:line 1427
   at Microsoft.Data.ProviderBase.DbConnectionPool.TryGetConnection(DbConnection owningObject, TaskCompletionSource`1 retry, DbConnectionOptions userOptions, DbConnectionInternal& connection) in E:\agent1\_work\28\s\src\Microsoft.Data.SqlClient\netfx\src\Microsoft\Data\ProviderBase\DbConnectionPool.cs:line 1309
   at Microsoft.Data.ProviderBase.DbConnectionFactory.TryGetConnection(DbConnection owningConnection, TaskCompletionSource`1 retry, DbConnectionOptions userOptions, DbConnectionInternal oldConnection, DbConnectionInternal& connection) in E:\agent1\_work\28\s\src\Microsoft.Data.SqlClient\netfx\src\Microsoft\Data\ProviderBase\DbConnectionFactory.cs:line 357
   at Microsoft.Data.ProviderBase.DbConnectionInternal.TryOpenConnectionInternal(DbConnection outerConnection, DbConnectionFactory connectionFactory, TaskCompletionSource`1 retry, DbConnectionOptions userOptions) in E:\agent1\_work\28\s\src\Microsoft.Data.SqlClient\netfx\src\Microsoft\Data\ProviderBase\DbConnectionInternal.cs:line 773
   at Microsoft.Data.SqlClient.SqlConnection.TryOpenInner(TaskCompletionSource`1 retry) in E:\agent1\_work\28\s\src\Microsoft.Data.SqlClient\netfx\src\Microsoft\Data\SqlClient\SqlConnection.cs:line 1880
   at Microsoft.Data.SqlClient.SqlConnection.TryOpen(TaskCompletionSource`1 retry) in E:\agent1\_work\28\s\src\Microsoft.Data.SqlClient\netfx\src\Microsoft\Data\SqlClient\SqlConnection.cs:line 1857
   at Microsoft.Data.SqlClient.SqlConnection.Open() in E:\agent1\_work\28\s\src\Microsoft.Data.SqlClient\netfx\src\Microsoft\Data\SqlClient\SqlConnection.cs:line 1425
   at Microsoft.EntityFrameworkCore.Storage.RelationalConnection.OpenDbConnection(Boolean errorsExpected)
   at Microsoft.EntityFrameworkCore.Storage.RelationalConnection.Open(Boolean errorsExpected)
   at Microsoft.EntityFrameworkCore.Query.Internal.QueryingEnumerable`1.Enumerator.BufferlessMoveNext(DbContext _, Boolean buffer)
   at Microsoft.EntityFrameworkCore.SqlServer.Storage.Internal.SqlServerExecutionStrategy.Execute[TState,TResult](TState state, Func`3 operation, Func`3 verifySucceeded)
   at Microsoft.EntityFrameworkCore.Query.Internal.QueryingEnumerable`1.Enumerator.MoveNext()
   at System.Linq.Enumerable.WhereSelectEnumerableIterator`2.MoveNext()
   at Microsoft.EntityFrameworkCore.Query.Internal.LinqOperatorProvider.ExceptionInterceptor`1.EnumeratorExceptionInterceptor.MoveNext()
   at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
   at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)

\bin\x64SNI.dll ---> System.ComponentModel.Win32Exception: The specified module could not be found

This would mean a dependency dll is not found in your OS for SNI.dll to load.
Could you take a look which dependent dll is not available in your host OS of Azure DevOps Server?
Or if the issue is something else!

Dependency list is here:
image

Is there an easy way to locate all of these dlls or do I just search the windows folder for the names? Also does it matter what the location of these dlls are?

Did a search in the windows folder and api-ms-win-crt-* and vcRunTime140.dll are missing

Try installing/fixing Microsoft Visual C++ 2015 Redistributable

I let the network team know to install Microsoft Visual C++ 2015 Redistributable on the server. After it is updated I will try again.

Sorry it took so long with an update; the missing Microsoft Visual C++ 2015 Redistributable was the issue. Not sure how these kinds of issues are usually handled but it might be useful to list this prerequisite somewhere (NuGet, here?) and a link or set of instructions on how to validate if this package is installed. Anyway, thank you every one for your help with this issue 😄

I am getting a very similar issue when running unit tests on our CI server, but the Microsoft Visual C++ 2015 Redistributable solution does not work for me.

Some of the unit test projects have a packagereference to one of our own nuget packages that has a dependency on Microsoft.Data.SqlClient 1.0.19269.1. When these unit tests run they fail with the same TypeInitializationException error. I can see that the bin folder of the unit test project contains Microsoft.Data.SqlClient.dll but the corresponding x86 and x64 sub folders are missing. The CI server has "Microsoft Visual C++ 2015-2019 Redistributable" x86 and x64 versions installed.

The CI server builds the VS Projects with MSBuild. If I log onto the CI Server and manually build the same projects with VS 2019 Community Edition then the x86 and x64 folders are created, and the unit tests run successfully.

Why doesn't MSBuild create the x86/x64 folders whereas VS 2019 does create them?

Thanks in advance.

Hi @corner22

Please provide us detail stack trace for the "TypeInitializationException" you're facing. Also a repro if possible.

Hi @corner22

Please provide us detail stack trace for the "TypeInitializationException" you're facing. Also a repro if possible.

I have resolved the problem. It wasn't an issue with your nuget package. When building with MSBuild, our CI server was using an out-dated version of nuget (4.8.1). After upgrading it to use the latest (5.3.0) then MSBuild correctly built the package.

Sorry to trouble you with this, but hopefully sharing my experience will be useful to others who may get a similar issue.

I'd be interested to know what difference between the versions caused the issue as well.

I am guessing it could be buildTransitive ?

https://docs.microsoft.com/en-us/nuget/release-notes/nuget-5.0-rtm#summary-whats-new-in-50

Looks likely, and in that case the nuspec update would be a good move.

Closing since fix in PR #274 is merged.

Hi everyone, we had to revert the change since NuGet.org gallery does not support <metadata minClientVersion="5.0.0"> at the moment. We've filed a bug #7674 on their end. Additionally, we realized having this change may impact users with older version of Visual Studio / NuGet. Therefore we won't be introducing this change.

We are currently facing the same issue on our azure nodes when upgrading to Microsoft.Data.SqlClient.
We have installed the VC++ Redistributable 2017 but not 2015.
Are the redistributable not backwards compatible?

The api-ms-win-crt files are all missing on our node. The vcruntime140.dll is available in the system32 directory

Are the redistributable not backwards compatible?

No. There is a specific redistributable for each major version of the c++ runtime and you need to have the correct one installed. This only applied on windows. On Linux the implementation is entirely managed code and doesn't require a c++ runtime.

I tried to install the redistributable 2015-2019 now
image

But the error is still occuring

@Poolitzer80

Do you have Nuget.exe version > v5.0 installed on your client machine as shared here: https://github.com/dotnet/SqlClient/issues/211#issuecomment-543087368?

If not, please try upgrading and let us know.

Hi Cheena

Yeah i already saw, that in your bugfix.
We tried already to upgrade our nuget task, but everthing newer than 4.7.1
Does not restore our own repository nuget packages ☹

Do you have an idea what we have to do that the new nuget updater works with our pipeline?

Viele Grüße
Jakob Schönfeld

root-nine GmbH
Eduard-Rüber-Str. 7
83022 Rosenheim
Geschäftsführer: Rupert Maier – Georg Huber
Registergericht Traunstein HRB 26248
Telefon: 08031 / 581797-5
E-Mail: [email protected]info@root-nine.de
Homepage: www.root-nine.dehttp://www.root-nine.de/

Von: Cheena Malhotra notifications@github.com
Gesendet: Freitag, 6. Dezember 2019 16:43
An: dotnet/SqlClient SqlClient@noreply.github.com
Cc: Jakob Schönfeld jakob.schoenfeld@root-nine.de; Mention mention@noreply.github.com
Betreff: Re: [dotnet/SqlClient] System.TypeInitializationException: The type initializer for 'Microsoft.Data.SqlClient.TdsParser' threw an exception. (#211)

@Poolitzer80https://github.com/Poolitzer80

Do you have Nuget.exe version > v5.0 installed on your client machine as shared here: #211 (comment)https://github.com/dotnet/SqlClient/issues/211#issuecomment-543087368?

If not, please try upgrading and let us know.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/dotnet/SqlClient/issues/211?email_source=notifications&email_token=ANDSDHEMGJ4XDWL6DOY3NM3QXJXH7A5CNFSM4IZOOBZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGEPIJY#issuecomment-562623527, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ANDSDHACPZGXXNGDO7BDSA3QXJXH7ANCNFSM4IZOOBZQ.

From NuGet documentation:

NuGet.exe 5.0 and later require .NET Framework 4.7.2 or later to execute.

That might be the source of problem. You could try upgrading to 4.7.2 and investigating packages not being restored.

If you're not willing to upgrade, you can also add Microsoft.Data.SqlClient.SNI NuGet package to your references to load SNI.dll manually.

Thank you! We will try to upgrade to 4.7.2! Have a nice weekend!

Viele Grüße
Jakob Schönfeld

root-nine GmbH
Eduard-Rüber-Str. 7
83022 Rosenheim
Geschäftsführer: Rupert Maier – Georg Huber
Registergericht Traunstein HRB 26248
Telefon: 08031 / 581797-5
E-Mail: [email protected]info@root-nine.de
Homepage: www.root-nine.dehttp://www.root-nine.de/

Von: Cheena Malhotra notifications@github.com
Gesendet: Freitag, 6. Dezember 2019 17:11
An: dotnet/SqlClient SqlClient@noreply.github.com
Cc: Jakob Schönfeld jakob.schoenfeld@root-nine.de; Mention mention@noreply.github.com
Betreff: Re: [dotnet/SqlClient] System.TypeInitializationException: The type initializer for 'Microsoft.Data.SqlClient.TdsParser' threw an exception. (#211)

From NuGet documentationhttps://docs.microsoft.com/en-us/nuget/install-nuget-client-tools#windows:

NuGet.exe 5.0 and later require .NET Framework 4.7.2 or later to execute.

That might be the source of problem. You could try upgrading to 4.7.2 and investigating packages not being restored.

If you're not willing to upgrade, you can also add Microsoft.Data.SqlClient.SNIhttps://www.nuget.org/packages/Microsoft.Data.SqlClient.SNI/ NuGet package to your references to load SNI.dll manually.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/dotnet/SqlClient/issues/211?email_source=notifications&email_token=ANDSDHHIXHJJSMZ5ITDQOTTQXJ2QVA5CNFSM4IZOOBZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGESFDI#issuecomment-562635405, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ANDSDHC3OB3EE2WELAOJY6DQXJ2QVANCNFSM4IZOOBZQ.

Are the redistributable not backwards compatible?

No. There is a specific redistributable for each major version of the c++ runtime and you need to have the correct one installed. This only applied on windows.

@Wraith2 I think this has changed a bit since 2015. From https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads :

Note Visual C++ 2015, 2017 and 2019 all share the same redistributable files.

For example, installing the Visual C++ 2019 redistributable will affect programs built with Visual C++ 2015 and 2017 also. However, installing the Visual C++ 2015 redistributable will not replace the newer versions of the files installed by the Visual C++ 2017 and 2019 redistributables.

This is different from all previous Visual C++ versions, as they each had their own distinct runtime files, not shared with other versions.

@Poolitzer80 The 2017 ones should be correct. But is your application 32-bit? If so, you will need to install the x86 redistributable package (even if you are running it on an x64 system), which will put the libraries in the SysWOW64 folder.

I had this error and it was fixed by updating
image

... to version 4.8.0

When installing, it'll say (in the license box):

image

Hello, I'd tried all options above, and I fixed uninstalling and reinstalling again with dependency behavior Highest using the Options on NuGet.

I'm using:
Net Framework 4.8
C# 7.3
Visual Studio 2019 Updated
ASP.NET App

I make this post because I had this issue last year but I did abandon, today I look for a solution.

JeffersonMotta2020 #TdsParserError

FIX_SYSTEM_DATA_SQLCLIENT

@jssmotta

Could you please upload a sample app to reproduce the issue?

Since the application architectures differ a lot and sometimes other dependencies have role to play, we'd like to know more about your specific use case, before making assumptions. Please open a new ticket with your repro, that would be ideal.

I seem to be having related problems reported here

Seems to be that EF Core 3 uses a different version of Microsoft..Extensions.DependencyInjection.Abstractions than MSTest

We ran into this with a console app that was targeting .NET Framework 4.8. Installing the Microsoft.Data.SqlClient.SNI package manually fixed the problem. The only difference I can see is that NuGet is using 1.1.0 without the explicit reference, and Microsoft.Data.SqlClient.SNI 1.1.1 fixes the problem.

Note: the app runs fine from my machine, but if I build the app and try to run the exe on one of our servers, it throws the TdsParser error unless the SNI package is installed.

The only dependency in my sample app is Microsoft.Data.SqlClient 1.1.2.

Thanks @ryanriv -- that fixed it for me too. I had Microsoft.Data.SqlClient.SNI version 1.1.0 and was getting this error (with Microsoft.Data.SqlClient 1.1.2). I updated the SNI package to 1.1.1 and that fixed the The specified module could not be found error.

the following issue fix it giving execute permission to /x64/SNI.dll. I don´t know if it´s the correct soluction but it worked for me

System.TypeInitializationException: The type initializer for 'Microsoft.Data.SqlClient.TdsParser' threw an exception. ---> System.TypeInitializationException: The type initializer for 'Microsoft.Data.SqlClient.SNILoadHandle' threw an exception. ---> System.TypeInitializationException: The type initializer for 'Microsoft.Data.SqlClient.SNINativeMethodWrapper' threw an exception. ---> System.ComponentModel.Win32Exception: Failed to load C:\websites\wwwroot\bin\x64SNI.dll

Was this page helpful?
0 / 5 - 0 ratings