wcf: Missing ProtectionLevel property on ServiceContractAttribute

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).

About this issue

Original URL
State: open
Created 5 years ago
Comments: 21 (9 by maintainers)

Most upvoted comments

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 😉

mattilindroth on Apr 3, 2019

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?

makacenko on Jan 25, 2021

AsymmetricSecurityBindingElement is full Message security and isn’t supported yet.

mconnew on Apr 19, 2023

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.

mconnew on Jun 10, 2019