WCF

Initialising Castle ActiveRecord in a WAS-hosted WCF service

Ryan Schreiber — Fri, 16 Jul 2010 09:25:53 GMT

I stumbled upon an interesting problem this morning where Castle ActiveRecord was being initialised correctly in the development environment, but as soon as everything was rolled out to the lab environment, the application would throw errors about AR not being initialised. The error message was along the lines of:

An ActiveRecord class (Darkside.Domain.Person) was used but the framework seems not properly initialized. Did you forget about ActiveRecordStarter.Initialize() ?

A bit of background info: As is custom in our web projects, we use an HttpModule to do the AR initialisation. In this case, the web project is actually a WAS host for our WCF services. After doing a bit of research, I found out that HttpModules are not executed when running WCF services. The reason we had the illusion it was working in dev is because of a default page that was started when the project was run. This caused the HttpModule to run, which in turn initialised AR for that session.

Our solution to this problem was to make use of a custom service host factory. I’ve touched on the custom service host factory subject here before, and this solution is just another use of it.

public class CustomServiceHostFactory : ServiceHostFactory

    private static readonly object m_InitActiveRecordLock = new object();

    public override System.ServiceModel.ServiceHostBase CreateServiceHost(string constructorString, Uri[] baseAddresses)

        //Initialise ActiveRecord...

        if (!ActiveRecordStarter.IsInitialized)

            lock (m_InitActiveRecordLock)

                if (!ActiveRecordStarter.IsInitialized)

                    ActiveRecordStarter.Initialize(Assembly.Load("Darkside.Domain"), ActiveRecordSectionHandler.Instance);

        //Hand off the real host creation to the base class..

        return (base.CreateServiceHost(constructorString, baseAddresses));

You then need to add the Factory attribute into your .SVC file

<%@ ServiceHost Language="C#" Debug="false" Service="Darkside.Services.CRUDService, Darkside.Services" Factory="Darkside.WAS.CustomServiceHostFactory" %>

Now, if a new service host is created in your app, AR will be initialised first, if needed.

Consuming a self-hosted WCF service in Silverlight

Ryan Schreiber — Thu, 09 Apr 2009 02:44:11 GMT

If you've decided to self-host a WCF service - or as in my case you already have a service in production but need it to be consumed by a Silverlight application, but keep on getting a security exception, here's a method of getting your existing services to work. It involves getting the WCF service to serve a "file" called "clientaccesspolicy.xml" when one is requested, as is done by Silverlight.

DOWNLOAD - WCF4Silverlight.Zip

Firstly, if you haven't already, you'll need to expose your services using an http binding. In my example project, I have a service MyService which is exposed using netTcp. My configuration file originally looked like this:

<configuration>

  <system.serviceModel>

    <behaviors>

      <serviceBehaviors>

        <behavior name="enableMetaData" >

          <serviceMetadata httpGetEnabled="true" />

        </behavior>

      </serviceBehaviors>

    </behaviors>

    <services>

      <service name="Darkside.WCF4Silverlight.MyService" behaviorConfiguration="enableMetaData">

        <host >

          <baseAddresses>

            <add baseAddress="net.tcp://localhost:9000"/>

          </baseAddresses>

        </host>

        <endpoint address="Calculator" binding="netTcpBinding" contract="Darkside.WCF4Silverlight.IMyService" />

      </service>

    </services>

  </system.serviceModel>

</configuration>

I modified the configuration file to look like this:

    1 <?xml version="1.0" encoding="utf-8" ?>

    2 <configuration>

    3   <system.serviceModel>

    4     <behaviors>

    5       <serviceBehaviors>

    6         <behavior name="enableMetaData" >

    7           <serviceMetadata httpGetEnabled="true" />

    8         </behavior>

    9       </serviceBehaviors>

   10       <endpointBehaviors>

   11         <behavior name="webHttpBehavior">

   12           <webHttp/>

   13         </behavior>

   14       </endpointBehaviors>

   15     </behaviors>

   16     <services>

   17       <service name="Darkside.WCF4Silverlight.MyService" behaviorConfiguration="enableMetaData">

   18         <host >

   19           <baseAddresses>

   20             <add baseAddress="net.tcp://localhost:9000"/>

   21             <add baseAddress="http://localhost:9001"/>

   22           </baseAddresses>

   23         </host>

   24         <endpoint address="Calculator" binding="netTcpBinding" contract="Darkside.WCF4Silverlight.IMyService" />

   25         <endpoint address="Calculator" binding="basicHttpBinding" contract="Darkside.WCF4Silverlight.IMyService" />

   26         <endpoint address="" binding="webHttpBinding" behaviorConfiguration="webHttpBehavior" contract="Darkside.WCF4Silverlight.IClientAccessPolicy" />

   27       </service>

   28     </services>

   29   </system.serviceModel>

   30 </configuration>

You'll notice on line 11 I added a new behaviour, on line 21 I added a new base address for the http exposed services, and I've added two extra endpoints on lines 25 and 26.

The first additional endpoint (line 25) is to expose my existing service over an http binding that can be consumed by Silverlight. The second additional endpoint (line 26), which has no address, is what we'll use to serve the file. It also has the new behaviour added to it to enable it as a REST service.

On a side note: If you don't have this behaviour configuration configured, you may an error along the lines of "The message with To '*' cannot be processed at the receiver, due to an AddressFilter mismatch at the EndpointDispatcher. Check that the sender and receiver's EndpointAddresses agree". Originally, before I had the behaviour in and I requested the URL in my browser all worked well. Suddenly, after making some minor changes, the error above occurred and didn't stop until the behaviour was configured.

Back in your source code, you need to add a contract as follows:

[ServiceContract]

public interface IClientAccessPolicy

    [OperationContract, WebGet(UriTemplate = "/clientaccesspolicy.xml")]

    Stream GetClientAccessPolicy();

In your service, modify the definition of the class to also implement this new contract. The implementation of the GetClientAccessPolicy method is included in the excerpt below:

   public class MyService : IMyService, IClientAccessPolicy

        //Existing code...

        public Stream GetClientAccessPolicy()

            const string result = @"<?xml version=""1.0"" encoding=""utf-8""?>

<access-policy>

    <cross-domain-access>

        <policy>

            <allow-from http-request-headers=""*"">

                <domain uri=""*""/>

            </allow-from>

            <grant-to>

                <resource path=""/"" include-subpaths=""true""/>

            </grant-to>

        </policy>

    </cross-domain-access>

</access-policy>";

            if (WebOperationContext.Current != null)

                WebOperationContext.Current.OutgoingResponse.ContentType = "application/xml";

            return new MemoryStream(Encoding.UTF8.GetBytes(result));

You can now start the service host, open up your browser and, if you're using the sample application above, enter the url http://localhost:9001/clientaccesspolicy.xml. You should get a response along the lines of this displayed in your browser:

<?xml version="1.0" encoding="utf-8"?>
<access-policy>
    <cross-domain-access>
        <policy>
            <allow-from http-request-headers="*">
                <domain uri="*"/>
            </allow-from>
            <grant-to>
                <resource path="/" include-subpaths="true"/>
            </grant-to>
        </policy>
    </cross-domain-access>
</access-policy>

Now you can safely reference your service from you Silverlight application, and the cross domain security issues should be resolved, as the request for the file "clientaccesspolicy.xml" by the application will now be responded to by your service.