LINQ to SQL generator fails due to custom code

LINQ to SQL generator fails due to custom code

Today I decided to do something quite innocuous, or so I thought, on an existing application that happened to use LINQ to SQL. I needed to add an additional field to an existing table which I did quite easily via SSMS. However, when I came to update the LINQ to SQL model file I ran into all sorts of issues. The easiest way I’ve found in the past to update the LINQ to SQL model is to simply delete the table that you need to update and drag it onto the design surface from Server Explorer. Normally this updates the model and doesn’t usually break anything (unless you say delete a field that is in use in your code in which case the compile error is an artefact you want).

Today this process seemed to go completely haywire for no reason. I was getting 10-15 compile errors – since I was just adding a field I shouldn’t have seen any. Thinking that I’d broken something accidentally I reverted back to the version in subversion and tried again. Same result. Looking in Solution Explorer it was clear why these errors were being generated – there was no .designer.cs file to go alongside the .dbml LINQ to SQL model file.

I right-click on the dbml file in Solution Explorer and selected “Run Custom Tool” (for those unfamiliar with the Visual Studio custom tool model this is essentially an external executable that is called to automatically create or modify files in your solution – in this case create the .designer.cs file). This time I at least got an error message:

image

Error: The custom tool ‘MSLinqToSQLGenerator’ failed. Unsepecifed error

Interestingly it also opened up a file in which I had added some custom properties for my LINQ to SQL entities. I found that if I excluded this file from my solution I was again able to run the custom tool to generate the .designer.cs file. So, in order to make schema changes from now on I need to:

-Exclude my custom properties file

-Make changes to my LINQ to SQL model

-Run the Custom tool to generate the .designer.cs file – this is automatically run if you save or close the model designer

Update: Actually, you need to do a build of the project that contains the LINQ to SQL model prior to adding the custom properties file back into the project. Otherwise Visual Studio decides to nuke the .designer.cs file again.

-Include my custom properties files

-Rebuild my solution.

Hope this helps anyone else seeing the same issue

Does Windows Mobile 6 Smell (part II)?

Does Windows Mobile 6 Smell (part II)?

In my previous post I talked about Microsoft and the enterprise and how it had help shape Windows Mobile 6.x. Now I want to look at some of the implications of this strategy, specifically looking at how the attitude towards touch input has changed over time.

Touch v’s Non-Touch v’s Multi-Touch

One of the things that really differentiated Windows Mobile was it’s ability to work on multiple different form factors, from your non-touch txt friendly devices with keyboards through to your candy bar devices through to your pda-style devices with on-screen keyboards. Track back a few years and you would have seen the names Pocket PC and Smartphone being used to describe devices with and without a touch interface. With a move to align the two operating systems these came to be known as Windows Mobile Professional and Windows Mobile Standard – personally I think this did more than confuse the market who were already confused by the double use of the word Smartphone.

But this post wasn’t supposed to be a Windows Mobile history lesson, instead it was to look at our opinions on touch have evolved. If you recall back to the Pocket PC days there were very few people who actually used “touch” to interact with their device. Most uses whipped out their stylus and used that to push and poke at the screen. They would tap at the on-screen keyboard or even learn how to use the quirky text recognition capabilities of the device. This process was quite painful, particularly if you were responding to a text message or email. This is in part why both hardware keyboards and the Smartphone increased in popularity – both these addressed the problem of how to quickly navigate and type on the device.

The challenge with a physical keyboard is that no matter how to position it you end up with a tiny keyboard that simply adds weight and size to the device. Text entry, whilst quickest using a full qwerty keyboard was still a far shy from entering it on the desktop and often the extra hassle of sliding out a keyboard, waiting for the screen to reorientate and then entering text was enough to put off a lot of users.

The challenge with Smartphone is that it just sux – ok, you have me, I’m not a Smartphone advocate. Whilst I find that the interface is quick to navigate nearly all the applications are somewhat lacking or clumsy to use.  Take internet explorer for example – you either have a little arrow cursor that you drag around the screen using a dpad or you jump from link to link, often making the text of the website very difficult to read. Personally I’ve never liked this style of device and it was scary a couple of years ago because it seemed that 90% of all new devices being released by OEMs were a Smartphone, rather than having a touch screen.

From a development perspective we saw the convergence of Smartphone and Pocket PC into Windows Mobile as a good thing. It meant we could build a single application that would work on both styles of devices. Unfortunately, this is a bit like building a desktop application and running it on the device – great idea, but results in an aweful user experience as either the desktop application is limited to display what’s available on the device (ie small screen real estate) or the application has to scale down to fit to the device (resulting in small controls that are hard to use). Guidance from Microsoft even suggested that developers should build to target Smartphone so it will work on both devices.

This whole topic became even more interesting when Apple released the iPhone and multi-touch came into the mainstream. Unfortunately the Windows Mobile team failed to get it and released 6, 6.1 and 6.5 without any support for multi-touch.  In fact it’s only been with the release of the HTC HD2 that we’ve even seen capacitive screens for Windows Mobile which would effectively allow multi-touch. I believe this was because there was a misunderstanding on how users wanted to use their device. Too much research focussed on looking at ways to improve what users were currently doing (eg using a stylus), rather than exploring more innovative ways for the users to do things (eg making all controls larger so that the user can use touch instead of a stylus).

Now, finally Microsoft has awoken and we are seeing a new era of devices and operating systems heavily geared towards making touch (and I’m sure in the future multi-touch). Windows Mobile 6.5.3 has restyled controls, repositioned Start menu and Ok buttons, specifically geared to making it easy to navigate with touch and gestures. Windows Phone 7 series is all about touch, swipe, gesture and motion in general. It’s clear to see that this is the way forward and that the old Blackberry style non-touch devices are a thing of the past.

Does Windows Mobile 6 Smell?

Does Windows Mobile 6 Smell?

If you ask most users what they think of Windows Mobile they either don’t know what it is (most non-techie consumers) or they shudder saying that slow, overly complex phone that I never use now I have…. Anyone would think that Windows Mobile smells. I’d like to put forward some points that at least explains why it looks and smells the way it is. You may even decide to give the current generation of Windows Mobile 6.5.3 devices a go.

Microsoft and the Enterprise

I think the first point I’d like to make is that I doubt at any stage Microsoft decided that the end user wasn’t the highest priority when designing and building Windows Mobile. The whole “end-user-first” message that’s coming from Microsoft is just another re-hash of the “Age of User Experience” message that we saw a couple of years ago. What I do buy is that Microsoft has changed focus on which end user they’re putting first, or at least, what end user activities should come first.

In the past the design of Windows Mobile was geared towards an end user who worked for an enterprise, was connected to Exchange server and the reason for having a device was to make phone calls, send sms, triage email, work with contacts, calendar and tasks to get their work done. Now we’re seeing a new era where Windows Phone 7 is about supporting end users in every facet of their lives – helping them stay in contact, entertain them, help them relax, get work done, oh and of course make a phone call. Actually the latter seems to have been almost an after thoughts as there is not even a hardware call and/or hang up button according to the specs released by Microsoft last week.

So I guess the question has to be asked as to why the focus was on the enterprise user? Microsoft’s entry into the mobile phone market came as an extension of their embedded operating system. In fact Windows Mobile is essentially Windows CE in a specified configuration, with additional modules, such as Office Mobile and of course a phone stack. As such it seemed logical for them to enter this space in order to support enterprise users.

Once in this space it appears that Microsoft saw RIM as one of the main competitors with their Blackberry devices. Those familiar with Microsoft codenames will know that Crossbow was one of the code names used internally for one of the previous versions of Windows Mobile – this happens (probably coincidentally) to be the name of a pesticide that can be used to get ride of the blackberry plant (ref Website). The Blackberry OS has traditionally been menu centric, so as long as Windows Mobile only had as single “Start” menu it was considered to be a safe bet. Also, since Blackberries didn’t have touch screens, supporting touch (rather than stylus, and definitely not multi-touch) input wasn’t really considered a core use case. Again the result was that Windows Mobile continued to evolve towards a dpad/keyboard driven interface – in the enterprise this resulted in some very effective office worker devices that could be used to rapidly triage email but they weren’t the nicest consumer devices.

More on this discussion in future posts….

Windows Phone 7 Series Development – What Do You Want?

Windows Phone 7 Series Development – What Do You Want?

Since it’s announcement over a week ago the question on all our lips is “what’s the development story going to be?” Whilst there has been countless rumours regarding support for Silverlight (perhaps third time’s like for this can of worms….) and XNA it won’t be until MIX that we’re going get a good look at what Microsoft has in store for us mobile developers going forward.

In the meantime, I took a little bit of time out to think about the current generation of development tools. Now, I’m going to overlook the obvious failing around stylish controls for building Windows Mobile applications (which in my opinion is one of the fundamental reasons the iPhone is trumping Windows Mobile applications at the moment, after all it sure as hell isn’t the development language!). What I’m interested in is the development/debugging/testing/deployment story, so here’s a list of the tools/frameworks etc that we have at the moment. I’ll start this list but I suspect it may have to be continued as I remember things that I’ve omitted.

Microsoft

IDE – Visual Studio

– Support for Native, C# and VB.NET development
– Visual Designer for Forms and Controls, including designer skin
– Intellisense, Code completion
– Debuggin support
>> Breakpoints
>> Watches and variable inspection
>> Datatips
>> Step through/over

Managed Frameworks

– .NET Compact Framework
– Windows Mobile managed libraries
>> POOM (contacts, calendar, email, tasks)
>> Camera
>> Contact picker
>> State and Notification Broker
[missing APIs could be p/invoked to native APIs]
– Rich networking stack (sockets & httprequest)

Data Story

– SQL Server Compact
– Multiple Synchronization Frameworks (RDA, Merge Replication, Sync Services)
– Designer support for connecting to web services

Support Tools

– Device Emulator
>> Able to change configuration
>> Able to adjust system state
>> Able to connect to ActiveSync/WMDC to simulate docking real device
– Cellular Emulator
– Hopper 

3rd Party

Smart Devices Framework (OpenNETCF)

Mobile In The Hand

Mobile Client Software Factory

Orientation Aware Control

NLog

 

With this list in mind, what do you feel is missing? If your answer is nothing, then think harder – after all there must be a reason why Windows Mobile 6.x was failing to attract users and developers alike.

Motorola Devour is yet another average Android device

Motorola Devour is yet another average Android device

On the way from the airport into the Melbourne CBD I read the ZDNet Review of the Motorola Devour and I think it confirms my view that Android, whilst perhaps a great operating system for OEMs to build on, lacks anything at all that would draw me to the platform. The Devour seems an overly unimpressive device both in terms of the hardware spec and the software.

From looking at the hardware I can’t get away from the feeling that Android devices, pretty much across the board, have been designed with your average “google-loving-geek-boy” in mind. The ZDNet review comments that the design of the Devour could be considered “retro” (from Wired’s Priya Ganapati) and that it’s the “next chapter of Motorola’s signature industrial design” but I think the hardware appears chunky and uncomfortable, and lacks any sense of true style.

From the software perspective it of course features the standard Android home screen featuring icons (urgh, so last year – get with the program, it’s all about square updating tiles now…. we’ll probably come back to that to determine whether Microsoft’s gamble pays off there). What’s interesting is that like other Android devices it supports the latest version of Google Maps. With Google increasingly leaning towards providing the latest features (such as navigation) only on the version of Google Maps for Android, it will be interesting to see what other players like Microsoft bring to the table.

[As an aside – the recently released Windows Mobile 6.5.3 DTK includes a mapping framework sample.  The sample is written in native code but has a managed wrapper so can be used in either a native or .NET Compact Framework application. This sample is a great starting point for anyone wanting to build an application making use of mapping on the Windows Mobile platform. No information yet as to whether there will be a similar control/framework for Windows Phone 7 series development. More to come on this topic…]

Is Windows Phone 7 series going to be great for developers?

Is Windows Phone 7 series going to be great for developers?

As you’ve no doubt seen Microsoft announced Windows Phone 7 series last week at Mobile World Congress in Barcelona. I guess I’ll start off with the mandatory “here’s what it looks like” piece: Here’s a couple of screenshots for you to go “oh-ah” over – if you want more you can head over to Rob’s blog where he’s got some more images, as well as the official Windows Phone 7 Series website.

startscreen web 158x300 Windows Phone 7 Series debuts at Barcelona!officescreen web 300x181 Windows Phone 7 Series debuts at Barcelona!

Now the reason for this post is a way of providing commentary following the Focus, Focus, Focus post by Charlie Kindel. Firstly, I want to say that I love the fact that there appears to be such a high level of “focus” from the Windows Phone team. It would appear that despite severely dropping the ball with Windows Mobile 6.x I think the departure from this platform to Windows Phone 7 series will definitely be a positive move and will position Microsoft in a strong position in the mobile market.

Yes, I know everyone’s (well at least a large proportion of the techie crowd) going on about Android this and Android that but they’re seeing the same issues Microsoft saw 5 years ago with market fragmentation and a UI that is already very dated. Unless Google does something remarkable prior to Windows Phone 7 hitting the stores I suspect we’ll see an un-remarkable end to Android phones being the alternative to buying an iPhone.

Coming back to Charlie’s post – What I found particularly interesting is the priority list regarding the developer audience, which essentially puts us enterprise developers close to the bottom of the heap. Initially you might look at that and say “but enterprise has been Microsoft’s staple when it comes to WM” but you have to remember this is NOT Windows Mobile, it’s Windows Phone 7, it’s a new era of devices and with that comes all the issues you’d expect to see with a v1 product.  Actually as an aside I’m surprised they went with 7 – this is so radically different they could have just gone with Windows Phone and be done with it. Alternatively they could have just picked a single manufacturer and released the Microsoft Phone but that’s a completely different topic altogether.

So, where does that leave us enterprise developers? Well the first thing you should do is realise that Charlie’s list is only a priority list, it doesn’t imply that you can’t do enterprise development. In fact, I’m guessing that in order to support the Pro and non-Pro developer audience in their ability to create awesome applications for consumers, a large proportion of the enterprise capabilities will be there.

So what may be missing for enterprise developers? If you consider enterprise as including line of business applications such as stock management, then it is highly likely that when Windows Phone 7 ships there won’t be hardware out there to support barcode scanning etc. This isn’t actually a new problem as hardware manufacturers for LOB devices typically take 6-12 months (or more in some cases) to update their devices with new operating system versions.

Microsoft also hasn’t talked about what the deployment story will be for applications and the extent of the programming apis that will be available for application developers to interact not only with other services on the device (eg camera or the phone), storage, other applications, PIM data (eg contacts, calendar) and whether there will be developer libraries for connecting to Windows Azure, Live Id and other hosted services. My guess is that like previous versions of Windows Mobile there will be apis for accessing some of these – how this affects enterprise development is really dependent on what apis are there and which are missing. For anyone interested in this story, you should be heading to MIX where they’ll be disclosing the developer story.

Windows Mobile 6.5.3 DTK (not SDK or 6.6) download available

Windows Mobile 6.5.3 DTK (not SDK or 6.6) download available

Get it while it’s hot from the download center. The content in my original overview of the Windows Mobile 6.5.3 SDK is still accurate. However the installation issues have been resolved and there is a bunch of things (like the help files and the Map Framework sample) are now installed correctly.  The installation of the DTK should not affect any of the existing emulator images you have installed.  Stay tuned for more information on what’s in the DTK.

Windows Mobile 6.5.3 DTK – Ready, Set….. Oh wait, hang on….. Go!

Windows Mobile 6.5.3 DTK – Ready, Set….. Oh wait, hang on….. Go!

As some of you will be aware there was a first attempt at releasing the Windows Mobile 6.5.3 DTK (now missing) earlier this month. Despite a number of bits being missing or not installed correctly there are definitely some good bits coming in the DTK (take for example the Widget development story within VS2008).  According to Todd in his Marketplace Momentum post we should see the real version of the DTK later this week. Check back with this blog to find out more about the actual release when it happens.