Windows 10: Supportability of XBAP + ClientFormsAuthenticationMembershipProvider + WCF Message Security...

We are troubleshooting the following architecture scenario:Client: XBAP application .xbap running in IE11 / PresentationHost.exe on Windows Server 2022WCF Service Binding: wsHttpBinding with Security mode="Message" certificate used for encryptionXBAP uses ClientFormsAuthenticationMembershipProvider for login/authenticationTLS ConfigurationotNET TLS Settings-App.config Progrmatically enable the TLS 1.2 in XBAPSystem.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12TLS 1.2 enabled and enforced TLS 1.0 and TLS 1.1 explicitly disabled via SCHANNEL registryCipher Suit

:)

 

AMD FX OC'ers Club

That's what the auto setting will do since you're over the 1333 mark it jumps to the next step which isn't listed or officially supported I assume by that ram.

At this point though I would suggest dropping the multi one step or .5 so that we can get something stable and possibly take the heat issue out of the picture for now.

 

a call from WCF Client using a distributed transaction on one workstaion blocks all WCF Clients that use the same WCF Service from different workstation for an extended period of time?

Aside from removing the TransactionScope created on the WCF client (and effectively taking msdtc out of the picture), Is there an alternate way to avoid the excessively long WCF-service-wide hang when a single workstation hosting
the WCF client is misconfigured (or experiencing communications issues)?

We have a simple WCF service implemented using C#, and a simple WCF Client which creates TransactionScope before invoking the WCF service proxy.

Both work fine as far as concurrency goes if Windows Firewall allows TCP communication from/to msdtc.exe thru firewall. However if a single workstation is misconfigured (i.e. has firewall enabled, and has an Inbound Rule for TCP for msdtc.exe disabled),
its attempt to communicate with the service will block all other WCF clients (which are properly configured) from communicating with the WCF Service for at least 41 seconds (given the currect settings for TCP retransmissions), despite us using much shorter
timeout settings for the WCF binding as well as for the TransactionScope timeout.

The WCF service is decorated with

[System.ServiceModel.ServiceBehavior(

InstanceContextMode = System.ServiceModel.InstanceContextMode.PerCall,

ReleaseServiceInstanceOnTransactionComplete = false,

ConcurrencyMode = System.ServiceModel.ConcurrencyMode.Multiple,

IncludeExceptionDetailInFaults = false,

TransactionTimeout = "00:00:13"

)

The WCF service has a single operation contract, decorated with [System.ServiceModel.TransactionFlow(System.ServiceModel.TransactionFlowOption.Mandatory)] in the class interface.In the class itself, the same method is decorated with [System.ServiceModel.OperationBehavior(TransactionScopeRequired
= true)].

The WCF service is hosted using a Windows console application which uses a netTcpBinding configured with transactionFlow="true" transactionProtocol="OleTransactions" sendTimeout="00:00:20" receiveTimeout="00:00:20"

The service is accessed from a Windows Forms client application configured with the following values for its netTcpBinding:

transactionFlow="true"

transactionProtocol="OleTransactions"

transferMode="Streamed"

sendTimeout="00:00:20"

receiveTimeout="00:00:20"

 

Migrate WCF to .Net Core API

Hi,

The question is regarding - Whether it is required to move WCF project to .Net Core WEB API?

We have a product written in WCF and with good about of business-rules are written into it. Though WCF technology is quite older and is Microsoft putting up the end-of-life/service?

If there is an end of life soon what precaution is to be taken prior?

With Regards,

Sid