LA.NET [EN] : WCF

Re-throwing exceptions

luisabreu — Tue, 02 Dec 2008 10:33:25 GMT

While I was reading the Essential Windows Communication Foundation book (from Addision Wesley), I found the following code (on a transaction required for a WCF service context):

[OperationBehavior(TransactionScopeRequired = true,
   TransactionAutoComplete = true)]
public void Transfer( String from, String to, double amount){
try {
    Withdraw(from, amount);
    Deposit( to, amount);
}
catch(Exception ex){
    throw ex;
}
}

Lets not even talk about why using the Exception type in a try/catch is bad (though I accept its usage in a book, but only after seeing a justification of why you should not use it in production code)…instead, lets concentrate on what is happening inside the catch block…see anything wrong there? I hope so! You should never re-throw an exception like that. In my opinion, you’ve got 2 options here:

1. You’re “important” in the stack chain and then you’ll want to wrap that exception with your own specific exception type (for isntance, NHibernate does something like this and wraps ADO.NET exceptions with its own exception type). Here’s what I mean:

catch(Exception ex ) { //btw, don’t catch the Exception type
//do something here…probably log it
throw new MyException(ex);
}

2. You’re not significant, so you can just rethrow that exception after logging:

catch(Exception ex ) { //btw, don’t catch the Exception type
//do something here…probably log it
throw; //see? no ex here!
}

Ok, so why is this important? Because when you re-throw the exception by using technique shown in point 2, you will be preserving the stack trace. When you do it like in the original code, the stack trace that the client will see ends up in your catch block. Probably not what you’ll want in most scenarios!

Do notice that technique 1 will also preserve the stack chain since you’re passing the exception as the inner exception of the new exception you’re throwing. Both of these options are really better than the one shown on the initial code.

I’m only writing this here because I was under the impression that this info should be well know by now, but it seems like I’m wrong…Do keep in mind that it’s not my intent to trash on this book (I’m still on page 211, but I’m liking it so far), but I was a little but surprised by seeing this code there (as always, I’ll put a review after ending it).

.NET 3.5 and VS SP beta1 goodies

luisabreu — Mon, 12 May 2008 19:58:24 GMT

You can get them from here (VS) and here (.NET). I'm reading what's new on Brad Abrams post and I'm really digging the new features:) For instance, having the format option working with JS code is simply cool! Another cool thing: the ScriptManager is able to combine scripts so there's really no need for using the ToolkitScriptManager for that:)

Btw, i'm still going through the complete list but it really looks like we're gonna gave lots of new stuff :)

WCF again: the slow problem attacks again

luisabreu — Tue, 25 Mar 2008 23:22:10 GMT

On a different set of machines...I'm stumped. I mean, I though I'd nailed it with the proxy problem, but unfortunately there are still some machines where the 1st call is really really slow and removing the proxy isn't helping. I've even profiled the code but I still can't see where the problem lies. I've written a post on the WCF forum, but there are still no clues on how to solve this. Anyone wants to give it a try?

WCF client calls slow

luisabreu — Fri, 14 Mar 2008 11:09:18 GMT

Today I was able to get back to my previous WCF client problem that I had described here. After looking at the old logs again, it was clear that the delay was on the server discoverability. The problem was that pinging was really fast, so it seemed like there was no client/server communication problem. You can say that I'm a curious stubborn guy and since I thought the discovery thing was the problem, I decided to look at the IE settings. And guess what? It had the automatically detect settings of the LAN Settings option turned on. Turning it off solved the 1st time request. After knowing the problem, it was really easy to get a confirmation for it: Dr. Nicholas Allen had already a great entry which discusses this kind of problems.

WCF+Windows Forms = lots of problems with some services

luisabreu — Mon, 10 Mar 2008 23:15:50 GMT

In these last days I've been really busy finishing an application which consists of a Windows Forms app that gets its data from serveral WCF services (which, btw, use basic HTTP binding + SSL). Now, most of the services work really smoothly, but...there are 2 which are really making me go crazy: they are SLOW when run in Windows XP Pro machines! Now, I'm talking about really simple services which should really execute under 300 ms!

As you might expect, the first thing I did was use fiddler to see what was going on. According to it, the request was taking 15 seconds, which seemed to confirm my initial impression that there was something wrong with the service. The next logical step was enabling tracing on the WCF service. I couldn't really believe in what my eyes were seeing: instead of seeing several seconds on processing time, the traced shown <300 ms. Could it be something wrong with IIS (which, btw, is IIS 6 on Windows 2003 Server machine)? To answer this, I enabled IIS logging. Guess what: IIS logging confirms the WCF tracing entries: requests were served in <300 ms!

Maybe there something wrong with the network? Pinging revealed nothing wrong...So I went ahead and installed netmon on my machine. After filtering the traffic, I was able to see that request/response from client to server were consistent with the logging info I was getting from WCF and IIS. So, I've just went ahead and tried using ngen with my client windows forms app. It didn't made any difference though...it was time to try one more thing: logging on the client side.

The SvcTraceViewer tool has a really great feature: you can open several trace files at the same time. When I did this, I got the following results (just copy/paste it here: on each line you'll see a description, the number of traces, the start and end time of the action):

000000000000 8 13s 9:21:20 9:21:34
Construct ChannelFactory. Contract type: 'SRA.Mercados.Servicos.IServicoUtilizador'. 4 328ms 9:21:20 9:21:21
Open ChannelFactory. Contract type: 'SRA.Mercados.Servicos.IServicoUtilizador'. 4 31ms 9:21:21 9:21:21
Process action 'http://sra.pt/Mercados/IServicoUtilizador/ObtemUtilizador'. 24 14s 9:21:21 9:21:35
Receive bytes on connection 'http://bksrv.sranet.local:8080/ServicosMercados/UtilizadorImpl.svc'. 17 437ms 9:21:34 9:21:35
Close ChannelFactory. Contract type: 'SRA.Mercados.Servicos.IServicoUtilizador'. 4 0ms 9:21:34 9:21:34

Construct ServiceHost 'SRA.Mercados.ServicosImpl.ServicoUtilizador'. 10 109ms 9:21:34 9:21:35
Open ServiceHost 'SRA.Mercados.ServicosImpl.ServicoUtilizador'. 64 93ms 9:21:35 9:21:35
Listen at 'http://bksrv.sranet.local:8080/ServicosMercados/UtilizadorImpl.svc'. 6 62ms 9:21:35 9:21:35
Listen at 'https://bksrv.sranet.local/ServicosMercados/UtilizadorImpl.svc/mex'. 4 15ms 9:21:35 9:21:35
Processing message 1. 5 15ms 9:21:35 9:21:35
Execute 'SRA.Mercados.Servicos.IServicoUtilizador.ObtemUtilizador'. 4 265ms 9:21:35 9:21:35

The bold lines are where the problems are happening. Now, I really don't understand why it takes 13 seconds for the process action on the client to hit the server (notice that server will only start its processing at 9:21:34 and that the client opens the channel at 9:21:21!). Now, I'm not really an expert on WCF, but it does seem like there's something wrong going on here. What's bothering me is that I don't know what it is :)

It was getting late, so I only had time for testing one more thing: using perfmon and see if I can get any info from it. I've only tried seeing one thing: the % of JIT time spent on a process. Guess what: the counter goes through the roof when I call a method of one of those services that take a long time! I'm still trying to understand what's going on with those XP machines (specially because on my Windows 2008 server everything is working out smoothly), but it seems like there's something that is making the Jitter do a lot of work when one of those methods gets called. I'm not sure on what it is since, as I've said, it's really a simple method and I've already run ngen on my code.

If anyone has any idea on what's going on here please do share it with me! I'm running out of them and I still don't understand what's going on...thanks.

Syndication and WCF

luisabreu — Wed, 16 Jan 2008 15:16:17 GMT

The latest release of .NET has added several interesting new things. One of those is support for Syndication. The System.ServiceModel.Web assembly has several classes that you can use to expose an ATOM or RSS feed. There's already a cool article on how to achieve this which has been published on MSDN, so I'm not going to bother you with the details (you can check the code online, but don't download it because it's not updated; instead, browse the online version). The only thing I'd like to add to what is presented on the article is how to make Firefox interpret the RSS generated as RSS (instead of interpreting it like XML).

The problem with FF is that it will only consider the XML to be RSS feed if it has all the mandatory elements. If you're like me, you're probably going to go through all the public properties of the SyndicationFeed object and you'll set those that make sense. Unfortunately, there really isn't any called link (though there's a Links collection property) so I didn't set up that element from my code (and <link> is one of the mandatory channel elements! - ok, my fault. Should have read the specs to see which items were mandatory...). And that's why I lost almost one hour trying to understand why FF wasn't applying its default XSLT stylesheet to my RSS content. I could see the XML, but then I got that awful message that said that there wasn't any stylesheet file applied to my XML document. In fact, it looks like I wasn't the only one that forgot to define the RSS link element: if you try to run the code presented on the sample, you'll see something like this:

The only thing you need to fix the code is to add a link element to the feed, which can be done with code that looks like this:

feed.Links.Add(SyndicationLink.CreateAlternateLink(new Uri("put a valid URI here")));

where feed is a reference to a SyndicationFeed object.

Now, if I only could make it add global namespaces, then I'd really be a happy man! (ok, You can add namespaces to the <channel> element, but what I want is to add those declarations on the top <rss> element)

Calling a WCF service from your Silverlight application

luisabreu — Tue, 12 Jun 2007 22:43:58 GMT

Yesterday I talked about calling a traditional ASMX web service from your Silverlight app. Today, I'll be talking about WCF services. As I've said yesterday, in the current release, you only have tool support for getting a proxy to an ASMX web service (well, at least I've tried getting a web reference to a WCF service and it simply didn't work - maybe i'm doing something wrong). However, nothing prevents you from creating your own proxy to make the call to a WCF service.

Since the alpha version only understands JSON when it calls ASMX services, I'm also assuming that is the only way you have to get info from a WCF service. That being the case, you must start by configuring your service to use JSON as its message enconding format.

After doing that, it's only a matter of creating a new proxy class. Let me illustrate this with a quick example. Lets start by creating the dummy service:

[ServiceContract]
public interface ITest
{
[OperationContract]
S DoWork();
}

public class Test : ITest
{
    public S DoWork()
    {
        S a = new S();
        a.Address = "Funchal";
        a.Name = "Luis";
        return a;
    }
}

Don't forget to add the svc file :) (not shown here because there really isn't much to show, right). As you can see, this is really a stupid service which returns an object that only has two properties. Here's the S class (just for the sake of completeness):

[DataContract]
public class S
{
    [DataMember(Name="Name")]
    private string name = "Luis";
    [DataMember(Name="Address")]
    private string address= "Funchal";

    public string Name
    {
        get { return name; }
        set { name = value; }
    }

    public string Address
    {
        get { return address; }
        set { address = value; }
    }
}

Now, the fun begins :) You must start by definig the S class in your silverlight project. You can do this in several ways:

you can add an existing cs file and then choose the link option (instead of clickin in the add button);
you might have built a dll with the previous type and then add it as reference to the service and silverlight projects;
there's always the old copy/paste approach :)

After doing that, you need to build a new type (the proxy) which you'll be using to communicate with the service. You must really build a new class because all the cool methods of the the SoapHttpClientProtocol class that you need to make the service calls are protected (the truth is that nothing prevents you from using the BrowserHttpWebRequest class and then using the JavaScriptSerializer to serialize/deserialize the values. If you find this funny, then by all means, go ahead and do it; i prefer to build the class in 30 seconds and then hit the coach to watch tv :)) . Here's a simple proxy that lets you invoke the DoWork method in a sync fashion:

public class MyProxy:SoapHttpClientProtocol
{
            public S DoWork()
            {
                object[] obj = this.Invoke("DoWork", new ServiceParameter[0], typeof(S));
                return (S)obj[0];
            }
}

Do notice the new ServiceParameter[0] value passed as the 2nd parameter of the Invoke method (needed because the method doesn't receive any parameters; if it expected parameters, you just need to pack them in an array and pass them to the Invoke method)...Getting the async methods is as easy as adding 2 methods which call the BeginInvoke/EndInvoke methods inherited from the base class. Using the proxy is really simple, as you can see from the following code:

MyProxy proxy = new MyProxy();
proxy.Url = "url to the service";
S aux = proxy.DoWork();
Debug.WriteLine(aux.Name +"-"+ aux.Address);

And that's all for today.

Calling your WCF web service from an ASP.NET AJAX page

luisabreu — Tue, 22 May 2007 14:44:19 GMT

The 3.5 beta version of the .NET platform lets us use JSON as the serialization format used by a web service call. The best of all is that this means that we can now call a web service from an ASP.NET AJAX page.

To do this, you need to add some entries to your configuration file (on the server side). Getting a proxy on the client side is a simple as adding a service reference through the ScriptManager control. Lets start by seeing the service code (which was generated by adding a new WCF service to an AJAX futures enabled web site):

[ServiceContract()]
public interface ITest
{
[OperationContract]
string MyOperation1(string myValue);
}

public class Test : ITest
{
    public string MyOperation1(string myValue)
    {
       return "Hello: " + myValue;
     }
}

The svc file looks like this:

<%@ ServiceHost Language="C#" Debug="true" Service="Test"
CodeBehind="~/App_Code/Test.cs" %>

Now you need to add an endpoint that is able to understand JSON. In my case, I wanted to expose a mex endpoint too, so I ended up with the following definitions for my web service:

As you can see, i'm using a WebHttpBinding and I'm saying that there's a new jsonBinding element which configures the traditional webHttpBinding that is introduced by default by the WCF framework. In this case, we're just setting the message encoding to JSON:

We also need to add a new behavior that looks like this:

And that's it! the only thing you need to do to call this WCF service from your AJAX ASP.NET page is add a reference to the web service:

<asp:ScriptManager ID="ScriptManager1" runat="server">
<Services>
<asp:ServiceReference Path="Test.svc" />
</Services>
</asp:ScriptManager>

Doing this ends up inserting the following js code in your page:

Type.registerNamespace('tempuri.org');
ITest=function() {
ITest.initializeBase(this);
this._timeout = 0;
this._userContext = null;
this._succeeded = null;
this._failed = null;
}
ITest.prototype={
MyOperation1:function(myValue,succeededCallback, failedCallback, userContext) {
return this._invoke(ITest.get_path(), 'MyOperation1',false,{myValue:myValue},succeededCallback,failedCallback,userContext); }}
ITest.registerClass('ITest',Sys.Net.WebServiceProxy);
ITest._staticInstance = new ITest();
ITest.set_path = function(value) { ITest._staticInstance._path = value; }
ITest.get_path = function() { return ITest._staticInstance._path; }
ITest.set_timeout = function(value) { ITest._staticInstance._timeout = value; }
ITest.get_timeout = function() { return ITest._staticInstance._timeout; }
ITest.set_defaultUserContext = function(value) { ITest._staticInstance._userContext = value; }
ITest.get_defaultUserContext = function() { return ITest._staticInstance._userContext; }
ITest.set_defaultSucceededCallback = function(value) { ITest._staticInstance._succeeded = value; }
ITest.get_defaultSucceededCallback = function() { return ITest._staticInstance._succeeded; }
ITest.set_defaultFailedCallback = function(value) { ITest._staticInstance._failed = value; }
ITest.get_defaultFailedCallback = function() { return ITest._staticInstance._failed; }
ITest.set_path("/AJAXFuturesEnabledWebSite2/Test.svc");
ITest.MyOperation1= function(myValue,onSuccess,onFailed,userContext) {ITest._staticInstance.MyOperation1(myValue,onSuccess,onFailed,userContext); }

which really looks similar to waht you get when you add JSON support to an ASMX web service.

Creating and using a test certificate with a WCF service

luisabreu — Fri, 19 Jan 2007 12:10:02 GMT

Since I've just lost a couple of hours trying to configure my WCF service to use SSL, I've though I'd put the steps here for self-reference.

The first thing you need to do is to create a test certificate. Since I'm running Vista+IIS 7 (workstation), I've used makecert with something like this:

makecert -sr LocalMachine -ss My -a sha1 -n "CN=url-you're-using" -sky exchange -pe

Basically, the previous command creates a new certificate and puts it in the Personal folder of the local machine store. It also configures the private key so that it needs to be exported.

After doing this, it will be necessary to export the certificate and all the certificates in the certification path - normally, one: Root Agency. Then you'll have to install them in the clients that want to use the client (normally, the root agency certificate will be installed in the trusted publishers and the test certificate should be put in the trusted people store of the local machine).

After performing these steps, you might still need to give access permissions to the private key to the service running the process that hosts the WCF service (WCF sampls have a tool called FindPrivateKey that helps you in finding the file that has the private key of the service).