Setting ProviderManifestToken for SQL 2005 in the .Net EntityFramework

Like many developers, I tend to have the latest software installed on my local development machine, but the servers that I deploy my code to are usually a few versions behind.  As is most common, I run SQL Server 2008 R2 with Visual Studio 2010 on my computer, but the servers that host the websites I develop are running SQL Server 2005.  This presents an interesting problem when developing with the .Net Entity Framework and generating the .edmx file to represent your data model.
The most common error seen when doing this is that SQL Server 2005 will complain about datetime2 not being a compatible field type.  The problem is that the .edmx file for the data model was generated against SQL Server 2008 which implements the new datetime2 field, and the Entity Framework will use datetime2 fields for any DateTime .Net properties.  The fix is to manually edit the .edmx file and change the ProviderManifestToken attribute of the Schema node from 2008 to 2005.  This will instruct the Entity Framework to function against the 2005 compatibility level of SQL Server, using datetime fields instead of datetime2.  Unfortunately, any updates made to the Model will cause the generator to recreate the .edmx file with ProviderManifestToken set to 2008.
From an old Microsoft Connect posting, it seems that the intended functionality was that the generator would use the Compatibility level of the database to assign the proper ProviderManifestToken.  However, it is currently reading the SQL Server Instance Version instead and as of .Net 4.0, the Entity Framework still behaves this way.  With Microsoft marking the posting as Will Not Fix and not adding in a designer setting for the property, having to remember to edit the .edmx every time a change is made to the model is not an acceptable solution.
I came up with an automated solution that uses the MS Build Community Tasks to automatically update the .edmx file in a BeforeBuild target, using the XmlUpdate task, to set the ProviderManifestToken to 2005.  It took a couple tries to workout the proper Xpath expression to select the ProviderManifestToken attribute, but here is my solution:

<Import Project="$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets" />
<Target Name="BeforeBuild">
<XmlUpdate Prefix="ssdl"
Namespace="http://schemas.microsoft.com/ado/2009/02/edm/ssdl"
XPath="//ssdl:Schema/@ProviderManifestToken"
XmlFileName="Model.edmx"
Value="2005"/>
</Target>

Now the ProviderManifestToken is always set to 2005, no matter what database the generator uses for my model.

Windows Phone 7 Developer Launch

I attended the Windows Phone 7 Developer Launch event in Philadelphia this week to learn all I can about the platform before it is released next week.  Things are looking good for Microsoft in the mobile development world.  My only hope is that they port some of these tools to the Windows Mobile 6 successor Windows Embedded Compact 7, or quickly get Windows Phone 7 on enterprise devices.  The ability to use XAML in applications and devices will greatly change how enterprise programmers develop on mobile platforms.

I also learned of a contest through Scott Hanselman’s website, that Microsoft is giving away two Windows Phone 7 devices if you post the above image in a blog post.  Crossing my fingers!

.Net Desktop Notifications for Android Notifier

I came across the Android Notifier application for my Droid phone the other day. It is a great application that allows the posting of phone notifications (SMS, Phone Calls, etc.) to a computer over Bluetooth, Wi-Fi, and USB.  I’ve been looking for an App like this for a while to solve a nagging problem I have at work.  Whenever I’m busy, and my phone is out of sight, how do I know that I have a text message to read, an incoming or missed call, or that my battery is about to die?  It was only a matter of time until someone figured out how to make an Android phone send notification to a computer.

The problem is, there is no decent client for Windows.  The only one that I can find is the Android Notifier Desktop.  It seems to have been developed with Growl in mind and is written in Java. Without Growl, it is extremely basic for Window users and is missing the full functionality of the Mac and Linux versions.

So that’s when I decided to start my own open source project on Google Code; the .net Desktop Android Notifier.  I am going to develop a better client for windows users to get some great features out of this wonderful Android application.

This is also a great opportunity for me to start my blog with an on-going project to document, along with other posts that I hope developers will find useful.

With that small introduction, look forward to the next up coming post.