Wcf: Missing ProtectionLevel property on ServiceContractAttribute

[menaheme]

I have installed the Nuget package System.ServiceModel.NetTcp , trying to invoke an existing WCF operation from a .Net Core 2.1 project.

The service's contract (that i do not cotrol) specifies ProtectionLevel.EncryptAndSign at the contract level.
I can see the ProtectionLevel property in the source code of ServiceContractAttribute in this repo, and also in the decomplied assembly on my hard drive, but the compiler reports the classic

"The Type or namespace 'ProtectionLevel' could not be found"

The Enum ProtectionLevel itself is known to the compiler.

Using VS 2017 (15.9).

[Lxiamail]

@menaheme Looks like ProtectionLevel is not exposed in .Net standard contract. Does your scenario use MessageSecurity later? I'm wondering if this issue is the only issue blocking your app run on .NET Core.

[mattilindroth]

Hello, I also have this problem. I would need to set ProtectionLevel.Sign to ServiceContractAttribute, but alas I cannot. This is the only reason I cannot develop my software in dotnet core. Hope you'd push the priority of this up ;)

[Lxiamail]

@mattilindroth Does your scenario use MessageSecurity later?

[phrohdoh]

I am also running into this (ProtectionLevel not being in the .NET Standard I am targeting: 2.0).

I don't see MessageSecurity anywhere in my codebase (nor has it been explained how that is relevant, if we knew that we may be able to provide more information).

Is the 3.0 milestone this is assigned to .NET Core 3.0, .NET Standard 3.0, or 3.0 of a WCF lib?

[mconnew]

The ProtectionLevel property on ServiceContract is used to specify how MessageSecurity is applied to the soap message. With MessageSecurity, it's not required that everything in a soap message is part of the signature and not everything is encrypted. For example, if you set ProtectionLevel to Sign, then the soap message body will be included as part of the WS-Security message signature but the body will be sent unencrypted. Sometimes you don't care that anyone can see the request, but you do care to make sure nobody has modified it since the originator created it. If you set ProtectionLevel to EncryptAndSign, then the message body will be encrypted too. There's different granularity that you can set this on. ServiceContractAttribute is used to apply a single setting across all operations. You can override this per operation by setting ProtectionLevel on OperationContractAttribute. There are ways to override it on a per parameter basis too. The contract properties are only used when using MessageSecurity. If you aren't using MessageSecurity, then this property does nothing. If you want to modify the ProtectionLevel when using TransportSecurity, then you modify a ProtectionLevel property on the transport binding element.
As we don't support MessageSecurity on .NET Core, this property has no effect and no purpose. If the property were added to our api, modifying it shouldn't have any effect.

[mconnew]

To answer what I think your last question is, we will have a new release at the same time as .NET Core 3.0, but we are not moving forward our dependency to require .NET Core 3.0/.NET Standard 3.0 and currently have no plans to. The only thing which would make us do so is if there are new api's that there's a very compelling reason to use which would require it. We're staying at 2.0 so that you can still create a single library targeting netstandard2.0 which will work on .NET Core and .NET Framework.

[makacenko]

Hello, I have the same problem. I need to migrate a SOAP client of 3rd party service from .NET Framework to .NET Core.

Setting which successfully work on .NET Framework 4.7.2:

service.Endpoint.Contract.ProtectionLevel = System.Net.Security.ProtectionLevel.Sign;

where service is a contract/reference generated from wsdl by dotnet-svcutil targeting .net standard 2.1.

But on .NET Core 3.1, I cannot find how to set ProtectionLevel to value System.Net.Security.ProtectionLevel.Sign. This is necessary to make success call to the remote service - they support only this specific format of the SOAP message.

How can I achieve the same behavior on .NET Core?