Hi, if you want to know what has SCSF development team been doing for the next release, check out Juan Argüello‘s post here: http://staff.southworks.net/blogs/jarguello/archive/2007/03/22/Smart-Client-Guidance-development.aspx

Great job!

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.