Copy local on implicit references?


(marc hoffman) #21

even without copy-local on the SqlClient (and a Clean to get rid of the old copy!)? that works for me.


(JohnMoshakis) #22

Did you remove the System.Data.SqlClient nuget ? I think adding it to a standard library was a mistake.


(marc hoffman) #23

No. I just made it not copy local. that way, the “bad” .NET Standard version does not get copied next to the .dll, and also not next to the .exe, and at runtime the Mono version of the dll gets loaded. Scenario 4, which is the testcase you sent me, runs for me with that fix (it now fails on “empty connection string” or something like that, ofc.

Remember to do a Clean (or Rebuild) immediately after you change copy-local. Else the old .dll will stick around forever until you delete it manually.

is probably the exact same issue as 4.

this one sounds like a separate bug, since when you build for .NET Core, it should resolve the right version. Can you send me a testcase for this one, and.or can you check which copy of the SqlLite .dll gets copied? (check the Generated Files for 'NetConsoleApplication' target 'Echoes': section, with Diagnostic logging, for the actual path.)

thanx!


(JohnMoshakis) #24

DataAcessStandardClassLibrary 2.zip (1.3 MB)

CoreConsoleApplication is the core console
CoreStandardConsoleApp is the core one that references the standard library
DataAccessStandardClassLibary is the standard library
MonoConsoleApplication is the mono console
NetConsoleAPplication is the mono one that uses the library.

I think based on this

https://apisof.net/catalog/System.Data.SqlClient.SqlConnection

I shouldnt need the nuget in the standard library and mono versions I removed it.

MonoConsoleApplication is the only one that complains about the connection, others say the platform isnt supported.


(JohnMoshakis) #25

actually it has

.NET Standard + Platform Extensions 1.6 System.Data.SqlClient, Version=4.1.0.0, PublicKeyToken=b03f5f7f11d50a3a
2.0 System.Data.SqlClient, Version=4.2.0.2, PublicKeyToken=b03f5f7f11d50a3a

so maybe I do need it ?


(JohnMoshakis) #26

So your right, if I add a nuget reference to System.Data.SqlClient in the .net standard library but dont set copy local it works in the mono console.

Do you think I need to add a reference to the System.Data.SqlClient nuget in the .net core console ? I tried that and Im still getting FileNotFound on my standard library.


(JohnMoshakis) #27

So I tried creating a new standard library using SqlConnection and it wont compile because SqlConnection is an Unknown identifier. I havent added any nuget references, so maybe I need to add system.data.sqlclient ?

This appears strange because I was compiling my other standard lib without that reference. I added it back to get the console app to work. If I remove it again it still compiles, even with rebuild.

Do you know whats going on ?


(JohnMoshakis) #28

So Dapper has a reference to System.Data.SqlClient and thats why it builds :slight_smile:


(JohnMoshakis) #29

So I got my webapplication building in Fire against mono. I also changed the data access assembly to be .net standard 2. Its using the system.data.sqlclient nuget with copy local disabled. It runs ok on my mac but when I deploy the assemblies to a windows machine I get this error

Could not load file or assembly ‘System.Data.SqlClient, Version=4.5.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a’ or one of its dependencies. The system cannot find the file specified.

Based on this https://apisof.net/catalog/System.Data.SqlClient.SqlConnection

That version only exists in core.

There must be more to this :slight_smile:


(JohnMoshakis) #30

Ok I think this should be it. Ive turned off copy local on my .net standard library references and added them to the exe/web application. That works on mono and windows.


(marc hoffman) #31

I’d say yes, but not as Copy Local.

I tried that and Im still getting FileNotFound on my standard library.

if it fails even with copy local, I wonder if thats coz as you say Dapper also pulls it in and that makes it Copy Local. Do you have the .dll next to your .exe? If so, what happens if you make Dapper non-copy-local too? does it fail on missing that .dll (or does the .NET Core runtime retrieve that as needed via the .deps)?

Yes, of curse you need that?

Hmm. So the .NET Standard 2 assembly links 4.5.0.0 of that dll, and thats not supported by the full .NET Framework on Windows? odd.

Odd that that would fix the version # mixup, but I’ll take the win :wink:


(JohnMoshakis) #32

On the nuget page

These are the references for core

Should I see those listed in Fire ?

Currently I dont but I am seeing them listed in visual studio for mac.

For .net core Im still getting a PlatformNotSupported Exception and the equivalent code in visual studio works fine.

Cheers,
John


(marc hoffman) #33

The Add References dialog (right now) only lists whats in the local repository and the cache. see Adding a Gradle repository for "Add Reference" dialog for a more detailed discussion of this.


(JohnMoshakis) #34

Sorry I wasnt trying to add this from nuget. I was using the nuget page to see what references the netcore version had. Comparing nuget page, visual studio and Fire, I was wondering why Fire didnt list those as dependencies where as VS does?


(marc hoffman) #35

Oh. you mean they don’t get pulled in as indirect package references? lets see…


(marc hoffman) #36

What version of .NET Core are you building for?

System.Data.SqlClient.nuspec lists no dependencies for <group targetFramework=".NETCoreApp2.2">


(JohnMoshakis) #37

Yes.

I was wondering if I could just copy the resulting dlls from a working .net core console but it doesnt seem to be as easy as that because I still get platform not supported from Elements.

I did a dotnet publish from the visual studio console and it looked to be copying the references.

Its 4.6.0


(marc hoffman) #38

And the ones for 2.1 and below have “exclude="Compile" />” which is why they don’t get added.

Seems correct to me. Does anything actually not work?


(JohnMoshakis) #39

Regarding the exclude=“Compile”

If I do “dotnet run project.csproj” and look at the debug folder it just contains the console and the referenced .net standard assembly I created.

dotnet publish project.csproj contains those references.

Im under the impression the only thing we can do with the dotnet app is run the resulting application so is what Im doing more like a publish ?

Yes I’m not expecting to get the PlatformNotSupported exception.

I can send you my visual studio sample.


(marc hoffman) #40

I’m confused, sorry…