Azure App Service: Offline Sync – Do not use CreatedAt for Display

In the Azure App Service Mobile Client Offline Sync:

With offline sync, the CreatedAt field for a new record that has not been synced is null. If you set CreatedAt to DateTime.Now or another value, on sync, CreatedAt will be replaced with the DateTime of when the sync occurred (used for incremental syncs among other things). If you need to have a created time that corresponds to the actual time the user created the record, created your own property, say DateUTC, and set it yourself to DateUTC.Now;. This value will not change. The only concern with doing this is if the user somehow has the date wrong on their device, the DateUTC will be wrong as well. Hopefully everyone has figured out that having their device date/time set automatically is a good thing.

Update Azure App Service Mobile Apps Beta to GA (General Availability) for Production

Microsoft has gone GA (General Availability) with the new Azure App Services Mobile Apps which means it is available for production use!

To update to the latest NuGet packages, you’ll need to remove the WindowsAzure.MobileServices* packages from your projects and add the new Microsoft.Azure.Mobile.Client* (currently 2.0.0) packages.

No code changes are necessary because even though they changed the NuGet package name, the dll names and namespaces have not changed.

From Xamarin Studio:
Azure Mobile Client SDK

Local Debugging with User Authentication of an Azure Mobile App Service

Local debugging of an Azure Mobile App Service can be a real timesaver, however, using provider authentication such as Facebook or Google throws a wrench in process. In the past, I resorted to logging on the server side and viewing the streaming logs. This was cumbersome and not to mention time consuming. Thankfully, that can be changed. Local debugging with user authentication of an Azure Mobile App Service is now super easy.

Thanks to the documentation, I knew it was possible, but a few things weren’t entirely clear. The steps below bring everything you need to configure local debugging with authentication into one place.

I assume you are working with the following:

In the [Project]/App_Start/Startup.MobileApp.cs file of your Mobile Apps Service, add the following highlighted code:

You’ll need to grab the WEBSITE_AUTH_SIGNING_KEY for your service. This key is highly sensitive and should never be included in a client application. This should be only used on the service side.

  1. Open a browser and navigate to https://{servicename}, replacing the {servicename}. This will take you to the Kudu settings.
  2. If you do not know your Service Name, you can find it as follows:
    1. Login to the Azure Portal.
    2. Navigate to your App Service.
    3. Click on Tools in the top bar underneath Mobile App Code.
    4. Under the Tools, find Develop and then click on Kudu in that section.
  3. You should now be on the Kudu settings site mentioned in step 1. Click on Environment on the top navigation bar.
  4. Search for “WEBSITE_AUTH_SIGNING_KEY” without quotes. It should be under the environment variable section.
  5. Copy this value for the the next section.

Still in your Mobile Apps Service, in the [Project]/Web.config, add the following highlighted code making sure to replace the {} items with their appropriate values:

In your Mobile App using Azure Mobile Services (in my case, this is for a Xamarin Mobile App) you will need the following code where you are currently instantiating your MobileServiceClient:

The key issue I was running into originally was that I did not set the AlternateLoginHost  to the actual service. This had resulted in a 404 error being displayed on my mobile app when clicking an authentication provider. Setting the this value makes all authentication calls still hit your Azure Service while your data calls hit the local service for easy debugging.

Note: This does not allow you to debug your service with authentication without an internet connection. You will still need an active internet connection, especially if your service hits other services. An example would be calling  GetAppServiceIdentityAsync<FacebookCredentials>  which calls out to the login provider service and requires an internet connection.

Being able to locally debug a service that uses authentication is an absolute timesaver. Hopefully this will help you get it up and running.

WPF application with DropShadowEffect renders incorrectly on nVidia GeForce drivers 185.85 and greater

For those of you who develop using WPF, I ran into the following issue recently:

I developed MuvUnder Cover: The Album Art Sleuth, a WPF application, and with the latest nVidia drivers it displays erratic rendering of the interface. Graphical elements are missing, are half showing, when you mouseover them they appear and then randomly disappear, etc.

I have tested this on a Geforce 7800 GTX and GeForce 7300 LE with the following driver versions: – tested and broken – tested and broken – tested and broken (this was the first of the GeForce/ION drivers)

I tracked it down to the following cause, with a solution:

I had the following DropShadowEffect set on a lot of controls:

<DropShadowEffect x:Key=”DropShadowEffectDefault”
BlurRadius=”5″ />

All of the controls that had that set where the ones that were showing the erratic missing, showing on mouseover, half rendered issue.

I then switched back to the following software rendered dropshadow:

<DropShadowBitmapEffect x:Key=”DropShadowBitmapEffectDefault”
Noise=”0.01″/> <!– Setting Noise forces it so it isn’t automatically changed to DropShadowEffect (nVidia bug with DropShadowEffect)–>

and everything rendered correctly.

You can follow the Microsoft Connect bug I reported to see if/when there is a fix and which side of the fence (nVidia or Microsoft) it comes from at:

BlendSense: XAML Intellisense for Expression Blend v2.1.1760.0

Karsten Januszewski has a post (read his post for instructions on installing the addin) about Intellisense for Expresion Blend and upon trying it, it didn’t work.  I would get the following error:

“Could not load file or assembly ‘Microsoft.Expression.DesignSurface, Version=2.1.1693.0, Culture=neutral,…”

The issue was caused by the fact that even though I was running SP1, I had v2.1.1760.0.  I’ve recompiled BlendSense against this version which resolved the issue.

You can download it here.