SCSF: Add Smart Web Reference and still access the Web Service’s authorization credentials

When using the Add Smart Web Reference recipe from the Smart Client Software Factory, it generates a proxy that wraps the original VS generated proxy.

Let’s assume we have a web service named MyService. When you add a Smart Web Reference, Visual Studio will automatically add a Web Reference to the service (a class named MyService that inherits from SoapHttpClientProtocol), and a class named MyServiceProxy, which is the class that wraps the previous one. It will also generate a bunch of other classes and interfaces to support the command queue infrastructure.

We, as SCSF users/developers, are used to add the services to WorkItem.Services collection to be consumed later in this or other modules, in the following way:

private void AddServices() {  WorkItem.Services.AddNew<MyServiceProxy, IMyServiceProxy>(); }

As you already know by now, you could get a reference to IMyServiceProxy, or even MyServiceProxy, but this wrapper does not expose any properties the original proxy had, so you can’t access the credentials for a service that do requiere some, if you don’t have a reference to the original web service proxy instance. MyServiceProxy does not inherit from SoapHttpClientProtocol so you don’t have access to any member of the original Visual Studio generated proxy class for the web service.

What the previous example does is call the default constructor on MyServiceProxy, which creates a new instance of MyService to wrap. Luckily, the wrapper has an overloaded constructor that receives an instance of the service it wraps, but the problem is we cannot specify the ObjectBuilder which instance we want to use with the previous code.

What we should do instead is the following:

private void AddServices() {  MyService myService = new MyService(); //we could store this instance somewhere for later usage if we want  myService.Credentials = new NetworkCredential(username, password); //Now we’ll create an instance of the wrapper class with this instance of MyService  MyServiceProxy myServiceProxy = new MyServiceProxy(myService); //Notice the use of the overloaded constructor  WorkItem.Services.Add<IMyServiceProxy>(myServiceProxy); }

Makes perfect sense, right? Sometimes we are so used to add web services to a workitem the other way, that when we add authentication to them we don’t see the solution at first sight.

Side comment: As many of you’d probably know, the p&p team is working on something called Disconnected Service Agent that will replace the Add Smart Web Reference recipe in the next release of SCSF, with lots of added functionality as it also uses the Offline Application Block.


  • http:// says:

    I was wondering if you can point me to some information on how to migrate to the new version of SCSF. We are currently using smart web references and I have read that recipe is not going to be available in the new version. Any suggestions?

  • http:// says:

    Unfortunately, the Add Smart Web Reference recipe was removed from the GP. You can still use the pattern, but you don’t have code generation for it. All your existing smart web refs should still work though.
    In the new version you have the ability to generate a Disconnected Service Agent (DSA), which doesn’t exactly tackle the same problem. You can get a quick and informal comparison in this forum post by Mariano Szklanny: