Hello!
I just completed full migration from Enterprise 10.9.1 to 11.1. I have most everything back up and running except 1 custom SOE we have was using SqlConnection and System.Data.SqlClient to call a SQL command. I got a 'System.Data.SqlClient' is not supported on this platform. Thinking it was similar to the recent ArcPro add-in issue I swapped that out for 'Microsoft.Data.SqlClient' with the same results. This was working fine before the upgrade. Does any one have any input on this one?
Thanks!
Mike
https://developers.arcgis.com/enterprise-sdk/guide/net/whats-new-11-0-net/
The .NET SOE or SOI projects built with the previous versions of the SDK will no longer work with ArcGIS Enterprise SDK 11.0.
Thanks. I guess I should have emphasized more than just in the post title that I upgraded the SOE. I have migrated all of our SOE's to the new 11 SDK using VS2022. They all migrated fine except for this one issue I'm having with that particular assembly - Microsoft.Data.SqlClient'. I even updated to the latest release and the error still shows up.
try and see SqlClient troubleshooting guide - ADO.NET Provider for SQL Server | Microsoft Learn
I am having a similar issue with a brand new SOI, and am using Microsoft.Data.SqlClient, instead of System.
What I want is to insert a row in a separate, non-spatial MSSQL database, so that I can keep records in sync between my enterprise geodatabase and the non-spatial database.
I am new to the Enterprise SDK; is this a feasible use case?
Can I implement additional interfaces, like IDbConnection on my SOI class? Create a separate class?
Or do I need to do this operation at the database level, with like an SSIS package?
try and see System.Data.SqlClient is missing in a .NET Core project | MAKOLYTE
Either way I get 'System.Data.SqlClient is not supported on this system' or 'Microsoft.Data.SqlClient is not supported on this system'. I thought it had something to do with the same issue that Pro was seeing with 3.0 where it migrated to 'Microsoft.Data.SqlClient'. Any ideas?
I was having the same issue with the error "Microsoft.Data.SqlClient is not supported on this platform." Same thing, upgrade from a 10.8.1 version using the ArcObjects SDK to using the ArcGIS Enterprise SDK 11.1. The SOE uses the SQL client to get some of the service data back from the source DB.
The SOE compiled successfully and even registered successfully as an extension in ArcGIS Server Manager. As noted, I got the "Microsoft.Data.SqlClient is not supported on this platform." error once I tried to assign it as a capability to Map service.
We requested support from ESRI on the issue and it has been identified as a bug (BUG-000158547) and should be resolved in a future release. However, I was also provided with a workaround that is working so far.
The compiled SOE found in bin folder that is copied to the server can be unpacked and updated - as in, rename the extension to ".zip" and you can expose the install files that are packaged up in the SOE. The compile folder also contains a folder of runtimes that has an updated version of the Microsoft.Data.SqlClient.dll, (bin\Debug\net6.0\runtimes\win\lib\net6.0) and I was able to copy that dll into the SOE Install directory, rename the file back to the SOE extension and update the SOE on the server. Then worked as a capability with the Map service I assigned it to without errors. Hoping this helps!
Hi
I tried this workaround and it didn't seem to work. The SOE deploys on Server successfully but it throws an error when the service that uses it's capability is attempted a start:
CLSID for Type MapServer is not registered
@SusanHmel__DOIT_ are you able to successfully use the Microsoft.Data.SqlClient in your SOE after your workaround?
The workaround solved the issue with the "Microsoft.Data.SqlClient is not supported on this platform." error when the service was started for me-- the first 1 or 2 times I didn't get that error I got other errors that were related to other parts of the SOE code - the main one being an SQL Exception error -
A connection was successfully established with the server, but then an error occurred during the login process. (provider: SSL Provider, error: 0 - The certificate chain was issued by an authority that is not trusted.)]
I update my connection details to work around that for my particular SOE, recompiled, re-instituted the Microsoft.Data.SqlClient.dll file replacement and replaced the SOE. It's working as expected.
If you are getting past the Microsoft.Data.SqlClient.dll error then you may want to look for other issues with your SOE code that are throwing the "CLSID for Type MapServer is not registered" error.
Out of curiosity:
Did you start with the 11.1 SOE template in VS, and did you include .Net Extension Support in your ArcGIS server installation?
With my SOE I don't get the '..is not supported' error until I acutally call the SOE extension from an app and I can see the error in the dev console. The SOE deploys fine and I can start the service with no problem. With the workaround, the SOE deploys fine but the service will not start due to the 'CLSID...' error.
Also, it is from a fresh 11.1 VS template and .Net Support is installed on Server.
Stumped...might need to wait for the update (hopefully a patch sooner than later).
I had that issue after attempting the workaround too. I suspected this was due to the way that I did the "unzip" and subsequent "zip" process. So I redid this exactly as Susan prescribed and it worked. That is, I renamed the soe file to be a zip file. Then I used File Explorer to navigate into the zip file and pasted the Microsoft.Data.SqlClient.dll from the bin\Debug\net6.0\runtimes\win\lib\net6.0 folder into the Install folder, which I had opened in my File Explorer. Then I navigated back out of the zip file and renamed it back to soe. When I updated my extension using THAT soe file, I was able to use my extension and it no longer errored out with the "is not supported on this platform" error. Now I am getting the "certificate chain" error that Susan mentioned. Oh esri.
I had the same issue, but needed to copy the Microsoft.Data.SqlClient.SNI.dll into the Install folder location within the .soe, too.That file is already located in the .soe's runtimes folders:
After more reading, a simpler solution turned out to be updating the .csproj with the RuntimeIdentifier tag.
Les membres connectés peuvent publier, suivre les mises à jour, et plus encore. Nouveau ici ? Inscrivez-vous gratuitement.
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.
