Alex Thissen Weblog Build 1.15.10.1971 : Web Services

Workaround for missing "Edit WCF Configuration" menu option in Visual Studio

Alex Thissen — Thu, 28 Aug 2008 09:48:00 GMT

Sometimes when you have a clean install of Visual Studio 2005 or 2008 the context menu item "Edit WCF Configuration" for a app.config or web.config will not show.

The picture above does show the menu item I'm talking about, but you may find that it is not there.

Help is at hand: there is an easy workaround. Simply open up the Tools menu in Visual Studio and choose "Wcf Service Configuration Editor". This will start the exact same tool, but doesn't open your web/app.config. Close the tool straight away and right-click you config file. The "Edit WCF Configuration" context menu should be there now.

I don't know exactly when the context menu goes missing, but I found that it occurs regularly for Virtual PC images. It might be totally unrelated to that though. The workaround works in all cases I encountered so far.

Combining AJAX and WCF 2.0

Alex Thissen — Fri, 21 Mar 2008 20:36:47 GMT

The WCF "Orcas" release (the WCF from .NET Framework 3.5 aka WCF 2.0) makes it so much easier to use your WCF service in conjunction with ASP.NET AJAX (formerly known as 'Atlas').

Before Orcas you would build a AJAX enabled (web) service by adding the [ScriptService] attribute to the service class.

[WebService]
[ScriptService]
public class MyService
{
  // Implementation details
}

The ScriptServiceAttribute enables you to reference a JavaScript proxy from your client-side JS by including

<script src="http://.../AlmostCoolestService.asmx/js" />

Notice the /js that is appended at the end. That bit is the work of the ScriptService attribute. You do not have to add the script element manually, but get that automatically when you add a service reference to the ScriptManager control in your page.

Before anything will work all .asmx requests in an AJAX-enabled website are redirected to a different handler:

<system.web>
  <httpHandlers>
    <remove verb="*" path="*.asmx"/>
    <add verb="*" path="*.asmx" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory, ..."/>
    <add verb="*" path="*_AppService.axd" validate="false" type="..."/>
    <add verb="GET,HEAD" path="ScriptResource.axd" type="System.Web.Handlers.ScriptResourceHandler, ..." validate="false"/>
  </httpHandlers>
</system.web>

This replacement .asmx handler will return JSON data instead of the usual SOAP enveloppes, allowing for easy usage from the JavaScript code.

<Side.note>

Here is a bit of JSON (JavaScript Object Notation) data:

{ "Name" : "Alex", "Age" : 35 }

Did you know that this is actually just a JavaScript fragment? Take a look at this:

var person = { "Name" : "Alex", "Age" : 35 };
window.alert(person.Age);

So, when you send some JSON data over the wire, it is very easy to start working with that data.

</Side.note>

This is quite a bit of work, right?

In Orcas we get support for JSON, URL parameters and non-SOAP XML. It also has Atlas-specific conventions such as the JavaScript proxy.

Support for calling WCF service from the client stack

Visual Studio 2008 has WCF AJAX support, meaning that the ScriptManager understands these types of services and new templates like the AJAX-enabled WCF service. The latter will automaticaly create the correct configuration and corresponding skeleton code.

Enabling a WCF service for AJAX is a decision you can make at deployment time. So, you can call into any regular WCF service from AJAX without making any changes to your implementation. You do need to make some changes, which vary based on your hosting scenario.

Let's assume you have an IIS hosted WCF service. You need to edit the ServiceHost directive in the .svc file and specify a different ServiceHostFactory implementation, like so:

<%@ ServiceHost Service="CoolestWCFService" Factory="WebScriptServiceHostFactory" %>

Here WebScript actually means AJAX-enabled.

When you host the WCF service yourself, you should edit your configuration file to enable JSON support.

<system.serviceModel>

<endpoint address="" behaviorConfiguration="AjaxBehavior"

binding="webHttpBinding" contract="IAjaxService" />

</service>

</services>

</behavior>

</endpointBehaviors>

</behaviors>

</system.serviceModel>

Note how you only need to add an endpoint behavior for enabling WebScript. This makes WCF do the same thing as ASMX web services: it can generate a JavaScript proxy when you visit the URL http://.../CoolestWCFService.svc/js. BTW, the WebScriptServiceHost automatically adds this behavior to any endpoint that has a WebMessageEncodingBindingElement in its Binding element list, but does not have the WebHttp behavior defined. If you are interested in a little more on hosting, check here (a bit dated, but still pretty much ok).

So, why would you switch to WCF services instead of ASMX services?

The separation of contract and binding:
Because the service contract and the binding are separated it will line you up better for future versions of encoding or . You will only need to change the configuration file to hook up e.g. some JSON version 2 (which might become reality to fix the recent security vulnerabilities in JSON v1). Or, you can add an application layer to expose the same service simultaneously as an AJAX and a SOAP service.
The cool features of WCF:
How are you going to protect your ASMX service from Denial of Service (DoS) attacks? In WCF you can protect your service with quotas, throttles and timeouts. There are more manageability options, such as logging, tracing and a whole bunch of performance counters. Think about the extra hosting options (e.g. self-hosted) for WCF services.
Also, Workflow Services in .NET 3.5 allow you to put a workflow inside a service which is behind an AJAX-enabled page. Compared to ASMX you could get performance gains as much as 4 times for large messages (rough estimate and preliminary results). And you get to use the HTTP programming model, such as POX and returning binary data.
The DataContract data model:
Going forward from .NET 3.0 the DataContract way of serializing is the preferred way. In 3.5 you may have noticed that Linq to SQL and ADO.NET Entities have built-in support for DataContract as well. The generated types for both Linq to SQL and ADO.NET Entities are [DataContract] types. Also, Linq to XML will have its XNode and derived types serialize to strings, so there is no problem to send them over the wire and use these in JavaScript. Furthermore, the DataContract is an opt-in model, so your type never gets serialized by accident. This is especially important, since you are sending the information to the browser client. The future directions of "Orcas+1" also indicate neat stuff to happen with the workflow data model and transformations (see this entry for a little more detail).
The future: There has been no investment in new features for ASMX since .NET 2.0 or in Orcas. Will there be for the future?

Finally, here are some characteristics of the WCF AJAX architecture:

Operation names are in the URL. There are no SOAP actions. A special operation dispatcher makes this happen.
Parameters in URLs, because no message body is available for GET requests. Again, a special formatter will take care of that.
JSON parameters in URLs (Atlas-specific) allows for complex types to be passed from the client to the service.

Are you my type?

Alex Thissen — Tue, 12 Dec 2006 06:01:00 GMT

The 15th episode of the Dutch .NET Magazine has dropped in the mailbox at Class-A just a moment ago. Inside are many great articles. There is also an article (I dare not say "one of them") written by Stefan Onderstal from Qurius and myself.

The article focusses on the problem of the default use of the code generators for web service proxies in the .NET Framework and Visual Studio 2005. It discusses three options that we considered on a project for KPN. These will generate data types for you, which is not always what you want or already have. The Schema Importer Extensions (I wrote about a fix for a generic implementation here) provide a way out in some of the cases.

The article is in Dutch, but if you got a hand on one of the magazines, you're probably Dutch anyway. Have fun reading all articles. If you aren't subscribed yet, do so right now: it's free. That should get the Dutch running. It might apply to Belgians as well.

Cheap skate way to do exception shielding in ASP.NET web services

Alex Thissen — Wed, 22 Nov 2006 05:42:16 GMT

You read it right. There is a very cheap way to shield exception information from an ASP.NET web service. Mind you, this is available only from ASP.NET 2.0 (and upwards presumably).

So, what is exception shielding for web services? Preventing potentially valuable exception information from leaking to the calling client. It’s a good security practice to shield unhandled exceptions that occurred inside your web service from bubbling up to the ASP.NET HttpHandler for ASMX. Take this web service:

[WebService(Namespace = "http://tempuri.org/")]

[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]

[ToolboxItem(false)]

public class FaultyTowers : System.Web.Services.WebService

{

[WebMethod]

public string HelloFawlty()

{

throw new ArgumentException("Stop right there, Basil!");

return "No way, Manuel";

}

The handler will take over and return a SOAP fault to the client. The <soap:Fault> element will contain (wrapped inside a SoapException) the type and message of the exception that occurred, plus a stacktrace and references to the file location of the source file. It will look like this:

<?xml version="1.0" encoding="utf-16"?>

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<soap:Body>

<soap:Fault>

<faultcode>soap:Server</faultcode>

System.Web.Services.Protocols.SoapException: Server was unable to process request. ---> System.ArgumentException: Stop right there, Basil!

at WebApplication1.FaultyTowers.HelloFawlty() in C:\temp\WebApplication1\FaultyTowers.asmx.cs:line 23

--- End of inner exception stack trace ---

</faultstring>

</soap:Fault>

</soap:Body>

</soap:Envelope>

You could jump through hoops to catch all unhandled exceptions that occur inside of your methods and throw your own SoapExceptions (in which case the exception isn’t altered). There is some guidance right here from the Patterns and Practices team.

Or you could set a new ASP.NET 2.0 diagnostics option in your web.config and let the ASP.NET runtime take care of not returning too much exception information.

<?xml version="1.0"?>

<system.web>

</webServices>

Setting the suppressReturningExceptions attribute to true (the default is false) will result in no information being included in the returned SoapException. The <soap:Fault> will now contain the following:

<soap:Fault>

<faultcode>soap:Server</faultcode>

<faultstring>System.Web.Services.Protocols.SoapException: An error occurred on the server.</faultstring>

</soap:Fault>

I say: recommended for production environments.

For a full-blown and more robust implementation, check the Web Service Software Factory from P&P and read an intro by Eric here.

Calling webservices from client-side Atlas: part 2 of 2

Alex Thissen — Wed, 26 Jul 2006 07:29:55 GMT

Part 1 left us able to call web services that are local. In part 2 we will take a look at web services that are remote to our own website that hosts the Atlas enabled page. Seems like a trivial thing to do. I mean, it’s “just” a soap call over HTTP, right? The challenge lies in the fact that the MSXML2.XmlHttp COM object is not allowed to make cross-domain HTTP requests. The solution is to bridge your call through the local website. The hosting web server will make the call on your behalf to the remote web service. The mechanism that Atlas brings is the .asbx bridge file. A bridge file defines what the remote web service looks like.

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

<input>

</input>

</method>

<input>

</input>

</method>

</bridge>

The XML fragment above defines a proxy to the remote service located at the endpoint http://localhost:8442/WebSite/GameQueryService.asmx. Although the web service might define more operations two of those are mentioned and are callable by the proxy. The input and (optional) output parameters are listed as well. The proxy is a server-side class that you must provide. I used a wsdl.exe generated proxy class and included it in the App_Code folder of the Website that also hosts the .asbx file.:

wsdl.exe /language:C# /out:GameQueryServiceProxy.cs /namespace:KillerApps.Games.Atlas http://localhost:1256/Website/GameQueryService.asmx

In the first part you already saw how the ScriptHandlerFactory class handles all requests for .asmx (local web services) and .asbx (bridge files to remote web services). To be able to call a remote service, simply list the location of the .asbx file instead of local .asmx file you saw before.

<atlas:ScriptManager runat="server" ID="scriptManager">

<atlas:ServiceReference Path="~/GameQueryService.asbx" />

</Services>

</atlas:ScriptManager>

Like before, the ScriptManager will emit JavaScript for the bridge containing an object that acts as a JavaScript proxy to the local server, which in turn bridges the call to the remote web service. The JavaScript is inserted by adding a include to the same location as the .asbx file, plus an extra /js, as in: http://localhost/GameQueryService.asbx/js. The resulting JavaScript for the bridge file above is:

Type.registerNamespace('KillerApps.Games.Atlas'); KillerApps.Games.Atlas.GameServerStatus=new function() { this.appPath = "http://localhost:8442/WebSite/"; var cm=Sys.Net.ServiceMethod.createProxyMethod; cm(this,"GetServerStatus","args"); cm(this,"GetPlayers","args"); cm(this,"__invokeBridge","method","args"); }

You can call the web service through the JavaScript object that has a “namespace” and “className” as indicated in the bridge file. The method names correspond to the defined methods. The call to the service looks like this:

function OnLoad(sender, eventArgs)

{

KillerApps.Games.Atlas.GameServerStatus.GetServerStatus

( { "serverAddress" : "213.132.174.125",

"queryPort" : 27030,

"engine" : "HalfLife" },

OnStatusComplete);

}

Notice that the bolded part is a different way to pass all parameters to the proxy. For proxies corresponding to local web services the arguments were “as always”. Now you need to define your arguments in a new Javascript dictionary. The syntax is { “parameterName1” : “argumentValue1”, “parameterName2” : “argumentValue2”, … }. After the arguments you can still provide a callback methodname, plus one for timeouts and one for errors.

You probably noticed that the service endpoint was a local address, that served as a remote web service for testing purposes. As soon as you want to access an actual remotely located web service, you will run into security problems. The bridge won’t let you call into cross-domain methods that are not marked safe. You do so by adding an extra attribute to each method that you consider safe (e.g. which transport non-confidential information, or the ones that cannot be misused)

This should get your web method calls to work. There is some mention of marking your web method calls as a WebOperation, like so:

[WebOperation(true, ResponseFormatMode.Json, true)]

[WebMethod]

public ServerInfo GetServerStatus(string serverAddress, int queryPort, GameEngine engine)

but I haven’t found a situation yet where this is actually necessary to do.

Fixing the Shared Type Schema Importer Extension for nullable value types

Alex Thissen — Mon, 24 Jul 2006 20:11:44 GMT

When you add a Web Reference to your project, Visual Studio will also import all schema types defined in the WSDL’s schema section. You can create a schema importer extension (SIE) to influence the way the XSD schema types are mapped to your CLR types. There is a very nice article by Jelle Druyts on a SIE that shows how you can create a extension that will map based on an XML configuration section in your devenv.exe.config file. Go read that one first, then read on.

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

<mapping xmlNamespace="http://schemas.samplebusiness.net/SharedTypes"

xmlTypeName="Customer"

clrAssemblyPath="C:\Sample\SampleBusinessTypes.dll"

clrClassName="SampleBusinessTypes.Customer" />

</sharedTypeMappings>

</schemaImporterExtensions>

It a reasonably straightforward process of looking up the imported XML element name and namespace in the mapping elements and adding returning the mapped CLR class name instead of the 1–1 mapping that would normally occur. We are using this schema importer extension on a project, but project-colleague Frans Harinck found that it did not map nullable enums correctly. So I ventured out to fix this.

The problem is that nullable value types on the web service will now have a xsd:nillable=”true” attribute set in the WSDL schema. This was always true for reference types, which (of course) can have a null value. Value types couldn’t until .NET 2.0. The SIE from Jelle did not take this into account (although SIE was introduced in Visual Studio 2005). When you debug the SIE (side note: Set the build path directly into the folder C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies and attach the debugger to another VS2005 instance. In the attached instance Add or Update a Web Reference and your breakpoints should be hit), you will see how the name and namespace of your nullable value type pass by. These are mapped to your own CLR type, but not as nullable. You can determine whether your type is marked xsd:nillable=”true” by evaluating the XmlSchemaObject object supplied. This indicates that the corresponding schema element is nillable, and that it is a simpleType. The combination tells you the type is nullable. So instead of returning the mapped CLR name, it should return System.Nullable<CLR name>.

Below is the bolded change you need to make to the source code from the article, i.e. the SharedTypeSchemaImporterExtension.cs file to be exact.

public override string ImportSchemaType(string name, string ns,

XmlSchemaObject context, XmlSchemas schemas,

XmlSchemaImporter importer, CodeCompileUnit compileUnit,

CodeNamespace mainNamespace, CodeGenerationOptions options,

CodeDomProvider codeProvider)

{

try

{

foreach (SharedTypeMappingElement mapping in

SchemaImporterExtensionsConfiguration.Instance.SharedTypeMappings)

{

// Check if the namespace and type name match.

if (mapping.Matches(ns, name))

{

// Add an assembly reference.

if (!string.IsNullOrEmpty(mapping.ClrAssemblyPath))

{

compileUnit.ReferencedAssemblies.Add(mapping.ClrAssemblyPath);

}

// Indicate that no XML schema type should be imported but that a

// well-known shared CLR type will be used.

// Valuetypes can be nullable in .NET 2.0

XmlSchemaElement schemaElement = context as XmlSchemaElement;

if (schemaElement != null && schemaElement.IsNillable &&

schemaElement.ElementSchemaType is XmlSchemaSimpleType)

{

return String.Format("System.Nullable<{0}>", mapping.ClrClassName);

}

return mapping.ClrClassName;

}

catch (Exception exc)

{

System.Windows.Forms.MessageBox.Show(exc.Message + Environment.NewLine +

exc.StackTrace, "SharedTypeSchemaImporterExtension Exception",

System.Windows.Forms.MessageBoxButtons.OK,

System.Windows.Forms.MessageBoxIcon.Error);

}

// No match, delegate to the base class.

return base.ImportSchemaType(name, ns, context, schemas, importer,

compileUnit, mainNamespace, options, codeProvider);

}

Calling webservices from client-side Atlas: part 1 of 2

Alex Thissen — Thu, 20 Jul 2006 21:05:14 GMT

The March and May 2006 CTP’s of Atlas introduced two formal ways to call web services from a web browser. The difference is in the location of the web services.

Local web services
Remote or external web services

Atlas makes it really easy to call web services when they are local, i.e. reside in the same website as your Atlas-enabled web pages. You can create any ordinary .asmx web service and it will be callable from client-side JavaScript. Sure, you need to do some extra things, but there are no requirements to your service. Let’s take a look at how this works. Full source code is included at the end.

Say we have a web service GameQueryService.asmx whose class is defined like so:

[WebService(Namespace = "unr:www-killerapps-nl:services:games")]

[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]

public class GameQueryService : System.Web.Services.WebService

{

[WebMethod]

[XmlInclude(typeof(HalfLifeServerInfo))]

[XmlInclude(typeof(SourceServerInfo))]

public ServerInfo GetServerStatus(string serverAddress, int queryPort, GameEngine engine)

{

// Not relevant

}

We want to be able to call this web service from JavaScript. In an Atlas enabled .aspx page there is always a atlas:ScriptManager control present. You need to reference the web service from there.

<atlas:ScriptManager runat="server" ID="atlasScriptManager">

<atlas:ServiceReference Path="~/GameQueryService.asmx" />

</Services>

</atlas:ScriptManager>

<div id="serverNameLabel">Loading server information...</div>

Now, the scriptmanager will do loads of things for you. First of all, it will generate JavaScript code that represents a proxy to this very web service. It makes the service available through calls as simple as this:

GameQueryService.GetServerStatus("213.132.174.125", 27030, "HalfLife", OnStatusComplete);

That is almost exactly like a regular C# call to a proxy generated by wsdl.exe or Add Web Reference. The first three arguments are the ones from the WebMethod. The last one is the name of a callback JavaScript method that gets called when the call has completed.
The magic behind the scenes is done by a different handler of .asmx requests. Web.config defines a new HttpHandler for .asmx and ties it to a ScriptHandlerFactory, allowing regular GET requests on the web service. GET requests are not supported by default in ASP.NET 2.0.

In part 2 we will get to the .asbx extension.
You can switch off the ability to reach local web services from GET request, but this is enabled by default from the web.config

<microsoft.web>

Let’s say we want to call this web service when the page loads. You might be tempted to use the onLoad event of the BODY tag to wait for the page to finish loading. You should not do this. There is a slight delay between the loading of the page and the generation of the JavaScript proxy. Instead you must trigger the call to the proxy via the Atlas application object:

</application>

</components>

</page>

</script>

The OnLoad method is called when the application has finished loading.

function OnLoad(sender, eventArgs)

{

GameQueryService.GetServerStatus("213.132.174.125", 27030, "HalfLife", OnStatusComplete);

}

function OnStatusComplete(result)

{

if (result == null)

{

alert("No response received");

return;

}

alert(result.ServerName);

}

</script>

The callback function expects a single parameter which is the result of the web service call, provided that no error or timeout has occured. In our case the result could be a null reference, so we need to test for that. But, if it is not, then you can access the result. We receive a ServerInfo (or one of its derived classes) object. The coolest thing is that you can access the properties of the result as if it were the actual C# object. That’s why you can access result.ServerName, because ServerName is one of the properties from the ServerInfo class.

You should also include a mechanism to catch timeouts and errors. For that, simply create a set of two JavaScript methods and pass the names of them as the last two arguments of the previous call to the proxy:

GameQueryService.GetServerStatus("213.132.174.125", 27030, "HalfLife", OnStatusComplete, OnTimeout, OnError);

function OnError(result)

{

alert('An error has occured. Details are listed below:\n' + result);

}

function OnTimeout(result)

{

var serverNameLabel = new Sys.UI.Label($('serverNameLabel'));

serverNameLabel.set_text('The gadget did not respond in time.');

}

The OnTimeout method has another bit of client-side Atlas, manipulating the DIV with an ID of serverNameLabel through DHTML.

Calling your web service’s methods turns out to be not that complicated. Things change a little when you try to access a web service that is not in the same domain. We will cover bridging such calls in the next part.

File Attachment: LocalWebservicesAtlas.zip (425 KB)