What are the most valuable .Net Compact Framework Tips, Tricks, and Gotcha-Avoiders? [closed]

Answer 1

Sure:

• Use a physical device whenever possible (not the emulator)
• Test with multiple devices (different vendors, different models)
• Concentrate testing around sleep/wakeup behaviors
• When using MSTEST unit tests, never use private accessors
• Avoid ActiveSync like the plague - debug using CoreCon direct
• Get familiar with RPM and start using it early
• Reuse objects when possible
• Avoid doing a lot of work in a Form's ctor - off load it for lazy load or in a background thread
• Load Forms on demand when possible (not all of them at once)
• Cache the frequently used Forms, create infrequent ones on demand
• Keep image resolutions low
• If a class exposes Dispose use it. Always.
• No app is too small to benefit from MVC/MVP patterns
• Don't use the Microsoft CAB/SCSF port for the CF (the people who ported it obviously never actually used a resource-limited device)
• Get familiar with the concept of "occasionally connected" if you will be doing any remote data/service activity
• Docking and Anchoring are your friend and your enemy - test run-time screen rotations and multiple resolutions (even if you think you won't target them, because you're probably wrong in that thinking)
• Look at, but don't heavily invest in the device deployment package project type. It has major limitations that will likely bite you. A batch file works surprisingly well or a custom MSBUILD task to call CabWiz
• Brush up on your C++ and P/Invoke skills. You will need them. It's almost impossible to write a useful CF app without P/Invoking something.
• Code to the lowest common denominator for targets.
• Partial classes are your friend, especially for dividing logic between target types (PPC, Phone, non-mobile CE).
• Avoid running an app from persistent storage, especially for CE and pre-WInMo 5. Copy to RAM and run from there to prevent demand-paging from killing you, especially after a sleep/wake cycle.
• Apps should not care about sleep/wake transitions, but that's pure theory. Sleep wake **will* change your app behavior, so again test, test, test.
• Did I mention test? Especially on every device you can get your hands on? Buy cheap hardware off of eBay for your test lab. Having more devices is more important than having the latest unless you intend to use a specific feature of a newer device.
• Ask for divine intervention if you plan to use bluetooth programmatically. Get familiar with the Widcomm and Microsoft stacks and understand that they aren't the same.
• Watch the MSDN webcast on memory management in the Compact Framework. Watch it again for the stuff you missed the first time.
• Watch out for sleep/wake invalidating internal handles and causing access violations. This is more esoteric but certainly happens. For example, if you're running an application off of a storage card, the entire app isn't loaded into RAM. Pieces in use are demand-paged in for execution. This is all well and good. Now if you power the device off, the drivers all shut down. When you power back up, many devices simply re-mount the storage devices. When your app needs to demand-page in more program, it's no longer where it was and it dies. Similar behavior can happen with databases on mounted stores. If you have an open handle to the database, after a sleep/wake cycle the connection handle may no longer be valid.
• Install the evaluation version of Platform Builder. The source code for a whole lot of things is in there (like the network UI, many drivers, etc) and when your P/Invoke code isn't doing what you expect you'll at least have a place to go look for the "why".

added 5/25/10

• Don't expect the power management APIs under WinMo to work consistenly or properly (or even at all) across devices. In fact even with the same hardware it might change from OS build to OS build.

added 7/27/10

• If you're after a aesthetic UI, be prepared to do a lot of custom or manual drawing.
• If you're doing custom or manual drawing and you need to use transparency, get ready for a load of frustrations and having to write wacky code or call native code directly to work around shortcomings in the CF.

added 11/22/11

• Don't assume that just because a namespace or class exists in the BCL that it is actually implemented in any useful manner. Certificates certainly aren't.

I'm simply adding to the list as they occur to me...

Answer 2

When working with Windows Mobile, if you don't want your form to be full screen you need to set the FormBorderStyle to None. If you don't then you will spend hours pulling out your hair wondering why it is resizing automatically to the full screen size (which is in fact a feature of Windows Mobile)

Answer 3

OpenNETCF is a great resource.

Their Smart Device Framework is a real must have when developing with the .NET Compact Framework, as so many of the Full framework features are missing [I think someone once said the .NET Compact Framework is a wrapper around NotImplementedException!]

Answer 4

• If you are planning to use Sql Server 3.5 Compact read this blog.
• There are serious performance issues at SQL Server Compact and some code may be 100 times slower on the device compared to the desktop so always test your database code on the device.
• Setup unit and performance / integration testing on the device. Also very few people actually do this, it's not that complicated and far overweights the costs.
• If you deploy your code all the time use the network instead of ActiveSync. The easiest way is setting up a simple FTP server or TCP agent on the device.

Answer 5

Just as an FYI, if you are upset about not having Compact Framework support in Visual Studio 2010 then go here and vote for it to be added in. (And spread the word)

MS has more or less abandoned existing feature requests in Connect. Please go to the new User Voice site to vote for this feature.

Answer 6

Unit Testing (TDD) is possible on .net cf. But there are issues.

You will be using MSTest. Not NUnit, MBUnit, XUnit.net, etc. MSTest.

You will need Visual Studio Professional (as near as I can tell). The easiest way to get started is to right-click on a method you would like to test, then select "Create Unit Test". This sets up the test project for you. Only create one test project. It doesn't like having multiple. Just do this to create the project and get all of the dependencies setup for you. Then create your own test classes.

Mock objects could be an issue. RhinoMocks, Moq, and TypeMock all depend on things that are not available in .net cf. Pex has a project calls Stubs that I'm still looking into. Pex is a Microsoft Research project. You you will end up creating custom fake objects instead.

Test are run on the device emulator. That means they have to be deployed. If you get a strange error when you first start up the test runner, you probably do not have .net 3.5 on the device emulator yet. First deploy your project, then run the tests again.

On the non-testing side: You do get LINQ to Objects and LINQ to XML. Both are a godsend. You can talk to a server via WCF, but you don't get all of the endpoints.