We Keep Coding

WebServices on Unity, Dll, compatibility with .Net 4.0

I'm trying to use web services on unity.
I used svcutil to generate a proxy class, however the proxy class was using "System.Threading.Tasks".
I noticed that System.Threading.Tasks wasn't aviable on .Net 3.5.
So I went to player setting and I changed to .Net 4.x
But now I have an other issue, and I cannot find a way to fix it, I need to use System.Web.dll and System.Web.Services.dll to make my web service work, however, the dll that are include in Program Files\Unity\Editor\Data\Mono\lib\mono\2.0 are all targets for .Net 3.5.
So that mean I cannot use them on .Net 4.x
I've been looking for quiet long and was unable to find any answer.
I can add the code to the proxy class here if it's require, but I don't think it would be useful. Should I download those dll somewhere?
Anyone ever seen thoses issues somewhere?

You are using the wrong dll version.
Once you change Api Compatibility Level to Net 4.x, you have to copy the System.Web.dll and System.Web.Services.dll files from <UnityInstallationDirectory>\Editor\Data\MonoBleedingEdge\lib\mono\4.5 to your <Project>\Assets path.
That's it. Restart Visual Studio and Unity.

There is another method of linking missing libraries as described in this unity documentation.
Create a file called csc.rsp and put these 2 lines in it:
-r:System.Web.dll
-r:System.Web.Services.dll
And yes, you better set compatibility level to .NET 4.x
You also might want to restart Unity or VS in some cases.

Reference error when deploying MVC website on server that imports a .NET standard class with a system.data.sqlclient reference

This is my first question. I have tried really hard to find a solution to my problem, but it seems to be a pretty specific collection of problems and I haven't found anything that works. I think I have narrowed down/identified my problem, but I don't know the solution or how to implement it correctly. I have tried to be detailed, but also concise. I don't have a strong coding theory background, just what I have learned online from MS documentation, Stack overflow, and other tutorial-like websites.
Background
In visual studio I wanted to create a class library that manages tables in a given database. It's part of a generic style API to handle implementations of repetitive database structures across projects. Because I wanted to create a generic class that I could use in various projects utilising various .NET frameworks, I decided to build the class using .NET standard 1.4. Because I needed to connect to MS SQL databases, I imported the System.Data.SqlClient namespace (an System.Data.Common) using NuGet.
I employed the use of a test MVC application in the solution and got some basic functions working in Visual Studio including opening the actual databases. Despite the recommendation not to, I referenced the compiled DLL from the release build rather than importing the reference as a project. I did this to mimic how I would be testing the class in my deploy environment. Everything here worked fine provided I added the reference to System.Data.SqlClient in the test application.
When testing the deployment however, things went awry. I was using an FTP connection to copy the files to the server. The server is running the .NET 4.5.2 framework. I kept getting a persistent error that the System.Data.SqlClient version 4.1 could not be found. I tried importing it into the project using NuGet and still had the problem. I was importing version 4.1, the earliest version (which is what I referenced in the class library). I also tried changing the reference in the class library to 4.4.2, the latest version, and importing that instead. Still had the same problem.
I then copied the code from the C# class from the class library and added it to a new .cs file in the FTP project- it compiled and ran without incident. I didn't need to import the System.Data.SqlClient in order to reference it, suggesting that a version of the namespace is already available on the server.
Problem/Question
This leads me to believe that there is a conflict where I'm trying to reference 2 different versions of System.Data.SqlClient within the FTP project.
As such, this leaves me to try and work out either:
How can I build a .NET standard class library that can use the latest installed version of System.Data.SqlClient in the target project (although, I fell like this is not really achievable given the way DLLs/versioning in general works)?
OR
How can I build a .NET standard class library that can use any of the currently available versions of System.Data.SqlClient (i.e. only use APIs that all current versions implement) and target the one already installed/referenced in the project that references it?
OR
How can I tell visual studio to include the referenced System.Data.SqlClient version used in my standard class library and only reference it for the purposes of running this library, with the rest of the project targeting whatever the other version may be?
OR
The otherwise correct way to manage this reference when it is not in the .NET standard library, but may be present in any given version in the application that references my library DLL.
Basically, I want to avoid having to write a new version of this class for every target framework if I don't have to.
End Note
I hope this question is of a good standard, I feel I have probably gone about something wrong in the implementation and that advice on the proper way to implement such a library would be of great help to myself and others in a similar situation.

Saxonica 9.7 HE in C#

I'm trying to get Saxon 9.7 HE up and running in C#, and failing miserably.
As per instructions, I am downloading and running https://sourceforge.net/projects/saxon/files/Saxon-HE/9.7/SaxonHE9-7-0-14N-setup.exe/download
This installs a bunch of files into C:\Program Files\Saxonica\SaxonHE9.7N.
In the bin folder inside this one, the following files are present:
No matter which DLLs I add as references to my project, the "using Saxon.Api;" reference fails to resolve.
Am I using the correct DLLs here? Is it some sort of .Net version mismatch? My class library project is set to .Net 3.5 currently.
Thanks for any help

The minimum supported version of .NET for Saxon is indeed 4.0.
The bug is in the documentation which will be updated shortly: See bug issue: https://saxonica.plan.io/issues/3085
Thanks for reporting the issue.

Some guess work here. But the dependency on .net 4 is most likley from the compiling of the C# wrapper over the saxon java library that was converted using IKVM. IKVM says it only requires .net 2.0, so I think the only place that dependancy can come from is the saxon9he-api.
You should be able to build this yourself, its quite thin.
https://dev.saxonica.com/repos/archive/opensource/latest9.7/hen/csource/api/Saxon.Api/
Otherwise if its a show stopper ask Michael Kay (the author), he's pretty active on stack overflow.
Updated
I was curious so I checked, the .Net 4 dependency seems to come from the saxon9he-api (which i'm fairly certain could be re-compiled under 3.5 with no/minimal changes), the same for the Query and Transform exe's.

Sharing a DLL between projects

Microsoft says it's platform neutral these days, so I'm trying to build on Mac and Linux only with VS Code and deploy to Azure. Why? It's mainly to prove that I can.
Our project has several parts which include a couple of different websites, a Web API, er API and a few other bits. On my Mac I've built a .Net Core Class Library with a load of objects in. Command line, dotnet build, DLL out, no problem.
I want to put that DLL on the Linux machine where the MVC website is being built - the objects forming the models part of that site hopefully. I cannot figure out how to get the website project to reference my DLL and use the objects.
I had assumed I copy it to the other machine, place it in the bin folder of the site being developed and reference it in the Dependencies section of the site's project.json. Nope. I saw a few articles that said .Net Core only works with NuGet and it had to be a package. Is that really true?
I've found and read (if not entirely understood) everything you could imagine on sharing between .net core and .net framework. This is a core-only project so not applicable. Frankly I'm lost, and something called .Net Standard has just rolled into my field of vision.

So instead of copying the DLL, use dotnet pack to build a nuget package on your Mac, and copy that to your Linux machine instead. Put it in a directory that you configure as a local nuget repository (no server or anything required) and you're away.
I agree it's not as straightforward as a reference to a DLL, but it's not too bad. Note that you'll need to version the package appropriately, so that the tool system can detect when it's changed.

.net remoting problem

I've got a .net 2.0 class library that uses .net remoting to communicate with a .net 2.0 server application.
I'm now creating a WPF version of the client and included the .net 2.0 communication dll.
The remoting no longer works (Exception Could not load file or assembly 'System.Data, Version=4.0.0.0,)
the line that fails is passing a DataTable as a parameter to a remote method.
The problem is if you use .GetType().Assembly it really does show that it's using the .net 4.0 System.Data assembly which the server obviously doesn't know about.
is there a way I can force the library to use .net 2.0 libraries for serialization?

This kinda depends on what type of configuration you're targeting, even if you run 2.0 and 4.0 in a mixed fashion this should be taken care by the run-time for you.
There seem to be a lot of components involved here, are you sure they are built using the correct frameworks?
If you build a WCF client on one machine and targets a different framework than the one installed on the machine that runs it it could lead to problems.
I'd like to know some more about your setup, specifically what projects you have and what "profile" these projects targets.
Meanwhile, you could try hooking the AppDomain.CurrentDomain.AssemblyResolve event and try locating the assembly yourself, it can work but it can also help to identify where in your code this problem occurs.

looks like your application was created as Framework 4 Application.
Check the settings of the project.