New Device Development Features in Visual Studio 2008

Roughly two years ago, when I was writing an article on "New Features for Device Developers in Visual Studio 2005" that was published in the August 2005 issues of this magazine, our program management team was already busy shaping the next release of the product, which is soon to be released as Visual Studio 2008. We spent a lot of time talking to our major customers and reviewing the feedback we got on blogs and questions on forums on newsgroups to identify what enhancements/features would be most useful to our device developers. One thing that surfaced was that device developers needed more help when it came to testing their applications efficiently. Whether that meant testing on multiple devices or under varying conditions or simply being able to write unit tests, they clearly needed help getting applications to market faster by reducing the testing time.
Here I'll walk you though some of the new features for device developers in Visual Studio 2008, focusing on how these features will make device developers more productive by enabling scenarios that aid in testing applications and help you ship a high-quality product fasterLet's start with the one of the most significant enhancements that we added to Visual Studio 2008 - the ability to write unit tests for your VB and C# device applications. While keeping device developers' unique needs in mind, we also kept parity with how this feature works on the desktop and Web so you can simply translate what you learned around writing unit testing for devices. Of course there are subtle differences that we had to allow for but you'll clearly see familiar dialogs and experiences when creating and running unit testing for devices such as integrating test results with back-end systems like Team Foundation Server.
To demonstrate writing a simple unit test for a device class library that you created, here's what you'd have to do (See Figure 1). Let's say you have a class library written in C# that has a method that returns the bigger of the two numbers passed to it. You want to write a unit test for it and make sure you don't goof up on the logic. So once you're in that project, right-click anywhere in the editor and select "Create a new Unit Test."
If you noticed that there's a flaw in the code trust me that's intentional. I'll be using that to highlight how your unit test will help you catch these kinds of mistakes. So please ignore that for the moment and assume that this code works as you expected.
Now, once you've clicked on create unit test, the next dialog lets you pick the methods for which you want to create unit tests (See Figure 2.)
For now we'll stick with the default and click OK and provide a project Name. This will create and add a Test Project to our solution and in the process Generate the Test Methods, add references as needed, ensure that Test Configuration Files are created and then you're ready to write your unit tests and execute them.
You'll find in your test project a Method called FindBigTest() that has a stub for the unit test for our simple method and looks like this:
TestMethod()]public void FindBigTest(){ Class1 target = new Class1(); // TODO: Initialize to an appropriate value int Number1 = 0; // TODO: Initialize to an appropriate value int Number2 = 0; // TODO: Initialize to an appropriate value int expected = 0; // TODO: Initialize to an appropriate value int actual; actual = target.FindBig(Number1, Number2); Assert.AreEqual(expected, actual); Assert.Inconclusive("Verify the correctness of this test method.");}
Let's modify this code to add the appropriate values for Number1, Number2, and the expected Values. For example, if Number1 is 5 and Number2 is 4 then the return value should be 5. We'll also remove the Assert.Inconclusive line and once our edits are done, right-click and select "Run Tests" from the menu. If prompted you can then select either a real device or an emulator to run your unit test on.
One tip: Make sure you have .NET Compact Framework 2.0 (or higher) on the device or emulator on which unit tests are going to execute because the unit test project won't deploy .NET Compact Framework and expects it to be there already. One easy way to do this is by deploying a simple VB or C# project to the device before you run your unit tests.
[TestMethod()] //After the changes are madepublic void FindBigTest(){ Class1 target = new Class1(); int Number1 = 5; int Number2 = 4; int expected = 5; int actual; actual = target.FindBig(Number1, Number2); Assert.AreEqual(expected, actual);}
Once you select Run tests, you'll notice that the emulator shows up (if running on the emulator) and Visual Studio starts to deploy the Unit Test Harness, your class library, and the test code to it. You'll also see that the Test Results Window shows up with the executing test reflecting the state of Pending. Give it a few seconds to execute and you should see something similar to Figure 3.
That clearly worked when Number1 was greater than Number2. Now let's test the other condition as well and make sure that if Number2 in bigger then our code works also as expected and returns that. So in our test we can swap Number1=4 and Number2=5 and execute the test again. Now it gets interesting. Your test just failed (see Figure 4).
No, don't panic. Remember the flaw in the code before? We were returning Number1 in both cases. While we did it intentionally to highlight how unit testing work, these are the kinds of scenarios that having unit tests can save you hours of debugging. So to ensure that this example works, simply fix the code in the class to return Number2 where applicable, rerun your unit test, and it will certainly come back as PassedContinuing with our effort to help you test your code more efficiently, the second trickiest area developers had to deal with was executing code on devices with different security configurations. Every device developer at some point will realize that the certificates and security policies on the device control code execution. While we can't simplify those policies and processes, we can certainly provide tools that make it easier to understand and deal with these challenges. One way to deal with them is to have lots of devices in your test labs with different security configurations and test your applications on each of them. A simpler and cheaper way is to take advantage of the new Device Security Manager in Visual Studio 2008 that can change the security configuration for your target device at a click of a button so that you can quickly test your applications on different security settings and configurations (see Figure 5).
This tool can be launched from the Tools Menu followed by clicking Device Security Manager. In Figure 6 you can see that this tool is currently connected to a Windows Mobile 5 Smartphone Emulator and displaying the security configuration it currently has.
Emulator images usually ship with an unlocked security configuration that makes it easy to deploy and test applications; real devices will very likely be one of the other configurations listed on the screen. To see the effect of how your application will behave in a different configuration all you have to do is select the configuration of interest and deploy to the device.
In a matter of a few seconds that emulator image will be provisioned to work like a two-tier device and when you run your application you'll experience exactly what your customers do using a similarly configured device, all without you having to build an inventory of real devices.
Automation in the Device Emulator ManagerThe Device Emulator Manager first shipped with Visual Studio 2005. It made it easy to see all the emulator images on your machine and provided the ability to quickly launch and cradle emulator images. Clearly that was useful, but manual in nature. Every time you had to launch or cradle or shut down and image, you had to manually do these tasks using the Device Emulator Manager. In Visual Studio 2008 the Device Emulator Manager can be fully automated, which means you can write simple scripts or code that you can run in conjunction with your unit tests to connect and disconnect one emulator after another.
Another enhancement in the Device Emulator Manager also makes it simple to clone emulator images. Once you have an emulator running, right-click on that node and select "Save As" shown in Figure 7.
This will prompt you to save the configuration of the emulator in a simple XML file in the "My Device Emulators" folder. It will also show this new emulator in the Device Emulator Manager. You can then edit this file to change the characteristics of the emulator and quickly build a list of emulators with various configurations.
Device Emulator EnhancementsThe version of Device Emulator that ships with Visual Studio 2008 is version 3.0. Version 2.0 of the emulator shipped with the Window Mobile 6 SDKs and was also made available for download standalone from Microsoft Downloads. The performance gains should certainly be the most visible benefit to all developers moving from Version 1.0. But apart from working on performance Device Emulator also added capabilities to emulator hardware and peripherals such as battery, speakerphone, headset, and car kit.
Of all these features, Battery Emulation has been my favorite. I recollect talking to many developers who had to wait for hours for device batteries to drain enough to test how their code worked in low-battery conditions. For example, when the battery in the device went down, say, 20%, they wanted to start saving some critical data gracefully. The only way to test this before was with a real device - waiting patiently for that moment of joy when the battery level hit the desired level. The Device Emulator makes it a charm to test these scenarios. Coupled with the new state and notification APIs in Windows Mobile, you can use the Device Emulator to send a low-battery signal to the Emulator Image, which will then send a notification to your application to handle that event. And in a matter of seconds you'll be able to test the behavior of your application under different battery conditions (see Figure 8).
And to make things even easier in Version 3.0 you don't have to launch the properties page manually to change the battery state. You can now automate that part too. Just like the Device Emulator Manager, the Device Emulator supports automation and using a script or code you can alter the battery state while your application and emulator are running.
A Broad Choice of Supported PlatformsVisual Studio 2008 provides the most comprehensive choice of Windows Mobile and CE platforms for developers to target and continue to support both managed (VB, C#) and native (C++) development. Along with the Pocket PC 2003 and Smartphone 2003 SDKs that we shipped in Visual Studio 2005, we now also include the Windows Mobile 5.0 SDKs in the box. To develop for Window Mobile 6, you just have to download the most recent SDK from the Web and it will plug into Visual Studio 2008. In Visual Studio 2008, Smartphone 2003 is for a native project only since .NET Compact Framework 1.0 projects aren't supported and Smartphone 2003 only supports a .NET CF 1.0 runtime. If however you have any projects that you want to open, Visual Studio 2008 will migrate them to work on Windows Mobile 5.0 Smartphone using the .NET CF 2.0 runtime.
Visual Studio 2008 also introduces a more usable version of the new project dialog designed to make it easier to navigate multiple SDKs, runtimes, and application types as well as a link to help discover new SDKs and emulator images.
As you can see in Figure 9, we allow the ability to select a platform, select a version of .NET Compact Framework (2.0 or 3.5), and the application type all from one single screen.
And the best part of Visual Studio 2008 is that it will work perfectly well with Visual Studio 2005 side-by-side on the same machine to help make a smooth transition from 2005 to 2008.
ConclusionI hope that with this article I was able to highlight how Visual Studio 2008 will greatly impact your ability to ship robust device applications faster to your customer and demonstrate a potential way to save the cost of procuring expensive devices by using the emulator and other features instead.
Our team will be glad to hear your feedback and thoughts on how we can continue to help provide you with the best development experience for smart device development. You can reach us using our team blog at http://blogs.msdn.com/vsdteam/, provide feedback using device forums at http://forums.microsoft.com/MSDN/default.aspx?ForumGroupID=11&SiteID=1, or by using the Connect Feedback System at http://connect.microsoft.com/default.aspx.