In my last post about my adventures in Smart Client land I talked about Using WCF Services with Smart Client Applications. In this post I wand to talk about how you can make things like database and service end-points dynamically adjust for different deployment scenarios.

Being a developer at a large corporation presents challenges not faced by those who develop and then deploy to a public customer web hosting. My company has a fairly rigorous deployment strategy. While it is designed to safeguard our production environment from any unwanted changes it presents some difficult programming challenges. At my current employer we have 3 main environments, development, test, and production. The difficulty comes in when you start making database connections or use web or applications services in you application, since each environment will have different connection information.

In this post I am going to detail a possible solution to this issue that I used on my current project, which is a Smart Device project that uses WCF Services on a handheld device to talk to our business layer and data provider. There aren’t any database connections from the Smart Device so all of the examples here will deal with changing application service end-points. Please not that this technique would work equally well for database connection info.

The setup, a Smart Device application targeting the .NET Compact Framework 3.5 and using WCF Services. When I develop I want the services to point our local machine, likewise, when the application is deployed to Test and Production the services should point to the correct resources in that environment.

The first pieced information the application needs to know is what environment are it is currently running in. I have used different methods to configure this in the past, a setting in the machine.config (for web applications), or a setting the in the app.config for windows client. In this case I decided to go with a command line argument to simplify switching from one environment to another. I realize this may not be the best solution, but with the limited access to the OS on the Smart Device I felt changing a shortcut was much easier than trying to dive into the file system and make changes to a config file.

Command line arguments to be passed:

Local, to use local services

Test, to use services in the Test environment

null is passed telling the app to use services in the Production environment

Now put the endpoints for each environment in the the config file using the following naming convention: Name_environment where environment is Local, Test, or Production.

This simple implementation does exactly what we want, given a known environment it will return the correct value from the configuration file. If the runtime environment is set to Local it will return the information from “MyService_Local”, and adjust for each environment we are in.

So earlier I stated we need to know what environment we are in, this is still unknown. A command line argument has been defined but hasn’t been used to connect the request and the application settings together. The ApplicationSetting class has a property for RunTimeEnvironment and this will need to be set when the application starts.

Here is what the Main function looks like from the Smart Device application:

The GetRunTimeEnvironment method sets the correct ApplicationSettings.RunTimeEnvironment property based on the command line argument. Now we have tied it all together and can change the end-points of our applications services simply by changing the command line in the shortcut on the device.

I hope that has helped ease some of the pain of working with Smart Device applications and using WCF Services. I have learned a ton about using Smart Device project and the limitations of the .NET Compact framework. I can’t wait to get back to development on the full framework, which will hopefully be soon.

The current project I am assigned to at work is Smart Client application running own Windows CE that communicates with WCF Services that it uses to communicate with SAP via BizTalk Services. We choose to use WCF because of the power that we felt it would bring to the solution. What we didn’t realize was the limited support in Visual Studio for consuming WCF Services for a Smart Client application.

In a WinForms application you have two choices to add an Application Reference to your project you can use the SvcUtil.exe or you can right click on the References node of the solution and select Add Application Reference. In the Smart Client world you don’t have either option, you can try to use the SvcUtil.exe but it will not create a proxy that can compile against NetCF libraries because NetCF does not include all the classes referenced from that source code.

Fortunately we found the Power Toys for .NET Compact Framework 3.5 which contains NetCFSvcUtil.exe that could be used to generate NetCF complaint service proxies. Once install the power toys you will find the NetCFSvcUtil.exe in the C:\Program Files (x86)\Microsoft.NET\SDK\CompactFramework\v3.5\bin directory.

We setup a batch file to generate the service files for us. So, all we had to do was make sure we check out the files and then run the command file to update the proxies and check the files back in and we are good.

You should be aware that NetCF does not support all WCF Bindings, it supports: BasicHttpBinding, CustomBinding, WindowsMobileMailBinding, and ExchangeWebServiceMailBinding. Andrew Arnott has a post about The WCF subset supported by NetCF and other good information.

This will generate the CFClientBase.cs and the MyService.cs files we need to access the WCF Service. If you want to control the namespace that the proxies get created in you can use the /namespace argument to specify this.

There are a lot of other options you can use to control how the proxies are generated you can execute NetCFSvcUtil.exe /? to see all of them and what they do.

This gets you up and running with WCF Services in a Smart Client application, without the robust configuration that is offered with WinForms or WebForm projects. In my next post I will walk you through how we configured our WCF Service endpoints and set some custom binding information to control how our clients behaved when consuming the services.