From my experience there seems to be very limited support for Windows Mobile Development. Sure, Visual Studios is great with its emulators, and essentially a lot of things you can do in Windows Forms, you can also do in a Windows Mobile Application, but one aspect I did not find a lot of support on was deploying CAB packets to an Active Sync'd device through an MSI package. After searching the internet for a while I came across a tool entitled, CABviaActiveSync which although did exactly what I wanted (install a CAB file from my desktop to my device), I still peronsally believe that having an MSI package is much more user friendly. It also would give me the oppurtunity to inject custom install options etc into my procedure (such as defining a Web Service IP address for my Mobile Device to Sync with). Below is a tutorial on how to install your Windows Mobile application onto your Windows Mobile Device via your desktop.
Extension methods are great! In the past I would simulate Extension methods by building Bookmark folders in Visual Studios for common string functions, math functions etc. I then migrated to using code snippet tools to save little reusable snippets of code, but always found it difficult for others to know that I had implemented a new code snippet and that they could now use it in their code. But alas, along came Extension methods and all my problems were solved. I now have a great way to organise all my code snippets into a contextual structure and also make it immediately available to the rest of the developers in my team. Below is a simple example of extending the Dictionary class to implement a "SortDictionary" method.
I am currently working on a new project using the latest technologies from Microsoft. Although most of the technologies are still in Beta, one of the languages I had to learn was LINQ. Coming from a SQL background, I could honestly say that the step from SQL to LINQ was a bit daunting. Statements that I wrote in SQL within 2 minutes took me over an hour to figure out in LINQ to start with. Below is a outline of converting SQL thinking to LINQ thinking that became the fundamental driver behind writing all my LINQ statements now.
For example, using this framework I could easily translate the following SQL call into LINQ syntax quite easily :
SQL Statement :
DECLARE @lat float
DECLARE @lng float
SET @lat = 40.66666666666
SET @lng = -3.54434333344
SELECT b.BlockId, b.PolygonId
FROM Block AS b INNER JOIN
Polygon AS p ON b.PolygonId = p.PolygonId INNER JOIN
Point AS po ON p.PolygonId = po.PolygonId
GROUP BY b.BlockId, b.PolygonId
HAVING (MIN(po.Latitude) < @lat) AND (MAX(po.Latitude) > @lat) AND (MIN(po.Longitude) < @lng) AND (MAX(po.Longitude) > @lng)
&& B.Polygon.Point.Max(point => point.Longitude) > Longtitude
As long as you follow the structure it seems as though most SQL statements can be easily translated to LINQ this way. One thing to note, is that I am using LINQ to Entities (Objects), and there are certain limitiation/bugs that I have encountered with using the "FirstOrDefault()" method when deailing with LINQ to SQL.