ReplyAction="*"

Recently came across the problem where the ReplyAction property in the OperationContract attribute was set to * - ReplyAction="*". wscf.blue was generating it with this, since the format SOAP action wasn't selected.

This was a problem as the operation was excluded when WCF generated the wsdl - after working out that is was ReplyAction="*" was the problem, I googled it, and found this on StackOverflow  

AppFabric’s E2EActivityId and non .Net 4.0 clients

Recently came across the scenario where the client wanted to supply the ActivityId that is to be used in AppFabric, however they weren't a .Net 4.0 client. If the client supplied the ActivityId in SOAP header request, then the framework will use this, rather than creating its own (assuming the monitoring level is End-To-End).

For .Net 4.0 clients, it's very easy to specify the value at the client end using Trace.CorrelationManager.ActivityId and ensuring that <endToEndTracing propagateActivity="true"/> is set in the client config. However endToEndTracing is new to .Net 4.0.

Initially I tried: OperationContext.Current.OutgoingMessageHeaders.Add(MessageHeader.CreateHeader("ActivityId", "http://schemas.microsoft.com/2004/09/ServiceModel/Diagnostics", activityId.ToString()))

where activityId was my guid in the client, however the ActivityId type also has a correlation id property, which is an attribute in XML. And that's the problem, I'm not aware of a method of adding a SOAP header element where you want to set a custom attribute on the element. The framework will ignore the ActivityId header if no correlation id is supplied as well.

So the option I went with was modifying the MessageContract to include the ActivityId header, so when you create the request at the client, you have the option of setting the Activity and Correlation Id. Here is the ActivityId type:

[System.Xml.Serialization.XmlTypeAttribute(Namespace = "http://schemas.microsoft.com/2004/09/ServiceModel/Diagnostics")]

[System.Xml.Serialization.XmlRootAttribute(Namespace = "http://schemas.microsoft.com/2004/09/ServiceModel/Diagnostics", IsNullable = false)]

public class ActivityId

{

[System.Xml.Serialization.XmlAttributeAttribute()]

public Guid CorrelationId;

[System.Xml.Serialization.XmlTextAttribute()]

public Guid Value;

}

Next, add a property of this type to the request message contract:

        [System.ServiceModel.MessageHeaderAttribute(Namespace = "http://schemas.microsoft.com/2004/09/ServiceModel/Diagnostics")]



       public ActivityId ActivityId;

Done. FYI – the schema definition for the ActivityId type is available here http://msdn.microsoft.com/en-us/library/cc485806(PROT.10).aspx

soapUI and wsHttpBinding

Below are the steps required to allow soapUI to consume a WCF service which is using wsHttpBinding.

1. By default Message Security is turned on for wsHttpBinding, which isn't supported by soapUI. So the security mode for the binding needs to be set to None:
   

   
   

   <bindings>
   <wsHttpBinding>
   <binding>
   <security mode="None">
   </security>
   </binding>
   </wsHttpBinding>
   </bindings>
   

   
   

2. After creating the new soapUI project, the only update that is required is to select the 'Add default wsa:To' check box (as WS-Addressing is part of the wsHttpBinding). Enable/Disable WS-A addressing should already be selected, along with the appropriate SOAP action. The below options are available when you click the WS-A button, available as part of the Request window.
   

The specified database is not a valid Monitoring database or is not available

During a rollout into production, the windows sys admin was responsible for executing the AppFabric installation scripts that I had put together, which includes using the Initialize-ASMonitoringSqlDatabase cmdlet, which allows you to create the monitoring database for AppFabric to use.

Just a reminder that the account running the script / cmdlet must be a sysadmin on the target SQL server, or you'll get the not a valid Monitoring database.... error, which we were getting.

More details are here.

The error message returned from the Initialize-ASPersistenceSqlDatabase cmdlet is a little more descriptive - Failed to connect to the master database on the SQL server.... Could not open a connection to SQL Server. However, this error message is caused for the same reason.

Default physical path when deploying web applications using MSDeploy

MSDeploy will use the physical location of the web site that the web application is being deployed under, if you're deploying a web application without specifying a physical location in the parameter settings.

Specifically, MSDeploy uses the physicalpath attribute for the site defined in the applicationHost.config file, which is located C:\Windows\System32\inetsrv\config.

So for example, my default web site is defined as physicalPath="E:\inetpub\wwwroot", which is specified in the virtualDirectory element. I have an application whose virtual path is under the default web site. When I deploy this application, which doesn't have a physical location specified as a parameter, it will use E:\inetpub\wwwroot as the base, and create a sub folder - e.g. E:\inetpub\wwwroot\NewApplication.

One thing to keep in mind, once the deployment has been performed, a new application element is created in the applicationHost.config file for the web application deployed. If you delete the application from IIS - the configuration remains for the application. This is key to remember, as this will now become the default physical location for the application, regardless of the physical location of the default web site. So if you want MSDeploy to use the default web site's physical address as the base address (assuming your deploying your applicaion under DWS), then you'll have to manually delete the application element for the web application in the applicationhost.config file before executing the deployment.

IErrorHandler.ProvideFault & serialization issues using XmlSerializer

I'm pretty much repeating what I posted here on the MSDN forum, but my work around seems to be doing fine so I thought it's worth noting down in case someone else comes across this problem.

If you're using the XmlSerializer rather than the default DataContractSerializer, beware that once you are out of the context of the service implementation (i.e. in a behaviour), WCF will use the DataContractSerializer. Why is this a problem?

Well, if you have implemented IErrorHandler, and are recreating the fault message that is returned to the client (e.g. using the CreateMessageFault method from the FaultException instance), the message has been serialized again. The trouble is, there is no way as far as I am aware of specifying which serializer to use (hence the reason for my post on MSDN) and WCF resorts back to its default of the DataContractSerializer.

I'm using a fault contract when creating the FaultException - i.e. FaultException and my ErrorInfo type in decorated with the appropriate Xml attribute indicating its Xml type and namespace. Eg:

[XmlType("ErrorInfo", Namespace="http://FaultContract")]
public class ErrorInfo

When this is returned back to the client, a different namespace arrives for the ErrorInfo type (rather than FaultContract), which means the client can't deserialize it. The xml namespace instead is http://schemas.datacontract.org/2004/07/ etc which is not what the client is expecting.

The reason this is happening is that the DataContractSerializer is looking for the DataContract attribute to determine what to use for the xml namespace. Since the ErrorInfo type isn't decorated with this attribute, which makes sense - I'm not using the DataContractSerializer, a default namespace is used instead.

To fix this, I have decorated the ErrorInfo type with both the XmlType attribute, and DataContract attribute:

[DataContract(Name="ErrorInfo", Namespace="http://FaultContract")]
[XmlType("ErrorInfo", Namespace="http://FaultContract")]
public class ErrorInfo

This now handle both scenarios, the Fault message created within the context of the service (where you can specify the serializer to use), and the Fault message created within a behaviour.

This took me a while to determine why this was occuring, but eventually I was able to isolate where the problem was (the behaviour). When I turned the IErrorHandler behaviour off, the client was able to deserialize the ErrorInfo type correctly (as the correct namespace was used).

EventProvider class - make sure it's a singleton

For emitting user defined events into AppFabric's monitoring database, I'm using the WCFUserEventProvider class (which is available in the WCF 4.0 samples). Basically this class wraps the EventProvider class which is the underlying class thatprovides the ability to emit user defined events to ETW.

During some performance/load testing of a WCF service, the apppool process continued to use more and more memory, which resulted in gradual reduction in throughput. Eventually I discovered I was instantiating a new instance if the WCFUserEventProvider class (therefore creating a new instance of the EventProvider class) everytime an user defined event was logged.

Once I changed my implementation to just have a static instance of EventProvider, no more memory leakage, and the throughput remained constant.

It's the construction of the EventProvider class that is the costly part, not the actual submitting of the event.