Copy local on implicit references?


(JohnMoshakis) #41

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.


(marc hoffman) #42

Ok, but we had all that sorted? What changed? Can I get a new testcase? thanx!


(JohnMoshakis) #43

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


(marc hoffman) #44

image

Didn’t we determine that CopyLocal for that reference is what causes the issue?


(marc hoffman) #45

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)


(RemObjects) #46

Thanks, logged as bugs://81666: EBuild: .NET Core: additional “runtime” entries needed for SQLClient.dll


(JohnMoshakis) #47

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.


(marc hoffman) #48

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.


(JohnMoshakis) #49

As its a reference on the exe, how it the copy local still a problem ?


(marc hoffman) #50

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.


(JohnMoshakis) #51

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 ?


(marc hoffman) #52

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.


(JohnMoshakis) #53

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.


(marc hoffman) #54

I’m sorry, I cannot follow what the problem is.


(JohnMoshakis) #55

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


(marc hoffman) #56

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.


(JohnMoshakis) #57

Is there any news on this bug ?


(marc hoffman) #58

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.


(JohnMoshakis) #59

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.


(marc hoffman) #60

81666 is fixed yes. thats the extra entries. So what’s the current problem you’re having?