I think there is still a problem with referencing system.data.sqlclient inside a .net core console app. With elements its results in a PlatformNotSupported Exception whereas with visual studio for mac I can open a connection to a database.
Ok, but we had all that sorted? What changed? Can I get a new testcase? thanx!
mono using a standard library, which referenced sqclient was sorted but not core with sqlclient.
SimpleDataConsoleApplication.zip (190.2 KB)
CSharpDataConsoleApplication.zip (487.4 KB)
I can dotnet run the charpconsole and it will run without exceptions.
The other one fails with PlatformNotSupported.
Cheers,
John
Didnât we determine that CopyLocal for that reference is what causes the issue?
Without Copy Local, I doin get a file out found, which is odd, bt I determined it needs additional entries in the .deps.json for those.nI need to look into how to fix that, but not for todayâs build, sorry :(.
Attached is the good vs bad .deps.json so yo can see whats missingâŚ
SimpleDataConsoleApplication.deps-bad-as-generated.json (4.3 KB)
SimpleDataConsoleApplication.deps-good.json (8.0 KB)
Thanks, logged as bugs://81666: EBuild: .NET Core: additional âruntimeâ entries needed for SQLClient.dll
Thanks.
Copy local is only a problem when you reference a standard library. In that case all the references in the standard library should be turned off.
No, CopyLocal is still the problem here. itâll copy the subbed-out reference next to the exe, and try to use that at runtime.
As its a reference on the exe, how it the copy local still a problem ?
I dont understand the question. The reference resolves to the stubbed-out version of the dll from the NuGet packageâs /lib folder. that version of the dll is not usable at runtime. By making the reference Copy Local, this âbadâ version of the .dll will be copied next to the exe, and used at runtime.
The proof is in the pudding, as you get the âplatform to supportedâ exception. If you change the reference to NOT be Copy-Local, that goes away.
I didnt realize the code would work without the assembly present. Mind you if I provide a proper connection string it says the sqlclient assembly is missing. How strange.
How does it build without having the references local ?
Does copy local differentiate between build time and run time assemblies ?
It uses the dll provided by the system.
No. Copy Local just determines whether the .dll you reference and build against gets copied along with the exe, or not. It needs (well, should) to be set for non-system .dlls that you need to deploy with your app, and it must not be set for system .dlls that you donât want to deploy yourself but expect to be present on the target system.
System.Data.SqlClient is the latter.
Should it be using the System dll ? I feel like this is complicated by the fact that the classes also exist in a framework assembly. For a web application running windows I had copy local on and copied the System.Data.SqlClient assembly to the application folder.
I did a dotnet publish CSharpDataConsoleApplication.csproj, screenshot below
Isnt this what I should be getting from Fire ? It has runtimes folder, System.Data.SqlClient and the additional referenced files.
I tried copying those files into my Fire project and it didnt make a difference. I was wondering if there is additional content missing from the config files ?
The other thing I dont understand is why dotnet run CSharpDataConsoleApplication.csproj also works. I presume that uses the netcoreapp2.2 folder but that doesnt contain the same files as the publish folder.
Iâm sorry, I cannot follow what the problem is.
I think that I should be using System.Data.SqlClient from nuget and I think the Debug folder from Fire should be the same as the one from dotnet publish
Yes, you should, and it should not be set to Copy Local.
I donât know what the one from dotnet publish looks like, it it should contain only your .exe, the deps.json and .runtimeconfig.json, as well as any nonsystem .dlls you have referenced (eg Echoes.dll or Elements.dll).
At the rest of repeating myself, the âNot Supported on this Platformâ error comes because youâre copy-locating the SqlClient dll from the NuGet package, when you shouldnât.
Is there any news on this bug ?
Not beyond that Iâve explained 3 time snow that Copy Local is the problem, and the references needs to be set no NOT copy local, and then the error goes away.
Or are you seeing a different problem without copy local now? if so, I must have missed the details and Iâd appreciate a fresh test case and description of the current state of the problem youâre seeing.
As a side node, 2361 has improvements to the generated .deps.json file mentioned earlier in the thread, but thatâs orthogonal to this.
Sorry I didnât mean to keep asking, I just wanted to help get to the bottom of the problem.
The issue is that Im not able to connect to a database. It builds but I cant connect. I was asking about 81666 mentioned earlier in the thread.
81666 is fixed yes. thats the extra entries. So whatâs the current problem youâre having?