Thinking about WS* and REST

In a previous post I highlighted a great webcast by Scott Hanselman on OData and discussed the metaphor he used to explain OO and SO (the Librarian Service). I’d like to continue discussing that webcast and this time turn my attention to REST and WS*.

To paraphrase Scott’s explanation,” SOAP is great for (that kind of) asynchronous message passing with the appropriate level of transactional consistency and so on, but if you just want to get a list of books and walk around in the stack of books, should I be sending asynchronous request-response messages to the Librarian Service? That’s rather heavy. I just want to see some stuff. I just want to do a “GET”. That’s what REST is all about.

REST says “We’ve got this thing called HTTP with a verb called GET and a cool addressing scheme in the URL that lets me get stuff (and we I have some other verbs like PUT, POST and DELETE that map really nicely to Create, Read, Update and Delete. So if I want to do CRUD over HTTP, the semantics are already there. So REST is about retrieving resources and sometimes about updating/modifying them.

So if we don’t get dogmatic and ‘exclusive’ about how we want to approach the system, we could now implement hybrid systems where for the CRUD , we could use WCF Data Services and OData and for the areas where we need the security , reliable messaging and to interoperate with legacy systems some of which may be using the WS* spec (for instance if we are passing money around ), then we use the ‘traditional’ SOAP approach. Most of the time we try to create artificial divisions and ring-fence our systems and tie them all to a particular approach when we really should be implementing services in a way that is appropriate for the parties/systems/people that are consuming them.

I think the final statement there is worth repeating : we should be designing/implementing services in a way that is appropriate for the scenario and consumer.

A lot of the proponents of REST (but of course not all of them) tend to be dogmatic. “WS* is evil” is the usual mantra. That’s simply not true. Sure, it is complex. Once you get past the WS-I basic profile (and even that is not implemented by everyone), things are hard. But complexity of SOAP does not negate the necessity for it nor is it an argument for a “programmable web”. What if I don’t want the web (or the part of it where my system lives) to be programmable?  I want to expose services, but i want to choose the consumers and I mandate the contract. In, say a financial services domain, for example a Payments System, I certainly don’t want my customers details to be easily available over a “GET”. Heck, no! I want the appropriate headers, I want X.509 mutual certificates, I want the whole shooting match (otherwise my customer will shoot me 🙂 ) . But if I were to build say, an admin interface, where my user base is locked down and heavily authenticated, and if there was a scenario where they needed to drill down to look at payment patterns, then sure, GET would be fine, saves me having to define numerous interfaces just to retrieve different aspects of the same thing.

Anyway, this isn’t intended to be a rant. I’m excited about the potential of WCF Data Services and OData.  In the next post, we’ll examine one of the most interesting aspects of that webcast, namely a demo of a data service with absolutely no database which puts paid to the notion that WCF Data Services is about chucking your precious DB straight into the internet. Stay tuned.

Contract First BizTalk – What’s Missing?

Although BizTalk is in many respects ‘contract driven’ (with the emphasis on first setting up the XSDs for the messages etc), WSDL First development has, IMO, always been a bit ‘iffy’. The purpose of this post is two-fold. One is to (re) start the discussion around Contract First development with BizTalk and the other is , through the discussion, to get a list of pain-points that I can go back to the product group with via our field channels and which would be of use to them in planning features for the next versions. I’m hoping that even if we cant get these into the core product, we could at least influence  and/or help set up a CodePlex project to provide some of the missing ingedients.

In v2004 (and 2006 R1) absence of support for Contract First was a huge shortcoming because we couldnt even import a WSDL let alone round-trip it while maintaining fidelity to the original. With the advent of v2006 R2 and the WCF adapters, to some extent things are better. At least we can now consume WSDL or MEX endpoints.

However, Contract First isnt just about importing WSDL. The round-trip experience and being able to maintain fidelity to the original is critical, especially in interop scenarios. While we cannot always expect service consumption and publishing to be single-click / push button, IMO, there’s currently far too many steps involved in building a provider or consumer that adheres to a supplied WSDL (and this is assuming you manage to coax it into rendering the WSDL exactly as you want).  Added to this, in the WCF world you also have to consider how you will handle strong typed SOAP Faults (when your client demands that you throw them). My esteemed colleague, Paolo Salvatori has a blog post describing how to add endpoint behaviors to a service to dynamically modify the WSDL exposed and to extend operations with fault messages. Ironically, I see this is part of the problem, namely, having to dive into so much custom code . Sure, its typical WCF, but hey, this is BizTalk, we are supposed to make the hard things easier.

The implementation of the tooling also leaves much to be desired. I don’t know of any people who still use Web Site projects as part of their automated build. Once the novelty wore off in the early days of VS2005, and once web apps came back in VS05 SP1, pretty much everyone went back to them. However, the Web Service and WCF Service publishing wizards still insist on generating website projects and there is no way to customize that to use your own template (has this changed in v2009 ?). While there is a command line tool to automate WCF service publishing, you cannot publish schemas as web services with that nor is there a command line interface (AFAIK) to automate consumption of WSDL/MEX endpoints.

Another problem I found is that Schema web services are great for one way messaging (especially when you can use direct binding so you dont have to tie an orchestration to the receive location) but if you want to expose a request/response operation, then you cant just use direct binding because the response doesnt make its way back to the required location. I read somewhere (could have been Yossi’s blog) that this is because the EPM demotes some properties. So you are forced back into an orchestration and static binding to the port. It’s not a big problem, after all the orch can be just a facade/shim, but it still feels a little dirty.

Ok, I hope that didnt come across as too much of a rant. I would like to hear your thoughts on the subject. Have I gone way off base anywhere ? Do you run up against the limitations of BTS in the Contract First (specifically WSDL First) world? What’s missing in the tooling? What should the product group (or a tool provider) be looking to supply to make things better. Do post your comments and let me know. Hopefully we can get enough consensus and ideas to provide the product group with valuable information. Let’s discuss.

WSCF blue – The Road Ahead – What does the dev community want?

WSCFblue v1 has been a really successful project and we’ve had some great discussions on the forums, feature requests (most of which we have been able to provide) and so on. For a long time the team has been thinking about the next generation of WSCF tooling, taking what we have now to the next level and we have put together a list of things for which we would love to get your feedback and ideas to help prioritise.

So here’s our laundry list. You can provide feedback here or on the CodePlex workspace where I shall put them up as work items so you can vote on them if you like.

1. T4 templates : We’ve had numerous requests for additional settings to allow users to ‘tweak’ the generated code ‘ever so slightly!’. To an extent, this can be done quickly as we implement ‘decorators’ to allow us to change the code depending on the options, but for many folk the ‘Rolls Royce’ of customising the code generation would be to control it through T4 templates. Having said this. there are (big) issues to consider. The first thing is that the onus is on the end user to not mess with the templates because T4 (as well as other code gen tools) will provide a long rope on which we could easily hang ourselves 🙂 . The second issue is that if we upgrade the templates, then again the end user  will have to migrate any customisations. So in some ways T4 could be a double edged sword.
2. Merge ‘Classic’ and ‘Blue’ : The ‘Classic’ / ASMX code generator is still available on a separate CodePlex project. While we havent made any formal MSI releases, there have been a number of contributions to the source especially to the command line options etc. While WCF is the preferred web services implementation framework, IMO, ASMX will be around for a long time and it would be useful to support that. It would be too much work for us to maintain two separate code-bases so perhaps it’s time to bring Classic into the Blue workspace.
3. API : While WSCF is primarily an add-in at the moment, it would be useful to externalize the API of the engine. The framework currently covers major services such as WSDL Generation, WSDL Import/Parsing, Service side stub generation, data contract gen and client side proxy gen and configuration management. A proper API would make it usable by other tools (such as my own MockingBird – which could ‘outsource’ the metadata import of multi-part WSDLs to WSCF) as well as other tools that developers may write.
4. Persistence + Reload of settings (all dialogs and WSDL wizard ) : For some of the code gen dialogs we allow the user to save the settings. However, this file is in the users profile temp folders. Storing these settings along with the code as well as allowing the code-gen dialogs (and the WSDL Wizard) to load a pre-existing config file would be very useful in scenarios where we only need to change one setting but dont want to go through the entire series of steps in the wizard.
5. New command line (can use “settings” files)  : The command line interface is in need of an overhaul. We could allow the user to use the ‘settings’ files mentioned above as part of the command line. The new command line would also target both Classic and Blue if possible.
6. Support other bindings : We only use BasicHttpBinding now. So far no one has asked for anything else. Should we consider adding an option to the dialogs that allow you to pick the binding (perhaps including custom bindings, say, via MEF?)
7. Customized mapping of endpoints to SVC files?  (multiple svc files) : We currently support only one endpoint (SVC file which points to the generated interface) out of the box. Business services usually have different endpoints (possibly with different bindings) to support things like customer access, management/ops access and so on. Is this something you would want ? Currently you can do this by creating another WSDL (importing the same schemas if needed) and driving the code gen from there, but since the metadata/WSDL for a service is always the same no matter how many endpoints, perhaps there needs to be an option for going from one WSDL to multiple SVC files ?
8. Incremental code-gen  (ie: what if we want to add extra operations to an SVC file or WSDL) : This is in early stages of thinking. Should the tooling allow you to add extra ops or would it be better to run the wizards again ? If we persist/re-load all wizard settings, then this wont be an arduous process anymore. I’m leaning towards the latter option because I would rather not tinker with code that could have been customized.
9. Additional behaviors :  Christian Weyer wrote a custom “FlatWSDL” behavior that allows the service to expose a single consolidated flattened WSDL. Perhaps this can be provided as one of the options for the service. Again, (via MEF) we could pick up any number of custom behaviors and allow the user to select them.
10. WS-Addressing support in WSDL wizard : The title says it all.
11. More flexible naming conventions : What would you like to see here? would T4 supersede this?
12. Contract First Workflow Services (.NET 4) : There is no support in WF4 for proper contract first development for various reasons. IMO, its more of a lack of time to provide the tooling and we may see something in service packs or upcoming versions if enough folks shout loud enough and/or if there are commercial justifications for the same. Anyway,rationale aside, is this something you would like to see in WSCF? Now do keep in mind that we havent worked through this issue in detail and it maybe that the lack of support goes beyond tooling so being able to code-gen the XAML will not provide any guaranteees it will actually work, be rendered correctly by the designer and so on.  But i think its worth considering and if you are a WF expert and have done anything in this area , we’d love to hear from you and maybe work with you on the same.
13. Integration with Service Factory : Would it be useful / make sense to link this with the Service Factory Modeling Edition (in its VS2010 or beyond incarnation). What are the touchpoints you see?
14. Feature Builder :  Now that Feature Builder has emerged as the primary vehicle for providing automated guidance, we’ve been thinking that WSCF should leverage Feature Builder. One of the reasons is that as we expand our functionality , wizards and single screen code gen dialogs are just too linear and do not provide enough guidance on what options or sets of options should be chosen for your scenario.
15. WPF UI :  We’ve (at least Alex has) been playing around with MVVM a little to see if we can rewrite the WSDL Wizard which is currently tightly coupled to the code gen engine. Given that we have opted for a full on refactoring (explained below), this may not be necessary, but on the other hand if we are going to support lots more options etc then the UI’s are going to need an overhaul. Let us know what you think of this idea.

That’s our list as it stands now. We are continuing to provide point releases of V1 but for many (if not all) the features listed above,  a full on refactoring of our code base is essential, which is already underway (For example, if we merged Classic and Blue, I would expect to be able to use the same core engine of ‘Blue’ , which evolved significantly from the ASMX days, and just ‘plugin’ the ASMX generation, but with the current code structure this is not possible). So it’s quite likely that most of the features above will be v2.x.

Please do provide your comments and feedback on the roadmap and help us to prioritise. We want to continue to make WSCF blue the premier web services development toolset for the .NET community. Looking forward to your feedback.

Parsing Multi-Part WSDLs

In the ASMX world, handling WSDL (for the purposes of say, generating code or custom documentation etc) is pretty straightforward. If you are given a .asmx?wsdl  endpoint (or even  a local WSDL file), all you need to do is instantiate a System.Web.Services.Description.ServiceDescription over it and that will give you access into all the objects that make up the WSDL (endpoints, bindings and so on). You can also  construct this class manually (if you need to) and generate a WSDL from that (which is similar to the approach we take in WSCFblue). 

However, with WCF you do not get a single WSDL with all the info, rather its split up into multiple-parts. (Also note that although you can enable metadata publishing on special endpoints or on different endpoints in a service, the WSDL is still essentially the same because the metadata is at the service level not the endpoint level, which is why the class is , rather obviously 🙂 named ServiceDescription. At first glance, one may think that the ServiceModel equivalent (System.ServiceModel.Description.ServiceDescription) will get you everything about the multi-part WSDL, but that’s not entirely true. 

In a discussion with Youssef Moussaioui on an internal forum, I gleaned the following vital nugget of info. 

“There are two different ServiceDescription classes that have *very* different meanings: 

• System.Web.Services.Description.ServiceDescription is an object model for WSDL documents
• System.ServiceModel.Description.ServiceDescription is an object model representing a WCF service”

As with most things, in retrospect it makes sense (and the object model is very rich indeed) but initially it was confusing to see that the two classes returned different properties and details about the ‘service’. 

So, if you are given a MEX endpoint (/mex or .svc?wsdl or .asmx?wsdl), how do you go about getting the metadata and using that?. The first thing to bear in mind is that the consequence of a rich object model is that the user then has to navigate a pretty deep tree to get at the data that is needed. But I must say, you gotta love the way WCF works sometimes. With the aid of 3 nifty classes , the MetadataExchangeClient, the MetadataSet (which is returned by the MexClient) and the WsdlImporter (which works on the MetadataSet) you can get pretty much everything you need. 

Here’s some sample code that can help. I chose to dump the results into the Console, but of course you could do a whole lot more (for example, in WSCFblue, we are building a ‘flat container’ that represents a WSDL, which we are going to use for some new functionality). 


// Define target endpoint
//Uri endpointUri = new Uri("http://localhost:45173/RestaurantServiceWcf/RestaurantService.svc?wsdl");

// Setup the mexClient and importer to get the metadata
MetadataExchangeClient mexClient = new MetadataExchangeClient(endpointUri, MetadataExchangeClientMode.HttpGet);
mexClient.ResolveMetadataReferences = true;
MetadataSet metadataSet = mexClient.GetMetadata();
WsdlImporter importer = new WsdlImporter(metadataSet);

 

// Now get all the metadata from the importer
Collection cds = importer.ImportAllContracts();
ServiceEndpointCollection endpointCollection = importer.ImportAllEndpoints();
Collection bindings = importer.ImportAllBindings();
XmlSchemaSet schemaSet = importer.XmlSchemas;
ICollection schemata = schemaSet.Schemas(); 


Console.WriteLine("Schemas");
foreach(XmlSchema schema in schemata)
{
Console.WriteLine(schema.TargetNamespace);
}


Console.WriteLine("Endpoints");
foreach(ServiceEndpoint endpoint in endpointCollection)
{
Console.WriteLine(endpoint.Address);
}


Console.WriteLine("Operations");
foreach(ServiceEndpoint endpoint in endpointCollection)
{
foreach(OperationDescription operation in endpoint.Contract.Operations)
{
Console.WriteLine(operation.Name);
}
}


Now, there is one limitation with the MetadataExchangeClient namely, that it cannot handle a local WSDL (makes sense, because the file system is passive and cannot obey a protocol to provide metadata). So, my WSCFblue colleague, Alex came up with a interesting approach where he downloaded all the metadata using DiscoveryClientProtocol and then picked up all the metadata documents (whether they were WSDL or XSD or Policy) and attempted to export the metadata using methods such as MetadataSection.CreateFromServiceDescription() and MetadataSection.CreateFromXsd(). These sections are then added to a MetadataSet from which we can then use the WsdlImporter to get the rest of the juicy bits. (This summarises what he did but there’s a bit more to it that I will write about a little later when we get to ship those bits).

So, there you have it. Some utility code that can get you started discovering the treasure trove that is the ServiceModel.Description.

MockingBird meets WCF in v2.0 RC

I’m delighted to announce that MockingBird v2.0 is now available as a Release Candidate.   This is the long awaited ( 🙂 ) version that adds a WCF Message Interceptor that now sits alongside the HttpHandler and uses the same generic simulation engine.

I owe this release pretty much entirely to the stellar contributions of Bram Veldhoen who wrote the entire WCF interceptor and dived into the Unity based dependency resolution and fixed a number of issues with threading and concurrency and even introduced me to the awesome (and scary) Microsoft CHESS concurrency testing tool which I’m still trying to get my head around.

Basically we have now added 2 things to the mix namely a “SimulatorService” (.svc) endpoint that implements a generic contract. The message exchange patterns are modeled after the BizTalk WCF adapters and the current set is : IOneWay, IOneWayDuplex,  IOneWaySession, ITwoWay, ITwoWayVoid and the corresponding Async interfaces (for example ITwoWayAsync ). The SimulatorService.svc can be hosted in IIS or in a ‘SimulatorHost’ console application (which also supports http and https). Although both are installed, it is not possible to run them simultaneously because of port sharing issues, so if you want to run the SimulatorHost ensure that the website that contains the ASMX and SVC is stopped.

The high level design of the system is shown in the following diagram

(If you are not familiar with it from previous versions, essentially it consists of a generic HttpHandler and a generic WCF message interceptor that can pick up any message sent to the endpoint and to respond to this message it looks at a model XML file that instructs it how to respond. All it needs to function straight out of the box is the model file which is very simple to setup)

In terms of the physical layout MockingBird is manifested as follows

• A virtual directory : This contains the SimulatorService.svc file (the WCF message interceptor)  and in the bin folder we have the Interceptor.dll which contains HttpHandler (implemented as a class that inherits the IHttpHandler interface rather than an .ashx) . The bin folder also contains the WCF Simulator Host application and a simulator host tester application. The .svc and the httpHandler both share the web.config and as explained in the technical documentation, there are a number of other .config files
• A folder (usually in Program Files) containing the Service Studio GUI application.

Please note that in the RC, due to the single package and co-location of the WCF SimulatorHost with the web application, the 4 config files are duplicated in the root of the web app as well as in the bin folder. This is intentional because the system looks for ‘sibling’ configuration files and for web apps they need to be in the root whereas for the Simulator Host they need to be co-located with the .exe.config which happens to be in the bin folder of the web app.

In v2 RTM we plan to split this up so that the simulator host is installed in a separate folder (under Program Files). This will avoid the confusion that may appear when the user sees the config files in 2 adjacent folders, however, the apps still need their own copies of the configuration files. Perhaps in a future version, we will build some advanced centralized configuration so that irrespective of the simulator chosen, the configuration is always taken from a single central location.

I hope you find this new version useful. Looking forward to the bug reports and feedback. I hope to be able to get the RTM out in a month or so (approx 20 April 2o10). Do check it out and let us know what you think of it.

AppFabric lands in VBUG (Bracknell)

Hot on the heels of my previous talk on AppFabric at SBUG, I will be reprising the talk, but with more of a Workflow Services slant at VBUG in Bracknell on Feb 15th 2010.

A big thanks to all who attended the SBUG talk and cool to see the large Avanade contingent comprising many familiar faces  🙂 . It was an interesting conversation on BizTalk and AppFabric. I will be posting more content on those topics here soon. I’ve sent the slides to Mike Stephenson and they should be available on the SBUG site soon.

I hope to be able to do more of a hands on demo of Workflow Services at the VBUG event (but that depends on Windows Virtual PC behaving properly). Still, it should be a good evening. Again, lots of known folk at VBUG and hope to see a good crowd.

Speaking on AppFabric @ SBUG

I’m delighted to be delivering my first presentation for the UK SOA/BPM User Group next week on the topic of Windows Server AppFabric (formerly code-named “Dublin”). The link to register is here and the page will be updated with the abstract shortly.

The tight integration between WCF and WF 4.0  and the hosting support in AppFabric is looking very promising now and will definitely provide a good platform for solutions which dont require BizTalk and, where BizTalk is already available, can work well alongside and integrate with it.   We’ll look at some scenarios where there may be overlap and how to approach the solution in such cases. Sure there will be some good discussions !

I know Yossi will be there 🙂 . Looking forward to catching up with some of the other UK / London gang as well.

BizTalk, WCF and the Bad Gateway

We ran into an interesting problem a couple of days ago and I decided it would be worth posting the solution in case anyone else runs into it.

The scenario involves a Windows Service communicating with a BizTalk WCF endpoint which is hosted using WCF-CustomIsolated and some fairly complex custom bindings, notably using X.509 Mutual Certificates. This is the second half of the communication, the first being where BizTalk sends a request to a vanilla WCF endpoint and gets an ACK, the service does some processing and the WinService then does a “call back” with the “real response” / outcome of the processing.  Both communication routes are secured via the same bindings. We didnt have any trouble with the transmission from BizTalk to the WCF service but the WinService initiated communication always failed with a HTTP 502 : Bad Gateway message. This had us stumped for a while as some articles we read seemed to suggest that there was a problem on the server. Now if you have looked into custom bindings and certs in BizTalk, you will know that there is some really heavy duty and scary stuff there so we wondered whether the way we had setup the certs and credentials info was playing havoc with the communication.

So I used the trusty WSCF.blue and mocked up another WCF service to mimic the BizTalk endpoint replete with the bindings (no, WSCF Blue doesnt support custom bindings yet, but will sometime soon) and swapped the URI in the WinService and it worked just fine. Still puzzled, I then created a console app to mimic the winservice and it was able to communicate with both my mock BizTalk service as well as the real endpoint. Curiouser and curiouser. At that time the only difference was in the App Pool between the BizTalk service and mock service, but i used the same app pool and still the problem only manifested between the Winservice and Biztalk.

Anyway, with some guidance from an expert colleague (who, unfortunately wasnt around when I was writing those mock clients and services) It turned out that the problem was with a setting “UseDefaultWebProxy”  in the Win Service. The difference between the WinService and the console client was that the console was running under my credentials and in the IE settings I had turned off the proxy for the specified URL so although I didnt specify the setting as “false” in the client it automatically picked up my settings. But the WinService was running under another user account, and so the system didnt care about my proxy settings and we had to explicitly set the value to “false”. 

That was it. A little setting buried deep in the bindings that caused us the grief. After sorting this out I stumbled across this post from Kenny Wolf  which points to the offending setting. Wish I had found that earlier, but then I wouldnt have realized that aspect of the console client where it picked those settings. So, hope this helps someone in a similar situation.

WSCF.blue Beta-2

Beta-2 of WSCF.blue is now available.

The big feature of this new beta is the standalone Data Contract Generation and we have also put in some other fixes and addressed some outstanding issues (as well as rolling up fixes since the last beta).

The feature list is as follows. The “More Information” links point to posts on Alex’s blog with screenshots and lots of details.

• The Generate Data Contract Code feature is now available and supports the selection of multiple XSD/WSDL source files. (More Information)
• When the Enable WSDL Endpoint option is chosen a reference to the Thinktecture.ServiceModel.Extensions.Metadata.dll assembly is automatically added.
• Support for VB.NET has been added to the code generation.
• You can choose if operation methods on the service class will throw a NotImplementedException, call an implementation method in a partial class, or will be defined as abstract methods. (More Information)
• Force the SOAP actions (Action and ReplyAction) applied to each operation contract follow the standard WCF format: <namespace>/<service>/<operation>[Response]

Hope you find this release useful. As always , keep the feedback and suggestions rolling in. Enjoy  🙂

WSCF blue: Beta-1

WSCF-blue, the WCF successor to the popular WSCF (Web Services Contract First) tool is now available in its first beta release at CodePlex. I’m delighted to be a part of the team working alongside guys like Christian Weyer, Buddhike De Silva, Edward Bakker and Alex Meyer-Gleaves.

If you aren’t familar with the tool, basically WSCF provides tooling to approach web service development in a contract first manner, specifically WSDL/XSD first rather than code-first. WSDL is often the favored ‘neutral’ ground for specifications to be agreed on in large projects where interoperability is key between heterogenous technologies. It is also common to find that the WSDL for web services is the first thing to be discussed between an application development team and a service provider (in any development / integration project). So , having a tool that allows you to work with WSDL and XSD in a consistent, reliable manner without getting bogged down in the intricacies of WSDL and associated specifications is a must. WSCF aims to address the lack of tooling in this space (especially in the .NET world).

WSCF is a Visual Studio 2008 add-in that provides the following features

• A WSDL Wizard that allows the developer to step through the creation of a WSDL from one or more XSDs
• A DataContract Generator (similar to XSD.exe, XSDObjectGen.exe and Svcutil.exe) that generates the . NET equivalent of the XSD types
• A Service/endpoint stub (SVC) generator and
• A client proxy generator.

In the current beta release, the stand-alone Data Contract generation option is NOT available, but that is something we will be addressing as a priority and should be available in the RTM release. However,  data contracts are generated as part of the service side stubs and client side stubs.

You can either install the MSI which makes the add-in available for an open solution (as the context menu for an XSD or WSDL) or if you are using the source version, you can debug the add-in directly using F5 which launches VS in the experimental hive as is normal for all add-ins.

I have been an regular user of WSCF since its ASMX days and found the quality of the code generated to be very high. We do hope you find that this tool goes some way toward addressing your needs with WCF development and are all keen to get feedback, bug reports and feature suggestions. With the number of project templates that are available for WCF (Web Site, Web Site -Remote IIS, WCF Class Library, WCF Service Application) and the rules that some of them have around structure, it has been quite a bit of work to get the features such as SVC generation sorted and I’m pretty sure that there will be other scenarios you are involved with where the tool needs improvement or enhancements.

Here are some other posts on the beta release by the other members of the team

• Next generation of a success story: WSCF.blue for WCF goes Beta 1
• WSCF.blue Beta 1 is out!
• WSCF blue – Are you doing contract first?

Keep an eye on the CodePlex space for information relating to the roadmap etc. Do check it out and let us know what you think of it.