Late last week I ran a couple of internal technical spikes to verify a standard assumption I was making in a design. The question was whether .NET Core was a valid platform for a new system, and although some very minor work had been done in .NET Core, this system would need to integrate with a number of existing services, and this had not been trialed previously.
I figured it would be simple (but I still wanted to verify it before setting down that path). It wasn't, and I'm glad I did take it that step further.
It turns out that .NET Core / .NET Standard 2.1 does not support WSHtttpBindings. WSHtttpBindings includes most of the WS-* extensions, including WS-Security, so if you are using Message security in WCF you can't use .NET Core.
All is not lost even if you are using WSHttpBindings. You can convert WSHttpBindings to a CustomBinding (this site helps a lot: http://webservices20.cloudapp.net/). If you are using WSHttpBindings, but no not using WS-*, you may still be OK. .NET Core doesn't support the specific implementations of many of the classes even where they are actually present in the netstandard library and result in PlatformNotSupportedException at runtime, so make sure you test it even if the appropriate binding classes are available.
In this case we were never going to be able to connect to that particular WCF endpoint using .NET Core.
It would be possible to manually implement WS-* implementations, but it's not something I would have the time not inclination to support.
As an aside, we implemented a secondary TransportOnly WsHttpBinding on the services years ago to address an issue with TransportWithMessageCredential and load balancers under heavy load. I was able to use that secondary binding using a CustomBinding in .NET Core, so the end result was that we could access the service, but it was a good assumption to have questioned and validated.