I'm working on a data provider extension which uses Microsoft.Data.SQLClient.dll. Database connectivity is established without issue and the extension works fine. However, I had to add Microsoft.Data.SQLClient.SNI.dll to the WL install location which I'm pretty sure is not a good idea. The below error is returned in the UI.
nuget says this is an "internal implementation package".
When I omit this dll, my connection open call fails.
Below are all of the dlls I've added to the WL location. None are blocked due to internet download. All except SNI.dll are set up as references in my project.
Below is a discussion that has been very helpful, but it does not seem like this was an issue. Could be due to a prior version the SQLClient dll being used.
https://www.wealth-lab.com/Discussion/Add-Microsoft-Data-SqlClient-dll-2-1-2-as-an-assembly-reference-5780
Any idea what I'm doing wrong here? Any help is greatly appreciated.
nuget says this is an "internal implementation package".
When I omit this dll, my connection open call fails.
Below are all of the dlls I've added to the WL location. None are blocked due to internet download. All except SNI.dll are set up as references in my project.
Below is a discussion that has been very helpful, but it does not seem like this was an issue. Could be due to a prior version the SQLClient dll being used.
https://www.wealth-lab.com/Discussion/Add-Microsoft-Data-SqlClient-dll-2-1-2-as-an-assembly-reference-5780
Any idea what I'm doing wrong here? Any help is greatly appreciated.
Rename
I didn't try this, but maybe ditch using .NET Framework and use .NET Core. See https://stackoverflow.com/questions/43825626/how-to-connect-to-sql-server-from-net-core-without-using-entity-framework#43825757
Thanks @paul1986. My project targets .Net8. The linked article suggests using System.Data.SQLClient (legacy method). I'm using Microsoft.Data.SQLClient. Since WL is using .net8, I'm pretty sure Microsoft.Data.SQLClient is the right library to use, and the connection does work. But, WL is loading all dll's found in the install location and the Microsoft.Data.SQLClient.SNI.dll is not intended to have direct references. I might try reverting to an earlier version of the SQLClient to see if that make any difference.
This is normal.
There are some DLLs, that are required by extensions and need to be present in WL's main folder.
WL's TypeLoader checks all DLLs in this folder for extensions: Indicators, Broker Adapters, Data Providers, ScoreCards and so forth.
If there is a non-standard or non-.Net DLL it issues an (otherwise harmless) error message.
You could ask glitch to add some code to the TypeLoader to make it ignore these DLLs.
I did this before with DLLs required by the finantic extensions, which had the same problem.
There are some DLLs, that are required by extensions and need to be present in WL's main folder.
WL's TypeLoader checks all DLLs in this folder for extensions: Indicators, Broker Adapters, Data Providers, ScoreCards and so forth.
If there is a non-standard or non-.Net DLL it issues an (otherwise harmless) error message.
You could ask glitch to add some code to the TypeLoader to make it ignore these DLLs.
I did this before with DLLs required by the finantic extensions, which had the same problem.
Thank you so much @DrKoch. That makes a lot more sense.
@Glitch - please see the above. I'd like to offer the SQL Server data provider as an extension. If possible, please ignore or do not attempt to load System.Data.SQLClient.SNI.dll so that we don't present a warning in the UI.
@Glitch - please see the above. I'd like to offer the SQL Server data provider as an extension. If possible, please ignore or do not attempt to load System.Data.SQLClient.SNI.dll so that we don't present a warning in the UI.
Aren’t these native dlls typically found in one of the folders under the runtime folder? But yes I can add that dll to the exclusion list. And I’ll get back to you via email about offering this as a third party extension, will be a useful addition!
Yes. The Microsoft.Data.SQLClient.SNI.dll is under the runtime folder. In my case, it is under nuget/runtime.
But you're copying it into the WL8 installation folder? If not, I don't see how WL8 would process that file during startup because it wouldn't find it.
Yes, I'm copying it into the WL8 folder. Prior to copying the dll into the WL8 folder I was getting an error message saying that this dll could not be found.
QUOTE:
I'm copying it into the WL8 folder.
And that is the correct way to go...
Your Response
Post
Edit Post
Login is required