Add-Microsoft-Data-SqlClient-dll-2-1-2-as-an-assembly-reference

Hello,

https://www.wealth-lab.com/Discussion/Assembly-References-MySql-DLLs-which-worked-in-6-9-aren-t-recognized-5530

Meet our website's power tool - the search box! :)

Of course, I've extracted Microsoft.Data.SqlClient.dll from the NuGet package under 2.1.2\lib\netcoreapp3.1 and in the assembly reference System.ComponentModel.Primitives and System.Data.Common were selected by myself.

So I don't see any differences to the MySql issue you've mentioned.

OK. Have you cleared the flag "Downloaded from the internet" from the file before placing it to the WL7 folder?

https://www.howtogeek.com/70012/what-causes-the-file-downloaded-from-the-internet-warning-and-how-can-i-easily-remove-it/

Yes, the flag "File Downloaded from the Internet" has never existed on the DLL.
In VS 2019, the namespace Microsoft.Data.* is available, in WL7B6 not?

Please use MySqlConnector as suggested because it works and MySql.Data.MySqlClient does not:

https://www.wealth-lab.com/Discussion/Assembly-References-MySql-DLLs-which-worked-in-6-9-aren-t-recognized-5530

Really?

The MySqlConnector is an ADO.NET data provider for MySQL Server, MariaDB, Percona Server, Amazon Aurora, Azure Database for MySQL, Google Cloud SQL for MySQL.

However, I use SQL Server Analysis Services to analyze my data using cubes...

I stand corrected, of course MySql != MS.SqlClient. Let me take a closer look.

Can you use the "classic" System.Data.SqlClient? This compiles (predictably):

CODE:
using System.Data.SqlClient;

https://docs.microsoft.com/en-us/dotnet/api/system.data.sqlclient?view=netcore-3.1

Well, it is not that simple :-)

If you first copy sni.dll into the WL7 directory, then you can use the classic "before .Net Core" way. However, this "classic way" in combination with .Net Core is associated with some side-effects, especially when running the WL7 backtester against a list of stocks.

Here are two side-effects (...and there will be more to come as .Net Core includes a special hardening as well):

If you establish the database connection in the BacktestBegin() event and the Close in the Cleanup() event, you'll run into the following WL7 generated error:



If you place the database connection and the Close into the Execute() event then the WL7 backtester runs into an endless loop without generating an error:




Without question, it would make sense to use Microsoft.Data.SqlClient.dll which is the official way since .Net Core!

I see. Like some missing assembly reference prevents loading the .NET Core assembly.

Still, you're better off leveraging the power of Visual Studio's debugger to peek inside these issues on your screenshots rather than using WriteToDebugLog:

https://www.wealth-lab.com/Support/ExtensionApi/StrategyLibrary
https://www.wealth-lab.com/Discussion/New-instruction-for-using-Visual-Studio-to-develop-and-debug-strategies-5494

Figured out the issue. As always, a construtor which is set to null because (in WL7 - not in QS), it's in the wrong event handler.

Just moved from QS to WL7. Will look into the VS integration later this year. So far the WriteToDebugLog() as a debugger worked quite well, even if it's a bit cumbersome. Anyway, thanks for the tip.

So were you able to load the library?

Yes. it looks like. Haven't done a major run yet but at first glance the result is positive.

Anyway, I have now a mixed solution between .Net Core and .Net Framework libraries, which is certainly not a good idea.



This is, what you'll get if you try to mix up different librararies from different .Net generations. So you have to build some kind of bridge:

Unable to load DLL 'sni.dll' or one of its dependencies: (0x8007007E)
at System.Data.SqlClient.SNINativeMethodWrapper.UnmanagedIsTokenRestricted(IntPtr token, Boolean& isRestricted)
at System.Data.Win32NativeMethods.IsTokenRestrictedWrapper(IntPtr token)
at System.Data.ProviderBase.DbConnectionPoolIdentity.GetCurrentNative()
at System.Data.ProviderBase.DbConnectionPoolIdentity.GetCurrent()

If .NET Core 3.x is used as a base for WL7 then there should never be an issue when API extensions (based on .NET Core 3.x) must be used. .NET Core 3.x onwards the new SqlClient library "Microsoft.Data.SqlClient" is used and it is certainly not the same as before since sni.dll is referenced from an "external package".

Therefore, it would be useful if Dion could have a look on this.

Another side effect of using the old System.Data.SqlClient.dll instead of the new Microsoft.Data.SqlClient.dll is the selection of the Namespace System.Private.CoreLibs (which is required by System.Data.SqlClient.dll). Afterwards, the WL7 Code window can't recognize certain Namespaces. Most of the code is underlined in red.



Would be great to fix this soon so that the library Microsoft.Data.SqlClient.dll can be used to write data into an MS SQL database...

In WL7 Build 8, the reference to Microsoft.Data.SqlClient.dll is still NOT recognized!
Is there a possibility that this problem will be fixed soon?

Yes, for Build 9.