.NET « Will’s Blog

Posts archived in .NET

March 16, 2008

Two WCF Stumbles

Here’s two things that caused me a bit of pain when working with WCF. Hopefully these pointers should help you get back to more productive things.

No Output when returning Serialized / Serialised objects.

I had been working on adding a significant number of methods and properties to a series of classes, and when I went to test the service I got literally no output.

Debug points indicated that all properties were there, and valid – but still WCF wasn’t returning anything. There was no exceptions being returned to the client.

The best tool for debugging these sorts of solutions is to first of all enable Tracing and MessageLogging. This is done via the WCF Service Configuration Editor, on the Diagnostics tab.

Once you’ve done that, and re-run the projects – you can open up Service Trace Viewer. For me under Visual Studio 2008, this was under Microsoft Windows SDK v6.0A > Tools.

This tool then lets you open up the trace log generated in your solution directory, and see all the activity that’s been happening.

debugging-wcf-services

From here, it was just a matter of scrolling down to the activity entry that had the yellow hilighting (indicating a warning), selecting it – then clicking on the Errors.

For me, the first time this happened to me, it was because I had stuffed up the DataMember Name values. It has also occurred for other reasons, such as a property not being populated, when I had specified that it was both required, and also that it could not emit a default value.

Can’t get mex to work

No, this isn’t a misguided racial slur. I was having issues setting up the mexHttpBinding on an ASP.NET AJAX WCF Service.

The solutions all point towards the same thing, that you need to set up an endpoint, and set the contract to IMetaDataExchange, then set the behaviour to have <serviceMetadata />. Except that it just wouldn’t let me add that property to my endpoint behaviour, and whenever I changed it to a service behaviour it would then not allow me to set the other properties I needed for that.

Well, perhaps I’m particularly slow – but hopefully this pointer will help someone else.

1: Create a NEW service behaviour:

<serviceBehaviors>
  <behavior name="MyServiceBehavior">
    <serviceMetadata
      httpGetEnabled="true"/>
    <serviceDebug
     includeExceptionDetailInFaults="true"
     />
  </behavior></serviceBehaviors>

2: Add a new endpoint to your existing service

<endpoint
   address="mex"
   binding="mexHttpBinding"
   bindingConfiguration=""
   contract="IMetadataExchange" />

3: Add the behaviorConfiguration you added in Step 1 to the Service (NOT the endpoint).

<service
  behaviorConfiguration="MyServiceBehavior"
  name="MyProject.MyService">

I kept trying to add it to the endpoint, and failing miserably. So much time spent back-and-forth on this!

That’s it for this instalment of “WCF is great, but I wish the config was a bit easier to understand”. Stay tuned for more exciting episodes!

1 comments

March 13, 2008

WCF Service Giving Blank or No Response

Today I spent about half an hour banging my head against this problem:
Whenever I would try and return a business object, I’d simply get no response from my WCF Service. Litterally nothing.

The problem turned out to be that I had accidentally specified the DataMember Name of a property in a sub object twice.

So, I had my broken class set up like:

[DataContract(Name = "MyClass", Namespace = "Example")] public partial class MyClass { [DataMember(Name = "property1")] public int Property1 { get; set; } [DataMember(Name = "property1")] public string Property2{ get; set; } }

An instance of this class was used as a property in another object, which was being returned from WCF.

.NET didn’t throw any sort of error unless I tried to return just “MyClass”.

Sure, it was my fault, but if you have a complex data structure, this could get awefully difficult to find without some sort of message from WCF.

Yes, this is part of that ultra nifty WCF JSON .NET 3.5 Flex project at work.

0 comments

March 8, 2008

LINQ to SQL, WCF, JSON and Flex. Oh My.

(A note to readers: This is all pure geek/coder content – Please skip this if nothing in the subject line makes sense)

I started on a new project at work for a client a bit over a week ago, by virtue of the requirements, we decided to investigate the use of new version of Microsoft’s .NET Framework, Version 3.5, for all of the server-side services.

Microsoft have been quite strongly pushing the benefits of the new features of .NET 3.5. There’s been a few key features which are particularly interesting, and if all goes according to the marketing hype, should end up saving a huge amount of time and effort, whilst ensuring that we use well known and standardised interfaces.

What features?

Windows Communications Foundation (WCF) is particularly interesting because it promises to let you (mostly) remove the whole ‘how’ and ‘where’ portion of communications between tiers, and let you focus on the ‘what’ and ‘when’.

In essence, WCF should let me state that I want to create (say) a Web Service, that accepts information in format X, and outputs responses in some other format. It doesn’t have to be a Web Service either, it could be a Peer to Peer network speaking in straight binary streams.

For this project the client-functionality is all in Flex, so we need to ensure that the Flex guys can quickly decode all the responses and turn them into Action Script objects. Through a bit of experimenting and application prior experience – Web Services speaking JSON appeared to be the easiest and most light weight method of doing this.

Language Integrated Queries (LINQ) is another particularly interesting technology, particularly because it lets me focus on what I want to do with the data I have, rather than spending time transforming it from the Database tables, rows, and procedures, into .NET objects and methods.

There are a number of implementations of LINQ, which enables you to query a variety of sources – the one that I’m most likely to use is LINQ to SQL (talking to SQL Server). Regardless of what I’m accessing however, the syntax is identical – again, removing the need to modify my code if I need to query an XML file, Oracle or MySQL Database, or even native .NET objects.

You can probably see a common theme here – WCF lets me focus on communication with the outside world without needing to write that interface or conversion functionality, and LINQ lets me access and manipulate data, without needing to write that interface either.

So, it’s all plug and play?

Well, that depends entirely on what you’re doing with your data. If you’ve got something like a CRM application where the client is responsible for managing (most of) the data, then yes it can quite possibly be almost plug and play if you’re going with a “CRUD” interface.

If your data structure is more complex, then you need to determine exactly where the split is. In this specific project, I’m presenting an abstracted view of the data that the client needs, and doing all of the business logic to manage data management in the SQL and Web Services Layer.

So far, the whole WCF and LINQ combination looks good. I’m hoping to post some more detailed posts later on.