Manually build WP7 solution with MSBuild on win64

When manually building a WP7 solution file on a win64 machine make sure you use the correct version of msbuild.exe - if you don't you'll get the loads of 'failed to load assembly' messages.

The message that gives it away is 'Could not load file or assembly PresentationCore':

C:\Program Files (x86)\MSBuild\Microsoft\Silverlight for Phone\v4.0\Microsoft.Silverlight.Common.targets(188,9): error MSB4018: S
ystem.IO.FileLoadException: Could not load file or assembly 'PresentationCore, Version=3.0.0.0, Culture=neutral, PublicKeyToken=3
1bf3856ad364e35' or one of its dependencies. The given assembly name or codebase was invalid. (Exception from HRESULT: 0x80131047
)\r [C:\Work\Temp\PhoneApp2\PhoneApp2\PhoneApp2.csproj]


So get it to build you have to use the msbuild.exe from the standard .net directory - C:\Windows\Microsoft.NET\Framework\v4.0.30319.

So the following will fail:

And the following will succeed:

Read More

WP7Contrib: 'IsCachable' is here to help!

We've added the method 'IsCachable()' to the ICacheProvider to help diagnose and test suitability of entities for caching.

It can be used in a live application but we expect it to be more likely used during testing. We don't see any problems with exposing this method on the interface as it has no side affects for the entity being tested or for the cache provider being evaluated against. Any exceptions which occur whilst calling this method are caught and not exposed.

The complete signature for the method is shown below:

bool IsCacheable<T>(T value, ref IEnumerable<Type> failingTypes) where T : class;

The suitability for caching will be returned as the boolean result and any failing types are returned via the ref parameter 'faillingTypes'. Obviously the internal implementation is dependent on the cache provider being used. The method will always return true for the In Memory & Null Cache Providers because neither of these implementations have to manipulate the data being stored in the cache provider.

The implementation was initially created for was the Isolated Storage Cache Provider. This uses the SilverlightSerializer internally and historically this gave rather confusing exception messages, but since Mike has released v2 these have greatly improved (see my previous post). We still went ahead with adding this functionality to aid testing and we completed it before Mike released the new version :)

Basically the implementation re-curses the object graph extracting the object properties which are reference types and  marked for serialisation (i.e. they don't have the 'DoNotSerialize' attribute). Common types which are known to be serializable are ignored - string, List string[], List, double[]... We also ignore duplicate types as well, so if an object graph has a circular reference or a descendant entity contains a type for checking as an ancestor it will be ignored because the ancestor will have already added this to the list of types to be checked.

So lets see how this works with a simple succeeding unit test:

[TestMethod]

public void ShouldBeAbleToCacheComplexModel()

{

    // Given we have an isolated storage cache provider...

    var cacheProvider = new IsolatedStorageCacheProvider("IsolatedStorageCacheProviderTests", Enumerable.Empty<Assembly>());



    // Given we have a model we want to check for cacheability...

    var model = new SuccessfulComplexModel

                    {

                        FirstName = "ollie",

                        LastName = "riches",

                        Location = new GeoCoordinate(51.554111, -0.072784)

                    };

    model.Area = new LocationRect(model.Location, 10, 10);

    model.Stuff.Add("Stuff1");

    model.Stuff.Add("Stuff2");

    model.Stuff.Add("Stuff3");

            

    // When we test for cacheability...

    IEnumerable<Type> failingTypes = null;

    var cacheable = cacheProvider.IsCacheable(model, ref failingTypes);



    //Then we expect it to be cacheable...

    Assert.IsTrue(cacheable);

    Assert.IsFalse(failingTypes.Any());

}

The type being checked here is a relatively simple complex type! See the class diagram below, it contains 2 String properties, 2 generic collections as well as a GeoCoordinate & LocationRect property.

When we run the tests in debug when get the following returned in the output window in visual studio. The highlighted area shows the types that have been checked for compatibility with the SilverlightSerializer and since the <ROOT> type (SuccessfulComplexModel) is serializable we skip over the rest of the types because they are all descendants of the <ROOT>.
.

A failing test produces the following output in visual studio, what you can see is two MissingMethodException messages being generated. These are coming from SilverlightSerializer, the actual (exception) message is not being displayed here but it will have detailed information about the failing type (since v2 of SilverlightSerializer).

What you can see below the exception messages is the types we've attempted to serialize and you can see the <ROOT> failed to serialize as well as the descendant property 'Url' - in fact the <ROOT> failed to serialize because of the failing descendant and this is why we recurse down the object graph looking for the all types which will fail to be serialized.

That pretty much covers it, hope this helps anyone using the Isolated Cache Provider and writing tests for entities you wish to cache.

Read More

WP7Contrib: Updated version of SilverlightSerializer

Mike Talbot's release a new version of SilverlightSerializer - keep up the great work!

Mike's blog can be found here with a list of the improvements for v2.

Obviously a performance improvement is always welcomed especially on a mobile device, but for me the biggest change is the friendly exception message support he's added. Several people using the WP7Contrib had said it was difficult to debug serialisation issues when using the Isolated Cache Provider because when it threw an exception invariably it would be the 'MissingMethodException'. At best this was a good pointer to problems with serialisation at worst it gave no really indication of where to look.

So the previous version (v1) gave the following output for the Cache Provider demo in the WP7Contrib Spikes directory, when the Isolated Cache Provider is attempting to serialize the cache contents (to isolated storage on a background thread) it's throwing the 'MissingMethodException' exception. This is because I've not added the WP7Contrib Serialization Helper assembly to the collection of external assemblies registered with the SilverlightSerializer.

So after compiling the new version of SilverlightSerializer for Windows Phone (I had do this manually after getting the code from GitHub) we get the following output.

Notice the exception details, it details the type failing serialisation - 'System.Uri'. It even goes as far to state the reason - the type does not have a parameterless constructor.

So to get this working as stated above we add the WP7Contrib Serialization Helper assembly to the collection of external assemblies registered with the SilverlightSerializer via the Isolated Cache Provider, see below:

That pretty much covers it.

I've got a blog post coming about the supported I've added to the Cache Provider Interface for checking type are serializable via a method called 'IsCacheable' this will allow you to check types are suitable for caching when writing unit tests.

Read More

SilverlightSerializer MissingMethodException on WP7

I wanted to start a list of common reasons why Silverlight Serializer throws the MissingMethodException exception. First off you need to make sure you've got a WP7 build of the Silverlight Serializer - you can get a copy from the WP7Contrib code base if you don't want to build your own.

Classes causing MissingMethodException exception:

System.Uri,
System.Globalization.CultureInfo

To correct the issue for the above classes you will have to implement a classes that acts a serialization proxy, the one shown below is for System.Uri.

[Serializer(typeof(Uri))]
public sealed class SerializeUri : ISerializeObject
{
    public object[] Serialize(object target)
    {
        return new object[] { ((Uri) target).ToString() };
    }

    public object Deserialize(object[] data)
    {
        return new Uri((string) data[0]);
    }
}

As said I'm going to try and keep this upto date as I come across framework classes not supported.

Read More

WP7Contrib: Transient caching with In Memory Cache Provider

Rich and I are currently working on a WP7 application based around local content stored on the device.  This content consists of a database and a set of flat files per logical item.  The content for the application can contain many of these logical items; this is determined by the user when purchasing the application.  The content is either installed along with the application at purchase or is downloaded afterwards. The application is completely self-contained and read-only – it doesn't allow modification of content.

The application in theory has n number of these logical items; each logical item is queried for a set of data.  This data consists of information extracted from a database and flat files.  Once the data has been extracted it is then mapped into the required model.  This process could be repeated n number of times whilst the application is being used.  There is a time penalty in accessing the flat files & database to get the data.

This process is an ideal candidate for use with a caching strategy – read once and store in cache.

WP7Contrib has a defined caching strategy with several implementations, the main two being isolated storage cache provider and in memory cache provider. The first is a persistent-cache backed by isolated storage so it will survive application restarts; the other is an in-memory-only implementation which is transient and does not support application restarts.  The class diagram is shown below:

We decided to use the in-memory cache provider for this application because if we had used the isolated storage implementation we would have been extracting from one format (flat file & database) to be stored in a different format (serialized objects) in a file in isolated storage.  Adding the required serialization support to the model can be a fiddly task prone with un-intelligible exceptions when it doesn’t work.  This is true irrespective of the serialization framework you use.  In addition to this, you will still have to access the flat file and database periodically anyway, so why add the overhead?

The in-memory cache provider is a very simple implementation; it uses a Dictionary class internally with a timer to remove items once they have expired.  It is thread-safe and does not use weak references for items in the dictionary so items will not expire unexpectedly.

You will also notice from the above diagram a cache provider called NullCacheProvider.  This is as the name suggests an implementation of the ICacheProvider interface that does not do anything!  It follows the ‘Null Object Pattern’.  We use it when a component defines dependency on the ICacheProvider interface but we don’t wish to use caching, and also for measuring and testing caching implementation performance.

Read More

WP7Contrib: Bing Maps REST Services Wrapper - Deep Dive

Following on from Rich's post introducing the Bing Maps Service in the WP7Contrib I'm going to explain in more detail how we built this service and how to use the API.

Before I get into the details let’s get some background on what is provided by Microsoft out of the box.  Microsoft provides multiple APIs for programmatically integrating maps and map data into your WP7 applications as well as the UI based controls included in the Microsoft.Phone.Controls.Maps namespace. The APIs are designed to used in conjunction with the UI controls to annotate the visual elements of Bing Maps.

The Bing Maps has it's own area up on MSDN, here.


Microsoft supports both SOAP and REST APIs for accessing location, imagery, route and services information.  Each implementation has its own taxonomy and these are heavily influenced by the underlying protocol (as much as you can call REST a protocol).  The only advantage we can currently see with using the SOAP implementation over REST is the ease with which you can integrate this into your application.  In my opinion this is not a reason to use the SOAP implementation, although it may appear to be quicker and easier.
The important point to remember about using a SOAP based API (over HTTP) is the fact that SOAP is based around the HTTP POST method and is not utilising the power of the HTTP headers and caching when retrieving read-only data.  Since the Bing Maps are a read-only service, why would I want to use a protocol on top of HTTP that does not utilise the potentials of HTTP for caching out in the web?


After using both Bing Maps API implementations, we believe the REST version is cleaner, easier to understand and more powerful from a caching perspective.  After using this on several WP7 apps we found ourselves either repeating the same steps to use the REST API or copy-pasting the code project to project.  We wanted to get away from this - say hello to the WP7Contrib Bing Maps Service!

Simply put, the Bing Maps service is a client-side wrapper for the Microsoft Bing Maps REST API for use in WP7 applications. It abstracts the developer away from having to deal with REST or HTTP concerns.  It utilises Rx (reactive extensions) for exposing the request data as well as handling caching, timeouts and retry strategies.  We also provide a criteria factory to help create the required search criterion - the number of configurations a developer can use is mind boggling and the criteria factory is there to help reduce the information overload. The complexity of a criterion and the results can be seen from the number of classes required to support searching for locations, routes, imagery and services shown below:

The Bing Maps service does not expose these resource classes to developer, this is done via our model classes, see below. The resources are mapped into the model classes by the service - the reason for this distinction is that we see them as falling into two distinct areas, one fulfilling the communications side (resources) and the other supporting the application and UI side (models) via binding, equality and cloning.

The next thing to look at is the service interfaces and the methods exposed.  As I said earlier we use Rx to expose the results because all operations over HTTP are asynchronous and Rx is very well suited to handling this requirement.  The interfaces are separated into roles - an interface for location methods, an interface for route method etc.  These are then aggregated under a single interface called IBingMapsService which is implemented by the BingMapsService class.

public interface IBingLocationService

{

    IObservable SearchForLocationUsingAddress(ILocationSearchAddressCriterion criterion);

    IObservable SearchForLocationUsingPoint(ILocationSearchPointCriterion criterion);

    IObservable FindLocationUsingQuery(ILocationSearchQueryCriterion criterion);

}



public interface IBingRouteService

{

    IObservable CalculateARoute(IRouteSearchCriterion criterion);

    IObservable CalculateRoutesFromMajorRoads(IRouteSearchMajorRoadCriterion criterion);

}



public interface IBingImageryService

{

    Uri ImageryUrlForCenterPoint(IImageryUrlForCenterPointCriterion criterion);

    Uri ImageryUrlForCenterPointWithRoute(IImageryUrlForCenterPointWithRouteCriterion criterion);



    Uri ImageryUrlForQuery(IImageryUrlForQueryCriterion criterion);



    Uri ImageryUrlForSpecificArea(IImageryUrForSpecificAreaCriterion criterion);

    Uri ImageryUrlForSpecificAreaWithRoute(IImageryUrForSpecificAreaWithRouteCriterion criterion);



    Uri ImageryUrlForRoute(IImageryUrlForRouteCriterion criterion);

}



public interface IBingImageryMetadataService

{

    IObservable GetImageryMetadataForAnImagerySet(ImagerySearchCriterion criterion);

    IObservable GetImageryMetadataForAnImagerySetAtASpecificLocation(ImagerySearchCriterion criterion);

    IObservable GetImageryMetadataForABasicImagerySetAtASpecificLocation(ImagerySearchCriterion criterion);

}



public interface IBingSearchService

{

   IObservable SearchForServices(ISearchCriterion criterion);

}



public interface IBingMapsService : IBingLocationService,

           IBingRouteService,

           IBingSearchService,

           IBingImageryService,

           IBingImageryMetadataService

{

}

We also have a settings interface.  This is to allow the developer to setup the Bing Maps Service with the required config values.  This is passed to the constructor of the service and the service extracts the required values, thus preventing a constructor with 20 parameters!  The interface definition has read-only properties but the implementation class Settings allows the setting of properties as well.

public interface ISettings

{

    string AppId { get; }

    string CalculateRouteUrl { get; }

    string CalculateRoutesFromMajorRoadsUrl { get; }

    string CredentialsId { get; }

    string ImageryCenterPointUrl { get; }

    string ImageryCenterPointWithRouteUrl { get; }

    string ImageryMapAreaUrl { get; }

    string ImageryMapAreaWithRouteUrl { get; }

    string ImageryMapRouteUrl { get; }

    string ImageryQueryUrl { get; }

    string FindLocationUsingQueryUrl { get; }

    string SearchLocationUsingAddressUrl { get; }

    string SearchLocationUsingPointUrl { get; }

    string SearchUrl { get; }

    int CacheTimeout { get; }

    int Timeout { get; }

    int Retry { get; }

}

The last set of interfaces of interest is Criteria such as ILocationSearchAddressCriterion and IRouteSearchCriterion. You can see in the above code snippets these are used as parameters to the Bing Map service APIs.  They encapsulate all the parameters required for making the call to the backend service.  These interfaces are returned by the CriterionFactory class; this is a helper class and is designed to make creating a criterion easier.  The code below for the IRouteSearchCriterion inteface shows the number of properties that can be used for calculating a route.  The criterion factory makes creating these easier because it has overloaded parameter signatures for specific search requirements, e.g.  search by address only, route search using only way points, or route search using way points with mode of travel and route optimisation.  Shown below are some of the criterion interfaces.

public interface ILocationSearchAddressCriterion : ICloneable<ILocationSearchAddressCriterion>

{

    Address Address { get; }

    

    bool HasAddress { get; }

}



public interface ILocationSearchPointCriterion : ICloneable<ILocationSearchPointCriterion>

{

    GeoCoordinate Point { get; }

    ObservableCollection<LocationEntity> IncludedEntities { get; }



    bool HasPoint { get; }

    bool HasIncludedEntities { get; }

}

   

public interface IRouteSearchCriterion : ICloneable<IRouteSearchCriterion>

{

    Avoid Avoid { get; }

    ObservableCollection<WayPoint> WayPoints { get; }

    int? Heading { get; }

    Optimize Optimize { get; }

    RoutePathOutput PathOutput { get; }

    DistanceUnit DistanceUnit { get; }

    DateTime? DateTime { get; }

    TimeType TimeType { get; }

    int MaxSolutions { get; }

    ModeOfTravel TravelMode { get; }

    string PointOfInterest { get; }



    bool HasAvoid { get; }

    bool HasWayPoints { get; }

}



public interface IRouteSearchMajorRoadCriterion : ICloneable<IRouteSearchMajorRoadCriterion>

{

    RouteDestination Destination { get; }

    RoutePathOutput PathOutput { get; }

    RouteExclude Exclude { get; }

    DistanceUnit DistanceUnit { get; }



    bool HasDestination { get; }

}

The criterion factory also has simple validation rules to prevent calling the Bing Maps service with an invalid criterion, see screen shot below.

The following screen shots and code snippet bring all of the above together.  This is an example application to get the detailed address information for a post code (zip code).

This code is taken from the BingMapsLocationDemo in the Spikes directory of the WP7Contrib code base. If you use any of the Bing Map demos in the Spike directory you will have to register with Microsoft for a Bing Maps account - this can be done here.

See how simply the location can be determined for a post code - 4 lines of code!.

private void getAddress_Click(object sender, RoutedEventArgs e)

{

   var criterion = CriterionFactory.CreateLocationSearchForAddress(this.postCode.Text);

   

   this.bingMapsService.SearchForLocationUsingAddress(criterion)

      .ObserveOnDispatcher()

      .Subscribe(result =>

              {

               this.address.Text = result.Locations[0].Address.Locality;

               this.address.Text += Environment.NewLine;

               this.address.Text += result.Locations[0].Address.PostalCode;

               this.address.Text += Environment.NewLine;

               this.address.Text += result.Locations[0].Address.AdminDistrict;

               this.address.Text += Environment.NewLine;

               this.address.Text += result.Locations[0].Address.CountryRegion;

              });

}

The code below shows how the service and its dependencies are created.  The WP7Contrib is based around the idea of using an IoC container for dependencies and injecting all dependencies via constructors.  The example application does not use an IoC container but you can see how we pass the dependencies to the Bing Maps service.

private readonly ILog log = new DebugLog();

private readonly IBingMapsService bingMapsService = null;



// Constructor

public MainPage()

{

    InitializeComponent();

    

    this.log = new DebugLog();

    this.bingMapsService = new BingMapsService(new ResourceClientFactory(this.log),

            new UrlEncoder(),

            new Settings("MyApplicationId", "MyCredentialId", 10000, 5));

}

The last to area to cover is the implementation of the SearchForLocationUsingAddress() method inside the Bing Maps service.  This uses a standard approach to making a query to the backend service.  First of all we check to see if the search has already been executed and if so return the value from the cache;  if not we then instantiate the resource client and then construct the search parameters.  Finally we execute the search and persist the results into the cache.  You can also see the timeout and retry strategy.

public IObservable<LocationSearchResult> SearchForLocationUsingAddress(ILocationSearchAddressCriterion criterion)

{

    this.log.Write("BingMapsService: SearchForLocationUsingAddress...");



    try

    {

        var keyTuple = new CacheTuple<string, ILocationSearchAddressCriterion>

        {

            Val1 = "SearchForLocationUsingAddress",

            Val2 = criterion.DeepClone()

        };



        var locationResult = this.cacheProvider.Get<CacheTuple<string, ILocationSearchAddressCriterion>, LocationSearchResult>(keyTuple);

        if (locationResult != null)

        {

            this.log.Write("BingMapsService: SearchForLocationUsingAddress results retrieved from cache, hash code - {0}", criterion.GetHashCode());

            return Observable.Return(locationResult).AsObservable();

        }



        var resourceHandler = resourceHandlerFactory.Create()

            .ForType(ResourceType.Json)

            .UseUrlForGet(this.settings.SearchLocationUsingAddressUrl);



        var @params = new[]

            {

                // path parameters...



                // query string parameters...

                propertyEncoder.Encode(criterion.Address.CountryRegion),

                propertyEncoder.Encode(criterion.Address.AdminDistrict),

                propertyEncoder.Encode(criterion.Address.Locality),

                propertyEncoder.Encode(criterion.Address.PostalCode),

                propertyEncoder.Encode(criterion.Address.AddressLine),

                this.settings.CredentialsId

        };



        return resourceHandler.Get<Resources.Location.Result>(@params)

                                            .Timeout(this.timeout)

                                            .Retry(this.retry)

                                            .Select(response => {

                                                var locations = ProcessResponse(response);

                                                this.cacheProvider.Add(keyTuple, locations, this.cacheTimeout);

                                                return locations;

                                            });

    }

    catch (Exception exn)

    {

        var message = string.Format(FailedLocationSearch, exn.Message);

        this.log.Write(message);

        throw new ServiceException(message, exn);

    }

}

As I said before you can find the demo application BingMapsLocationDemo in the Spikes directory of the WP7Contrib code base.

Read More

WP7Contrib: Timing out HTTP requests on Windows Phone 7

This code uses change set #68097 of the WP7Contrib - http://wp7contrib.codeplex.com/SourceControl/changeset/changes/68097

When doing communications over HTTP we often want to set a timeout for the response.  We want the ability to handle the timeout in a timely manner when the communication with a remote server has taken too long. When using the full version of the .Net framework we have the ability to control this precisely using the HttpWebRequest.Timeout property. The default value is set to 100 seconds. Unfortunately the ability to change this property is not supported on the Windows Phone 7 platform and I suspect the value is set to 100 seconds (should test this hypothesis). Looking around on the internet there are several approaches to get around this problem using the DispatcherTimer class and explicitly disposing of the request when the timeout has been exceeded, see an example here.

When using our ResourceClient to do RESTful communication over HTTP we can leverage the power of Rx (reactive extensions) and use the 'Timeout()' method - nice simple example here. This method throws a TimeoutException when the timeout occurs.

The following example shows the implementation for the button click code-behind using the previous ResourceClient example (Google Weather API on WP7):

private void button1_Click(object sender, System.Windows.RoutedEventArgs e)
{
      this.weatherResource.Get<xml_api_reply>(encoder.Encode(location.Text))
         .Timeout(TimeSpan.FromMilliseconds(10000))
         .ObserveOnDispatcher()
         .Subscribe(result =>
            {
               var text = string.Format("Current Temp. (Celsius) in {0}: {1}",
               location.Text,
               result.weather[0].current_conditions[0].temp_c[0].data);
            
               Debug.WriteLine(text);
            },  
            exn => Debug.WriteLine("Failed, exception - " + exn.Message),
            () => Debug.WriteLine("Completed!"));
}

When executed the code outputs the following in Visual Studio:

To demonstrate a timeout we can lower the value to 10 ms, this gives the following output in Visual Studio:

Now setting a 'reasonable' value this should cover 90% of cases, but there are going to be times when we will receive timeout exceptions unexpectedly.  When this happens we want to employ a retry strategy, again Rx provides a method for this - 'Retry()'. Shown below is the code with a retry strategy of 3 attempts:

private void button1_Click(object sender, System.Windows.RoutedEventArgs e)
{
      this.weatherResource.Get<xml_api_reply>(encoder.Encode(location.Text))
         .Timeout(TimeSpan.FromMilliseconds(10))
         .Retry(3)
         .ObserveOnDispatcher()
         .Subscribe(result =>
            {
               var text = string.Format("Current Temp. (Celsius) in {0}: {1}",
               location.Text,
               result.weather[0].current_conditions[0].temp_c[0].data);
            
               Debug.WriteLine(text);
            },  
            exn => Debug.WriteLine("Failed, exception - " + exn.Message),
            () => Debug.WriteLine("Completed!"));
}

When executed the code outputs the following in Visual Studio:

The above shows 3 attempts to access the remote server and we finally see the exception bubbling up and being handled.

Now we have to decide what a 'reasonable' value for timeout is and I believe this is dependent on the application you're building and the remote (back end) services you're using. If you're communicating with an enterprise level back end  (e.g. Google API) then you're going to be able to get away with a lower value. I would start with a value around  60 seconds and do testing in the field.  When choosing a value, it is impolrtant to remember that the maximum amount of time for making a request is going to be:

        Time out x Retry = Maximum total time.

         20 secs x 3 = 60  secs

So a user could be waiting for 60 seconds for data to be returned and displayed.

There is one caveat to this strategy and that is the hard coded value used by the HttpWebRequest class. If as I suspected this is hard coded to 100 secs as described by MSDN for the desktop version of .Net, then we will not be able to set a timeout greater than 100 secs.  I've not been able to test this just yet.

So the code examples above demonstrate the use of timeout & retry with the ResourceClient directly in the code-behind.

I've also updated the weather service implementation and what you now start seeing is the cleaner approach of using the service from the code-behind (or ideally from a view model) - the service is responsible for managing the retry strategy and the code-behind use of the service has not been modified.

You can find the demo application 'CommunicationTimeout' in the Spikes directory of the WP7Contrib code base. Shown below is a screenshot from the demo application.

Read More