Smart Client: So where is the End-Point?

WindowsMobileLogo 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.

   1:  <?xml version="1.0" encoding="utf-8" ?>
   2:  <configuration>
   3:    <appSettings>
   5:      <add key="MyService_Local" value="http://localhost/MyServer/Service.svc" />
   6:      <add key="MyService_Test" value="" />
   7:      <add key="MyService_Production"  value="" />
   9:      <add key="MyService_Timeout"  value="180" />
  10:      <add key="MyService_MaxReceivedMessageSize" value="65536"/>
  11:      <add key="MyService_MaxBufferSize" value="65536"/>
  13:    </appSettings>
  14:  </configuration>

The next step is to create an ApplicationSettings class that will be used to get the correct endpoints for the service.

   1:  using System;
   2:  using System.Linq;
   3:  using System.Reflection;
   4:  using System.Xml.Linq;
   6:  namespace MyClient.Core
   7:  {
   8:      public static class ApplicationSettings
   9:      {
  11:          public static string RunTimeEnvironment { get; set; }
  14:          public static string MetroServiceEndPoint
  15:          {
  16:              get { return ConfigManager.GetAppSetting("MyService_" + RunTimeEnvironment); }
  17:          }
  19:          public static TimeSpan MetroServiceTimeout
  20:          {
  21:              get
  22:              {
  23:                  int seconds = Convert.ToInt32(ConfigManager.GetAppSetting("MyService_Timeout"));
  24:                  return new TimeSpan(0, 0, seconds);
  25:              }
  26:          }
  28:          public static long MaxReceivedMessageSize
  29:          {
  30:              get { return Convert.ToInt64(ConfigManager.GetAppSetting("MyService_MaxReceivedMessageSize")); }
  31:          }
  33:          public static int MaxBufferSize
  34:          {
  35:              get { return Convert.ToInt32(ConfigManager.GetAppSetting("MyService_MaxBufferSize")); }
  36:          }
  38:      }
  39:  }

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:

   1:  internal static class Program
   2:      {
   3:          [MTAThread]
   4:          private static void Main(string[] args)
   5:          {
   6:              ApplicationSettings.RunTimeEnvironment = GetRunTimeEnvironment(args);
   8:              new LogonForm().ShowDialog();
   9:          }
  11:          private static string GetRunTimeEnvironment(string[] commandLine)
  12:          {
  13:              if (commandLine.Length != 0)
  14:              {
  15:                  if (commandLine[0].ToUpper().Contains("LOCAL")) return "Local";
  16:                  if (commandLine[0].ToUpper().Contains("DEV")) return "Development";
  17:                  if (commandLine[0].ToUpper().Contains("QA")) return "Test";
  18:              }
  20:              return "Production";
  21:          }
  22:      }

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.

Dallas GiveCamp January 15-17, 2010

GiveCamp Dallas, a.k.a. the We Are Microsoft Charity Challenge Weekend is ramping up for another amazing event!  If you’re interested in participating as a volunteer, visit, scroll down to the bottom and click on the “Start Here” link underneath the Volunteer sign.

You can also find out more information at and

We have had a great presence at this event in years past.  If you are interested in attending please let me know.


<<  April 2017  >>

View posts in large calendar

Month List