Ok, I’ve just started working with Microsoft’s Distributed Caching API (aka “Velocity”) and while I’m very happy with the features thus far (can’t wait for notifications!), I really think the API needs a TryGetValue method. Right now you have the Get, GetAndLock and GetIfNewer methods and all of those return type Object. My suggestion is two-fold: Add the TryGetValue method with similar overloads to Get. Return a bool which, if true, indicates the item was found. Take it a step further and make the method generic. This will help when working with simple...

I sat in on a very informative roundtable discussion about WCF tips, tricks and pitfalls this afternoon here at the MVP conference. In that discussion one of the topics that came up was load balancing. After some brief discussion, I chimed in with a pitfall that people would need to watch out for which is that, if they're using something like a BIG-IP box from F5, which proxies SSL communication for them, they will have problems getting their message credentials to flow through to the actual web server since communication between the F5 and the web server is done over...

Alright, I'm reaching out via my blog for anyone in the NYC area who has strong experience writing web services and wants to join an awesome team, using awesome, bleeding edge technology to develop an enterprise level API for Mimeo. Skills required: At least 5 years programming with C# and .NET Must understand .NET 2.0 concepts such as generics, anonymous methods, etc. Strong understanding of and production experience with WCF Must be able...

For those who may not already know WCF that well, FaultException is a special type of exception class that exists as a way for those of us who are writing service operations that need to throw errors to indicate to those who are extending the WCF stack that "hey, I want the details of this exception to be passed through to the client". The whole purpose of FaultException is so that if something like a database statement fails unexpectedly deep inside the implementation of your operation, the details of that exception, which may include sensitive SQL syntax or schema object...

I've been doing a lot of digging around System.ServiceModel.Web lately and have come across a subtle difference in the way the XML is produced for POX endpoints when switching between BodyStyle.Bare and BodyStyle.Wrapped[Response]. The quick and dirty explanation, if you're using Bare and you return a DataContract with Name="Foo", the name of root element returned will be "Foo". If you're using Wrapped however, the root element will be a wrapper element named "<YourMethod>Response" and that will contain a child element named which will be name "<YourMethod>Result" instead of "Foo". For full details, including sample XML output, check out this...

I have been playing with this System.ServiceModel.Web for about a week now trying to get real world prototypes together and, in addition to having a hard time understanding some of their design choices with regards to how/where they plug into WCF, I have come across at least two major limitations. I'll start with brief descriptions of limitations and then elaborate below: You cannot mix WebInvoke decorated methods that specify a UriTemplate with the enableWebScript behavior that is meant to provide compatibility with the JSON protocol (i.e. application/json) that ASP.NET AJAX uses. See my post here on WCF...

I've reported a bug over on connect with the full details, but basically what it boils down to is that there's no way to raise exception detail from ScriptMethods when ASP.NET custom error handling is enabled. What happens is that the RestHandler for ScriptMethods detects the custom error handling is enabled and literally throws out all the details of the exception and returns a generic message instead. This pretty much makes it impossible to know what happened on the server. Did it fail to connect to the DB or was there a business logic problem that the user needs to...

I was having a problem with serializing a FaultException that had a custom details class that was a collection. Today I figured out that, when using the DataContractSerializer, you need to make sure you provide a setter implementation even for your collection based properties. Once again, this is a departure from the way that the XmlSerializer works. I'm trying to work through the scenarios where this is any kind of improvement over XmlSerializer, but I cannot think of any problem this solves. Welp, I hope this saves someone else some headscratching. I truly hope Microsoft lifts the restriction of only being...

So a couple days ago I posted an entry about how to implement a custom transport that allows you to send message credentials over plain old HTTP. Unfortunately when I rolled this into the test environment where I had all the "real" infrastructure in place I ran into a new problem. It appears that the username token implementation built into WCF has some hardcoded logic for how it deals with addresses. I have filed a bug over on Microsoft Connect and I hope that Microsoft addresses it soon. Lately they haven't responded to a single post I've made about WCF...

Since I have to define my fault details with DataContractSerializer attributes for now (I hope it's only for now anyway), I was looking at how to translate a property that was previously serialized by the XmlSerializer using XmlArrayAttribute and XmlArrayItemAttribute. Well, I figured out pretty quick there was no equivalent, found CollectionDataContractAttribute, but thought "noooo, this can't be the only way... can it?". Unfortunately a quick search revealed this post by Christian Weyer that confirmed my fears. Why oh why do I have to go writing a whole new collection class now just to decorate it with attributes when I could...

Just found out WCF does not supporting XmlSerializerFormat for custom fault details (see note under Creating Strongly Typed Faults section here). Everything else in my contracts is defined using this approach and now I have to use DataContracts for my fault details? What's up with that? Seems superbly  lame and inconsistent to me. Gonna have to take this one to the forums and possibly to the bug database... Update: No response to my forum post as of yet, so I entered a bug. Go vote on it if you agree that this inconsistency in the API is "teh suck".

I asked a question in the forums a week or so ago about how one could go about getting username credentials to be passed through HTTP. The problem is that, out of the box, WCF will not allow you to specify message credentials without using a secure transport. This is probably a really smart move for Microsoft because it will prevent people from exposing their credentials. While it certainly causes headaches with development since you need to configure certificates on all your dev boxes, that's probably still not a good enough reason for Microsoft to allow message level credentials go over HTTP...

In my last post about providing custom context I described a way that allowed you to scope the context to the operation/method level. This time I'm going to show you a way that will allow you to scope your context to the service instance level. As you may, or may not, know there are a few instancing modes for WCF services. Per-Call, Per-Session, Shareable and Single. Not only that, but someone could technically invent their own mode of instancing by implementing a custom IInstanceContextProvider. Anyway, despite which mode is used, you may want to tie your custom context to the instance of the service and...

First off, I'd like to say that I absolutely love how extensible WCF is. So far there hasn't been anything I can't do. Unfortunately the documentation, examples and guidance around extensibility is still lacking a bit at this point. This is somewhat disturbing considering that RC1 just went out. Now, on to what I really want to talk about here: providing custom context to your service implementations. We have an in house framework here at Mimeo, called our system framework, that provides some context much like System.Web's HttpContext or even System.ServiceModel's OperationContext. This in house framework exposes the current instance via a Current property (again, just...

Inspired by Craig's MSDNMan, Ian has created an MSDN browser with WPF. If, like me, you read a ton of MSDN content every day, both of these tools are extreeeemely welcome additions to browsing the online content or using the installed version of the content.

Currently blogging from my little hotel room desk at the Wilshire Grand. I'm in room 446, my cell is 973.699.0532. Feel free to give me a buzz if you'd like to chat or grab some grub. One thing I will say is that there is already a larger female presence here at this PDC than I've ever seen at any previous PDC. Unfortunately, just as I was reflecting on and being impressed by that, I was sadly reminded as to why there aren't more women in this business by some childish, chauvinistic guys cracking the usual slew of jokes on my bus ride back to the hotel from...

Well Yahoo has released their search engine web service APIs. The fact that they chose to ignore industry standard communication protocols (SOAP + WS-*) was just a bad decision IMHO. Now all the toolkits that exist for various languages/frameworks are useless in helping the programmer develop against these APIs and everyone must roll their own XML parsing. Something that could have taken ten seconds of running your favorite language wrapper generator now boils down to you having to write extensive amounts of XML generation/parsing logic. I see they released some sample client implementations for ECMAScript and Java, but noticeably absent is an sample...

So I jumped into a discussion on microsoft.public.dotnet.framework.webservices where the author asked the best way to send DataSets over web services. One of the initial responses was basically (to paraphrase) “...just pass it as strings and use GetXml, ReadXml to dehydrate/rehydrate the DataSet...”. The author of said post has, IMHO, been trying to tap dance out of that statement, but he only seems to be digging himself deeper. Anway, I leave the reading of that thread up to you if you're interested. The real reason for this post is the ever increasing scenario where I see people recommending passing strings of...

I just noticed Amazon is beta testing a Message Queuing Web Service (via TSS.NET). What has me scratching my head here is, what exactly is Amazon doing here? Are they getting into the software business now? Previously everything they've released has been to enable them to sell more goods, but this service seems like it's a pure software product completely separated from any of their other business activities. Anyway, it's worth checking out and should be interesting to keep track of...

Ok, so the question in the title a little misleading... I actually know why it's abstract, but what I don't understand why it was designed that way. It forces me to always subclass it and add my own methods, decorated with SoapMethodAttribute, just so I can send a SoapEnvelope from client to server. What's lame about this is that all the information I need to send is in the SoapEnvelope already. I shouldn't need to pass it through some special method decorated with one attribute to set the SOAP action. I understand that this design is intended to simplify the strongly...

I was reading Don's blog this morning and he links to Aaron's post about designing web services with the "contract first" mentality. Here's my two cents: To answer question #1: Yes, I absolutely believe in contract first. Defining web service should be no different than defining any other API. You define your interfaces first using the interop standard and then use whatever technology you can find to provide the underlying implementation. If you ever find fragments of your underlying technology bubbling up the contract level, you know you've done something wrong. Therefore I suppose the answer to question #2 is...