Pratibha's WebLog

Localized Windows Phone Developer Tools

Installation Issues with Localized version of WPDT

Windows Phone Developer Tools Beta Released

Deployment in Smart Device Unit Tests

Unit Testing Private Methods in Smart Device Projects

A starter on smart device unit testing

A brief intro

OS Support

Dev10 Support

SxS support

Upgrading from ENU WPDT to the localized version

Installing WPDT Beta

Deployment using the Run Configuration

Deployment Attribute

Setup script

Private Accessors

Using Private Accessors

Structure of the Smart Device Unit Tests

Creating Smart Device Unit Tests

Executing the Unit Tests

2010-10-15T17:50:00Z

The German, French, Italian and Spanish of the Windows Phone Developer Tools (WPDT) are now available. You can go ahead and install them from here

Below are some of the details around the configurations supported, steps to upgrade from an existing English edition of WPDT and a couple of known installation issues to watch out for.

Like the English version, the localized versions are supported only on Vista and Windows 7 Operating Systems. Additionally, the localized versions of WPDT are only supported on the corresponding languages of the Operating System. The below table summarize this matrix.

Supported

Not Supported

Legend:

If Visual Studio 2010 Professional or higher edition is already available on the system, you can continue to use VS for windows phone development after installation of WPDT.

The below table summarizes the IDE to use in various configurations of Dev10

Dev10 WPDT	None	English	German	French	Italian	Spanish	Others
English		VS
German			VS
French				VS
Italian					VS
Spanish						VS

VS (devenv)

Express SKU (vpdexpress)

Legend:

1. You can install only one language version of WPDT on a system. You will need to uninstall the existing language version to install another other language version of WPDT.

Instructions for this are in the next section

2. If you have multiple language versions of VS 2010 installed, you will need to set the locale of VS 2010 to match that of WPDT to be able to use VS for windows phone development.

e.g. If you have German and Spanish VS 2010 installed on a German OS, after installing German WPDT, you can use VS for windows phone development if the current VS language is set to German (From Tools->Options)

This section lists steps for users who want to move from using the English version of WPDT to the localized version of WPDT. For the sake of simplicity, I will illustrate for moving from English to German, but the instructions would be same for any two language versions.

1. From Add/Remove Programs, Uninstall the English WPDT

2. Uninstall all the English Blend components that are left on the system

E.g. Microsoft Expression Blend SDK for Windows Phone,

Microsoft Expression Blend SDK for Silverlight 4,

Microsoft Expression Blend SDK for .NET 4 etc.

3. Install German WPDT

1. WPDT installation will not install OR fail to install Blend 4 for Windows Phone if there is an existing Blend 4 installation in a different language.

Note: WPDT only installs Blend 4 for Windows Phone and you will not have support for desktop Blend development. If you have a different language version of Blend 4, recommend you install WPDT on a different system.

However, if you do need to overcome this, you will need to:

a. Uninstall all the Blend components already existing on the system from Add/Remove Programs. (you can search for Blend in the ARP window)

b. Then, get the localized Blend 4 for Windows Phone from Add/Remove Programs, by choosing ‘Change’ on Windows Phone Developer Tools, clicking on ‘Add optional components’, selecting Blend 4 for Windows Phone and proceeding with it.

2010-07-13T12:50:00Z

The Windows Phone Developer Tools (WPDT) Beta has just released. You can install it from http://developer.windowsphone.com

This version is compatible with Visual Studio 2010 RTM. If you have Visual Studio 2010 RTM installed, the WPDT will automatically light up VS for phone development and you should be able to continue to use Visual Studio 2010 RTM for the same.

Uninstalling older WPDT

If you have the CTP bits of WPDT installed, you will need to uninstall them before installing beta.

Please see the below points if you are facing issues in uninstalling the WPDT CTP.

1. When un-installing you are asked to install Silverlight 4 Tools for Visual Studio 2010 RC

Cause for this: Users have installed the Sillverlight 4.0 RTM or later version Runtime after installing Windows Phone Developer Tools - CTP

Workaround: Install the SL 4.0 Developer Runtime and then uninstall the CTP.

2. When un-installing you get a prompt to install some components like Microsoft XNA Game Studio 4.0, Windows Phone Extensions.

Cause for this: Very likely you have un-installed the product using Add/Remove Programs

Workaround:

a. Proceed with install of all the listed components.

Then Select the No option in the install source page and click Install to all the listed components when you see this dialog

b. Repeat uninstall. This time the product should uninstall completely

If the above steps, do not help you in uninstalling, you can use the cleanup tool at http://blogs.msdn.com/b/astebner/archive/2009/04/10/9544320.aspx to uninstall WPDT CTP

While installing WPDT Beta, you may hit upon the following issues:

1. Blocker Dialog

WPDT Beta will block installation if some of the requirements are not met. You will see a dialog like this:

Cause for this: Setup has detected there are some conditions that could get your machine in an bad state and hence prevents the install of Beta.

For example-

a. Some incompatible products/versions are installed as listed. (SL 4.0 SDK RC version, Visual Studio 2010 RC or Beta version, etc.)

b. Some process is running that can impact install. E.g. (devenv.exe)

c. or Disk space is not sufficient

Action: Follow the instructions specified in the dialog which will usually be quite explicit about what needs to happen. Like

a. Uninstall the incompatible version of SL 4.0 SDK/Dev10 RC

b. terminate the devenv process if that is running

c. or Free up required space on disk

And then retry installation; hopefully this should get you unblocked.

2. Blend 4 for windows phone installation failure

During CTP, Blend for windows phone was available for download seperately. In WPDT Beta, Blend 4 for Windows Phone is included in the default installation.

On few occasions, Blend 4 for Windows phone may fail during installation.

Possible cause: The installation of Blend 4 for Windows Phone may fail if there is pending reboot on your system.

Action: For such cases, post installation, reboot the system, and install Blend using the below instructions:

From Add Remove Programs, select Windows Phone Developer Tools Beta - ENU, click uninstall/Change, choose Install Optional Components and proceed

with the wizard with Blend 4 for Windows Phone checked.

With this you should have successfully installed WPDT Beta and jump into windows phone app development.

In case you are still facing issues in installing WPDT Beta, request you to run the log collection tool , upload the vslogs.cab generated in the TEMP folder to a file server such as http://skydrive.live.com and then let us know of the issue using the Windows Phone 7 Forum

2008-02-05T23:03:00Z

By default, when Visual Studio executes a smart device test run, it copies the test assemblies and all its dependent assemblies down to the device. However, there may be scenarios where you would want to deploy other files like some xml files or .sdf database files on which the tests depend.

In this blog, I will describe a few ways in which you can achieve deployment of files as part of the Smart Device Test Run. You can use any of the methods based on the scope of the deployment items.

This method sets the deployment items for the run configuration. You can specify the files and folder to be deployed in the Deployments Page after opening the run configuration in the Run Configuration Editor.

At the start of the run, all the deployment items (files and folders) specified in the active run configuration will be copied over to the device. These items will be copied over to the Test Deployment Folder on the device (i.e. \Program Files\SmartDeviceTest\<TestRunFolder>\Out ). The default format for the Test Run Folder name is <user name>@<computer name> <date> <time>, and can be configured using the Test Run naming scheme in the Run Configuration File.

The deployment attribute can be used to specify deployment items such as files or directories for per-test deployment. This attribute can be specified on a test method or on a test class and there can be multiple instances of this attribute to specify more than one item. Examples:

[DeploymentItem(@"D:\My.txt")] // copies my.txt to the test deployment directory

[DeploymentItem(@"D:\My.txt", "DataFiles")] // copies my.txt to a DataFiles subdirectory under the test deployment directory

Note: In case there is a collision between filenames specified in the runconfiguration and the per-test deployment items, the runconfiguration takes higher precedence, i.e. the file specified in the test runconfig will be deployed.

The above two mechanisms allow deployment of items only under the test deployment directory. In case your tests require some files to be copied to the device outside the test folder, like in windows folder, you can use this method. However this method is not so straight and requires more work.

The run configuration allows specifying a setup script (.bat/.cmd file) that is executed at the start of the run. What you can do is write a utility application using the core-con managed API to copy the files from the desktop to the device and then invoke this utility from the setup script.

To simplify this process, I have compiled a tool “RemoteDeploy” that will do what I mentioned above. You can download this tool and then author a batch script that invokes this tool as below. Set this batch file as the setup script in the run configuration.

Setup.bat:

start remotedeploy.exe /platform:"Pocket PC 2003" /device:"Pocket PC 2003 SE Emulator" /source:”d:\myfile.txt” /dest:”Windows”

At the start of the test run, the set up script will be executed which will connect to the PPC 2003 SE Emulator and will deploy myfile.txt to the Windows folder on the device. If there is a collision between files deployed by the setup script and by the run configuration, the run configuration will take higher precedence.

Note: The remote deploy tool requires a platform and device switch. This must match the device specified in the smart device run configuration. Any change made to the platform or device in the run configuration will need to be manually reflected in the setup script.

The RemoteDeploy application can do more than just copying files. You can also deploy NETCF (2.0 / 3.5) , SQLCE and other CoreCon packages onto the device using this tool. For more help on the tool use it with the /help switch.

e.g. The below command will deploy NETCF 3.5 on the PPC 2003 SE Emulator.

remotedeploy.exe /platform:"Pocket PC 2003" /device:"Pocket PC 2003 SE Emulator" /package:NetCF3.5

Since Unit Test execution in Orcas currently does not install NETCF / SQLCE, you can use this tool in the setup script to automate installation of NETCF / SQLCE or any other package, which your tests depend on, before the start of the run.

2008-02-05T21:21:00Z

http://msdn2.microsoft.com/en-us/library/ms184807.aspx talks of how to test private methods when working with Unit Tests in Visual Studio 2008. These steps are applicable to Smart Device Unit Testing as well. Let me spend some time discussing this.

The problem with testing private methods is that test assemblies cannot access private or internal methods of the code under test. How can this be worked around?

In VS, private accessors are used to address this problem and call such restricted-access code. The approach is to use reflection to invoke the non-public methods of the CUT (code under test) assembly. In VS 2005, this accessor code was part of the Test Project itself. In Visual Studio 2008, however, there is a slight change in the design. The reflection based private accessor code now resides in a separate assembly called the Private Accessor Assembly.

The private accessor assembly gets generated automatically when you generate a unit test for a private method from the IDE. The accessor assembly’s name is generated as <CUTassembly>_accessor.dll. It is not included in the projects references directly. There is a text file with .accessor extension added to the Test project which contains the name of the Accessor assembly. For Smart Device test projects, this file will also include a line “Device” that defines that this is a smart device accessor assembly. A successful compilation of the test project would generate the Accessor assembly at <test project folder>\bin\Debug, which is then referenced by the test assembly.

Note: Desktop unit testing supports manually generating private accessors for an assembly from command-line using the publicize utility. While this should work for smart devices for most cases, this is an unsupported scenario for smart devices in Orcas.

Let me take the same BankAccount class I used in my previous blog. Let’s say that the DepositMoney method was made private.

private void DepositMoney(float depositAmount)

{

this._currentBalance += depositAmount;

}

On generating unit test for this method from IDE, the following test method is created in the test project:

/// <summary>

///A test for DepositMoney

///</summary>

[TestMethod()]

public void DepositMoneyTest()

{

// TODO: Initialize to an appropriate value

PrivateObject param0 = null;

// TODO: Initialize to an appropriate value

BankAccount_Accessor target = new BankAccount_Accessor(param0);

float depositAmount = 0F; // TODO: Initialize to an appropriate value

target.DepositMoney(depositAmount);

Assert.Inconclusive("A method that does not return a value cannot be verified.");

}

The BankAccount_Accessor class is defined in the private accessor assembly and contains shadow implementation for DepositMoney, which internally invokes BankAccount.DepositMoney using reflection. After taking care of the TODO’s in the generated code, the test method will look like the one below. The steps for executing these tests are same as for regular smart device unit tests (described in my earlier blog).

/// <summary>

///A test for DepositMoney

///</summary>

[TestMethod()]

public void DepositMoneyTest()

{

BankAccount_Accessor target = new BankAccount_Accessor(10);

float depositAmount = 10;

target.DepositMoney(depositAmount);

Assert.AreEqual(20, target.CurrentBalance, "Error in depositing 10$");

}

Testing private members in Smart Device Projects should thus, hopefully, be fairly straightforward.

2007-12-13T07:07:00Z

Unit Testing for Smart Devices is one of the key features added as part of Orcas in the Smart Device Development front. This feature has been built upon the existing framework in Visual Studio that enables unit testing desktop projects. It should hopefully be a cakewalk for those already familiar with the testing features in Visual Studio Team Test.

For those who have not already used the testing features in Visual Studio, let me introduce the feature and walk you through a basic scenario of unit testing a smart device library. For a start, I will keep it simple. I will cover other deeper scenarios in the subsequent blogs.

Unit tests are methods marked with the [TestMethod()] attribute and are members of a class marked with the [TestClass()] attribute. The test source code files containing these test classes must be part of a “Smart Device Unit Test Project”.

The test methods contain logic to validate the expected results based on assertions. There are various assertion classes like Assert, StringAssert and CollectionAssert defined in the Unit Testing Framework that provide assertions to validate various conditional statements like Assert.IsTrue(), Assert.AreEqual() etc.

Additionally you can also used the [ExpectedException()] attribute to test whether a particular exception is thrown. In this case the test case will pass if the specified exception is thrown or fail otherwise.

Additionally you can have methods in the test class marked with [AssemblyInitialize()],[ClassInitialize()],[TestInitialize()] to set up the environment appropriately before execution of all tests in the test assembly, or all tests in a class or before each single test respectively. Similarly, you can have methods marked with [AssemblyCleanup()],[ClassCleanup()],[TestCleanup()] to perform environment teardown after execution of all tests in the assembly, or all tests in a class or for each test respectively. All the above attributes are defined in the Microsoft.VisualStudio.TestTools.UnitTesting namespace in Microsoft.VisualStudio.SmartDevice.UnitTestFramework.dll.

Now that we are warmed up, let me show you how to generating unit tests for a smart device project.

1. Setting up the project for which unit tests must be created

Let’s say that we need to test a BankAccount class that is part of a Pocket PC 5.0 C# smart device class library. The code for the BankAccount class is as below:

using System;

using System.Collections.Generic;

using System.Text;

namespace BankAccountDemo

{

public class BankAccount

{

// Properties

private float _currentBalance;

public float CurrentBalance

{

get { return _currentBalance; }

}

// Constructors

public BankAccount(float initialBalance)

{

this._currentBalance = initialBalance;

}

// Methods

public void DepositMoney(float depositAmount)

{

// note that I have a bug here

// I am deducting the deposit amount!!!

this._currentBalance -= depositAmount;

}

public void MakePayment(float paymentAmount)

{

this._currentBalance -= paymentAmount;

}

2. Generating unit tests

Visual Studio can generate test method stubs for all the methods in you class or for a specific method. All one needs to do is right-click the relevant code element and click ‘Create Unit Tests’ from the context menu. Here, we right-click on the class name BankAccount and then ‘Create Unit Tests’. This will bring up the ‘Create Unit Tests’ dialog box which allows you to customize the generated test code.

You can choose to have your tests generated in either VB or C# Smart Device Test Project. For this example select ‘Create a new Smart Device C# Test Project' on the dialog and click OK. Provide the name of the test project and click Create.

This will automatically create a smart device test project containing test method stubs for testing all the methods and properties defined in the BankAccountClass. The test class will look like this:

using BankAccountDemo;

using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace BankAccountTestProject

{

/// <summary>

///This is a test class for BankAccountTest and is intended

///to contain all BankAccountTest Unit Tests

///</summary>

[TestClass()]

public class BankAccountTest

{

/// <summary>

///A test for DepositMoney

///</summary>

[TestMethod()]

public void DepositMoneyTest()

{

// TODO: Initialize to an appropriate value

float initialBalance = 0F;

BankAccount target = new BankAccount(initialBalance);

// TODO: Initialize to an appropriate value

float depositAmount = 0F; target.DepositMoney(depositAmount);

Assert.Inconclusive("A method that does not return a value cannot be verified.");

}

///More test methods for each of the method/property

///in the BankAccountClass ....

}

On creation of the test project, you will also notice the following:

Vsmdi file: The Visual Studio Test List Editor window lets you organize and categorize tests into various test lists. The user created test lists and links to the test cases are persisted in this metadata file. You can ignore this file for the moment.
Testrunconfig file: This file contains settings that control the way the tests are run. We will touch upon this file little later before starting execution of the tests.
Test Project: you will notice that the generated test project has references, in addition to standard system dlls, to the project to be tested and also the Microsoft.VisualStudio.SmartDevice.UnitTestFramework.dll. This dll contains many definitions, classes and attributes, essential to support unit testing for smart devices in Visual Studio. See Device Unit Test Framework for an overview and differences with respect to the desktop unit test framework

3. Updating the test methods to reflect the test case

Now we have the test method stubs, but they may not be entirely meaningful. What we need to do next is initialize the test method i.e. specify the initial and expected values. You may additionally want to tweak the implementation of the test method. For e.g., in the DepositMoneyTest method, we will set the initialBalance = 10F. After initializing a bank account with an initial balance of 10, we will deposit an amount of 5 units. So the expected current balance at the end of the transaction is 15. So we add an assert to verify whether they are the same:

/// <summary>

///A test for DepositMoney

///</summary>

[TestMethod()]

public void DepositMoneyTest()

{

float initialBalance = 10F;

BankAccount target = new BankAccount(initialBalance);

float depositAmount = 5F;

target.DepositMoney(depositAmount);

Assert.AreEqual(target.CurrentBalance, 15F, "Error in depositing money");

}

Now that we have created the project and completed authoring the tests, it’s time to execute them.

How do we specify on which device should we execute the tests? This is where the runconfig file I mentioned earlier comes in. If you double click this file, you will notice that runconfig editor comes up and displays a plethora of options based on which you can configure the test run. Navigate to the ‘Host’ page and you will see that the ‘Host’ is set to ‘Smart Device’ (this is the indication that this test run will be executed on a smart device). You can modify the platform and device to specify which device you want to execute the tests on.

The important point to note here is that the tests will be executed on the device specified in this run config file, and not on the target device that is currently chosen in the device toolbar.

Before starting the run, we need to manually deploy the appropriate version of NETCF on the chosen device. In Orcas, we could not include support for automatic deployment of NETCF and SQLCE, and so the tester must ensure he has manually prepared the device by installing the required cab files.

Once this is done, we are now ready to execute our tests on the device. You can start executing the tests from the Test List Editor Window, or the Test View window, the Test tool bar or from the test source file itself (using the Run Tests context menu). For now, click the ‘Run all tests in solution’ toolbar item in the Test toolbar.

The tests get downloaded and executed on the device and finally you can see the results of the tests in the test results window. You can double click on the result to see the details of the individual test:

Failed DepositMoneyTest Assert.AreEqual failed. Expected:<5>. Actual:<15>. Error in depositing money

Here the test has failed saying that while the expected output was 15, the actual output after depositing money was 5. This implies an error in either the test method or the actual implementation. Here, we know there is an error in the implementation of the DepositMoney() method.

All we need to do is go back to the BankAccount.cs code file and correct the DepositMoney method()

public void DepositMoney(float depositAmount)

{

// The bug was that I was deducting the deposit amount!!!

// this._currentBalance -= depositAmount;

this._currentBalance += depositAmount;

}

And then hit the ‘Run all tests in solution’ toolbar item in the Test Toolbar! This will take care of rebuilding both the projects and rerun the test this time with the correct code. And if you check the test results window, this time round the test passes! I can now safely Deposit my money.

Passed DepositMoneyTest

Hopefully this has been a good start. In the next blog, I will discuss how you can use the unit testing framework to test private methods.

OS Language

WPDT Language

2007-11-29T13:15:00Z

This is my first Blog and am pretty excited to get started. For now, let me be done with the introduction.

I am a QA Lead in the Visual Studio for Devices team working out of the India Development Centre.

I joined Microsoft and this team a little over two years back during the Whidbey Beta2 timeframe. For the rest of the Whidbey lifecycle I worked on Data development scenarios for Smart Devices. I am also proud of just having been through the complete Orcas (VS 2008) life cycle. As part of Orcas, I have contributed to the Smart Device Unit Testing support. For those who are not aware, yes we now have test driven development for smart devices integrated well into the IDE. This feature enables creation, management and execution of tests for device applications built on the .NET Compact Framework. And it uses the same familiar Visual Studio interface as that supported in the Visual Studio Team Test for unit testing desktop applications!

In my blogs I will aim to answer questions and share some thoughts around Unit Testing in the Smart Devices arena and Smart Device development in general. So stay tuned!

-Pratibha