Last night the UK ALM user group was fantastic. I really enjoyed it and we had good discussions going. So thanks to Stuart Preston for setting it up and thanks to the speakers, Karel Deman from Avanade for a great talk and Howard van Rooijen.
Which leads me to why I started to write this post. Howard demoed a tool he built called StyleCop for Resharper.
Now if you've never heard of ReSharper - shame on you, then you can search my blog or the web for info on it. If you've never heard of StyleCop then again search the web or read this post that should give you a quick overview of what StyleCop is designed to address: http://blogs.msdn.com/b/sourceanalysis/archive/2008/05/23/announcing-the-release-of-microsoft-source-analysis.aspx
Just quickly; StyleCop is a code style analysis tool. It at compile time will inspect your code against a pre-determined set of rules to determine whether your code complies with your companies coding style implicitly. The problem with it is it only tells you what is wrong with your code when you compile. And in order to get a list of "failures" you have to look at the warning tab in the 'Errors' window in Visual Studio.
When you install StyleCop: http://code.msdn.microsoft.com/sourceanalysis you get the option to install MSBuild targets that you can call during your automated build process. I haven't yet tried this but I will. As what you can do is fail the build if a developer has not complied to your companies codeing style.
Don't confuse StyleCop with FxCop or (Code Analysis) they are very different. Code Analysis inspects your assemblies post compilation for good practices in terms of how you have built your solution, i.e. implementing IDisposable when consumed types support it. Proper use of localization and best practice use of the .NET class libraries.
StyleCop for ReSharper is a ReSharper plugin (yes ReSharper supports plugins even though ReSharper is itself a VS plugin). What it does is it works like ReSharper, so as you type, it will inspect your code and tell you whether you are breaching StyleCop rules for that project. And as per ReSharper style, of hitting Alt+Enter, it gives you corrective options to fix your code for you!
I like it alot. I think it really is a great tool. Combined with the StyleCop build targets I think this can work well in a team environment. As to configuring your projects for StyleCop use, StyleCop creates a file in each project directory that it reads. It doesn't work like Code Analysis, where the settings are baked into the .proj file. So I'm thinking maybe include that file in Source Control so each dev machine doesn't have to configure their machine everytime a new environment is spun up or a new project is added to the solution.
Check it out here: http://stylecop.forresharper.org/
Thursday, September 23, 2010
Tuesday, September 21, 2010
UK ALM User group
We Hitachi Consulting are hosting the next UK ALM user group at 2 More London (London Bridge) tomorrow night 22nd September.
Now I'm not sure if it is too late to register at this time, but the event brite registration page can be found here: http://ukalmug-september2010.eventbrite.com/
Now I'm not sure if it is too late to register at this time, but the event brite registration page can be found here: http://ukalmug-september2010.eventbrite.com/
Thursday, September 02, 2010
No need for server side clientaccesspolicy.xml when using Silverlight for Windows phone 7 Series
If you're a seasoned Silverlight developer you'll be well aware of having to incorporate the clientaccesspolicy.xml file in the root of your service domain with a method that returns the file as a Stream object. MSDN documentation that describes that and the documentation can be found here: http://msdn.microsoft.com/en-us/library/cc197955(VS.95).aspx
Then you would typically define a method that looks like the following that is accessible via a RESful call (if using WCF) - note: the UriTemplate here is what is important:
When calling any web method from a Windows phone Silverlight application, the 'GetClientAccessPolicy' is not called so there is (currently no need for it if your clients are from WP7 apps).
I'm not sure if this will change when the WP7 tools RTM on the 16th September - I will be the first to try!
My colleague Anthony Cooper found this out, so thanks to him.
Then you would typically define a method that looks like the following that is accessible via a RESful call (if using WCF) - note: the UriTemplate here is what is important:
[OperationContract, WebGet(UriTemplate = "/clientaccesspolicy.xml")]Executing any method from within a desktop Silverlight app whether in-browser or out-of-browser (SL 3 feature) will call that method above implicitly by the SL HTTP stack.
Stream GetClientAccessPolicy();
When calling any web method from a Windows phone Silverlight application, the 'GetClientAccessPolicy' is not called so there is (currently no need for it if your clients are from WP7 apps).
I'm not sure if this will change when the WP7 tools RTM on the 16th September - I will be the first to try!
My colleague Anthony Cooper found this out, so thanks to him.
Windows Phone 7 Series released to RTM
Just in case you haven't heard the news yet, yesterday Windows Phone 7 Series was released to RTM: http://windowsteamblog.com/windows_phone/b/windowsphone/archive/2010/09/01/windows-phone-7-released-to-manufacturing.aspx
Excellent work to the Windows Phone team!
So now we wait for OEMs to produce some hardware...not long I'm sure.
The tools RTM on 16th September: http://windowsteamblog.com/windows_phone/b/wpdev/archive/2010/08/23/a-developer-s-roadmap-to-windows-phone-7-launch-timing.aspx
Excellent work to the Windows Phone team!
So now we wait for OEMs to produce some hardware...not long I'm sure.
The tools RTM on 16th September: http://windowsteamblog.com/windows_phone/b/wpdev/archive/2010/08/23/a-developer-s-roadmap-to-windows-phone-7-launch-timing.aspx
Wednesday, July 28, 2010
Building your Windows Phone 7 Series apps using Team Foundation Server 2010
UPDATE: There is a workaround to what I have said here. See this post - a really cool way to build WP7 targeting different WP7 builds: http://justinangel.net/WindowsPhone7EmulatorAutomation#BlogPost=TFS2010WP7ContinuousIntegration
So the ultimate question is, how do I build my Windows Phone 7 Series apps on TFS and perhaps run unit tests against a Windows phone 7 series emulator. The short answer is you can't, well that's not entirely true. You can build your Windows phone 7 series apps on TFS so long as you install the developer tools on your build server.
Bear in mind when you install the developer tools you will not only get all the required build targets and Silverlight framework for Windows phone 7 series but also a VS2010 IDE as well. This will either be VS2010 Express edition if you don't already have VS2010 RTM installed on your server, or the tools will integrate into VS2010 RTM (if installed). Either way, you are going to get an IDE on your build server.
This might sound rather ugly and I have asked Microsoft for separation of the tools/framework etc from the IDE so ISVs/consultancies can be more flexible how they build their apps. But this is really not high on Microsofts priority list right now. The reason is simple. These tools are targeted toward consumers, so the majority or at least what Microsoft would like is the majority of people building apps/games for Windows phone 7 series are individual programmers whether professional or ameteur and not big companies. Long term this will change.
Instead, the priority is to deliver a really quick and easy way to get up and running building Silverlight or XNA apps for Windows phone. And Microsoft has done this. Simply go to http://developer.windowsphone.com/ and you can download a single package, run it and this will set your machine up ready to build and ship apps on the Windows phone platform. No other downloads are required.
The cool thing about this is, unlike Windows Mobile development, the tools are free. A great step forward.
So to recap, in order for more professional programmers to build Windows phone apps using a sophisticated continuous integration yada yada solution, you need to install the tools on your build server, but you will get the IDE as well.
I also mentioned unit testing. Currently the latest beta tools do not support unit testing on the emulator. Of course you can still write unit tests that execute on the desktop against your Silverlight for Windows phone apps. I have a sample of this over at http://wp7.codeplex.com/
Happy coding!
So the ultimate question is, how do I build my Windows Phone 7 Series apps on TFS and perhaps run unit tests against a Windows phone 7 series emulator. The short answer is you can't, well that's not entirely true. You can build your Windows phone 7 series apps on TFS so long as you install the developer tools on your build server.
Bear in mind when you install the developer tools you will not only get all the required build targets and Silverlight framework for Windows phone 7 series but also a VS2010 IDE as well. This will either be VS2010 Express edition if you don't already have VS2010 RTM installed on your server, or the tools will integrate into VS2010 RTM (if installed). Either way, you are going to get an IDE on your build server.
This might sound rather ugly and I have asked Microsoft for separation of the tools/framework etc from the IDE so ISVs/consultancies can be more flexible how they build their apps. But this is really not high on Microsofts priority list right now. The reason is simple. These tools are targeted toward consumers, so the majority or at least what Microsoft would like is the majority of people building apps/games for Windows phone 7 series are individual programmers whether professional or ameteur and not big companies. Long term this will change.
Instead, the priority is to deliver a really quick and easy way to get up and running building Silverlight or XNA apps for Windows phone. And Microsoft has done this. Simply go to http://developer.windowsphone.com/ and you can download a single package, run it and this will set your machine up ready to build and ship apps on the Windows phone platform. No other downloads are required.
The cool thing about this is, unlike Windows Mobile development, the tools are free. A great step forward.
So to recap, in order for more professional programmers to build Windows phone apps using a sophisticated continuous integration yada yada solution, you need to install the tools on your build server, but you will get the IDE as well.
I also mentioned unit testing. Currently the latest beta tools do not support unit testing on the emulator. Of course you can still write unit tests that execute on the desktop against your Silverlight for Windows phone apps. I have a sample of this over at http://wp7.codeplex.com/
Happy coding!
Monday, July 26, 2010
Username and password format for TFS on codeplex
When you first setup a project on codeplex there is a popup that tells you what domain\username and password to use to connect to the TFS server.
But I found after setting up a project I couldn't remember what the format should be.
So this post is really for my benefit if nothing else, here it is:
Username: snd\<username>_cp
Password: <Codeplex password>
But I found after setting up a project I couldn't remember what the format should be.
So this post is really for my benefit if nothing else, here it is:
Username: snd\<username>
Password: <Codeplex password>
Sunday, July 25, 2010
I'm TestDriven.Net
Thanks to the chaps over at http://testdriven.net/ I got the opportunity to test their product.
So, one of the real problems with Visual Studio when it comes to unit testing your code is it is really slow and unproductive.
If I write a test method in C#, I often want to quickly run it and run it often as this is the whole point of TDD isn't it. If you use MSTest you'll probably find this is the slowest testing tool available but its great integration with TFS often makes it a desirable choice.
To quickly test our method we normally right click the method in code, and select "Run Tests". This will (if a MSTest) switch to the Test Results window and show you the result of the test, great. But...you'll find this quite slow. Then what if you want to debug a test. First you have to run the individual test as said above, then check the check box and hit Debug Test.

This is fine but all very time consuming, why can't I just say Debug this test without having to run it first, check the check box, then hit Debug test.
This is where TestDriven.Net comes into play. Now after installing the tool, I have a new menu item when right clicking my test "CanResolveTransientComponent":

So here I can hit "Run Test(s)" and it will execute the test in a fraction of the time that Visual Studio will do it. When doing this, TestDriven.Net will switch to the output window and show the test output:

So 0.36 seconds is pretty fast. When running via Visual Studio it is much longer, perhaps around 2 seconds for the same test.
The reason for this is when you execute via TestDriven.Net, it omits MSTest code coverage. This greatly speeds up the testing process. If and when you're interested in code coverage you can ask TestDriven.Net to give it to you.
There is a submenu when you right click your test method:

I like this submenu alot. It gives great flexibility in how you run your tests. If you want to simply debug your test without have to go through the lengthy steps mentioned earlier, simply select "Debugger". Sweet.
As mentioned earlier regarding code coverage. When quickly executing a test the MSTest code coverage is omitted in order to speed up the test greatly. But if you want MSTest code coverage then you can select "Coverage" from this handy submenu. This will give you pretty much the same results as if you ran the test via Visual Studio itself.
As you can probably see, if you use another test tool other than MSTest, there is integration for NCover. In fact NCover works for MSTest too. Selecting NCover from the submenu fires up the NCover Explorer tool that gives you a code coverage for the test(s) you have selected to run:

This is a great feature, I do like this.
Another really cool feature that I'd like to mention is support for performance testing. Selecting "Performance" from the TestDriven.Net submenu gives you a nice breakdown of performance data for your test:

There are many more features to checkout with TestDriven.Net and I recommend you check them out.
So, one of the real problems with Visual Studio when it comes to unit testing your code is it is really slow and unproductive.
If I write a test method in C#, I often want to quickly run it and run it often as this is the whole point of TDD isn't it. If you use MSTest you'll probably find this is the slowest testing tool available but its great integration with TFS often makes it a desirable choice.
To quickly test our method we normally right click the method in code, and select "Run Tests". This will (if a MSTest) switch to the Test Results window and show you the result of the test, great. But...you'll find this quite slow. Then what if you want to debug a test. First you have to run the individual test as said above, then check the check box and hit Debug Test.

This is fine but all very time consuming, why can't I just say Debug this test without having to run it first, check the check box, then hit Debug test.
This is where TestDriven.Net comes into play. Now after installing the tool, I have a new menu item when right clicking my test "CanResolveTransientComponent":

So here I can hit "Run Test(s)" and it will execute the test in a fraction of the time that Visual Studio will do it. When doing this, TestDriven.Net will switch to the output window and show the test output:

So 0.36 seconds is pretty fast. When running via Visual Studio it is much longer, perhaps around 2 seconds for the same test.
The reason for this is when you execute via TestDriven.Net, it omits MSTest code coverage. This greatly speeds up the testing process. If and when you're interested in code coverage you can ask TestDriven.Net to give it to you.
There is a submenu when you right click your test method:

I like this submenu alot. It gives great flexibility in how you run your tests. If you want to simply debug your test without have to go through the lengthy steps mentioned earlier, simply select "Debugger". Sweet.
As mentioned earlier regarding code coverage. When quickly executing a test the MSTest code coverage is omitted in order to speed up the test greatly. But if you want MSTest code coverage then you can select "Coverage" from this handy submenu. This will give you pretty much the same results as if you ran the test via Visual Studio itself.
As you can probably see, if you use another test tool other than MSTest, there is integration for NCover. In fact NCover works for MSTest too. Selecting NCover from the submenu fires up the NCover Explorer tool that gives you a code coverage for the test(s) you have selected to run:

This is a great feature, I do like this.
Another really cool feature that I'd like to mention is support for performance testing. Selecting "Performance" from the TestDriven.Net submenu gives you a nice breakdown of performance data for your test:

There are many more features to checkout with TestDriven.Net and I recommend you check them out.
Sunday, July 18, 2010
Windows Phone 7 Extension Tools
I started porting some code from the Compact Framework over to Silverlight for Windows Phone.
I have created a project on codeplex: http://wp7.codeplex.com/. The solution so far contains an IoC with support for implicit dependency injection - in fact this is a port from the Compact Container on the CF. It also contains a port of the Common Service Locator for the desktop by the p&p team at Microsoft.
The project is designed to be a work in progress and I'll add stuff to it if I think it might be useful to others.
I do plan over the next couple of days to add an event aggregator to the solution that will integrate with the container nicely to promote nice loosely coupled multicast event model in your Silverlight applications.
I am also working on an API that allows communication with the Microsoft Azure Service Bus - much like you get on the desktop. I will checkin as soon as it is available.
The current solution that is checked in is designed to be used with the latest release of Windows Phone developer tools beta.
I have created a project on codeplex: http://wp7.codeplex.com/. The solution so far contains an IoC with support for implicit dependency injection - in fact this is a port from the Compact Container on the CF. It also contains a port of the Common Service Locator for the desktop by the p&p team at Microsoft.
The project is designed to be a work in progress and I'll add stuff to it if I think it might be useful to others.
I do plan over the next couple of days to add an event aggregator to the solution that will integrate with the container nicely to promote nice loosely coupled multicast event model in your Silverlight applications.
I am also working on an API that allows communication with the Microsoft Azure Service Bus - much like you get on the desktop. I will checkin as soon as it is available.
The current solution that is checked in is designed to be used with the latest release of Windows Phone developer tools beta.
Friday, July 16, 2010
Windows phone virtual live class - July 20th and July 22nd
Jump start your development of Windows Phone 7 applications by attending Windows Phone 7 JumpStart. This free virtual live class, comprised of four instructor-led 3 hour sessions, will guide you in developing applications for the Windows Phone 7 platform using Silverlight and XNA. Register today by visiting: https://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032455932&EventCategory=2&culture=en-US&CountryCode=US.
Course sessions:
July 20 – 8am: Session One: Getting Started with Microsoft Windows Phone and Silverlight
July 20 – 1pm: Session Two: Programming Game Applications with XNA
July 22 – 8am: Session Three: Programming Applications with Silverlight
July 22 – 1pm: Session Four: Review and Wrap Up
Course sessions:
July 20 – 8am: Session One: Getting Started with Microsoft Windows Phone and Silverlight
July 20 – 1pm: Session Two: Programming Game Applications with XNA
July 22 – 8am: Session Three: Programming Applications with Silverlight
July 22 – 1pm: Session Four: Review and Wrap Up
Wednesday, July 14, 2010
Pivot and Panorama support in Windows phone 7 beta
The title of this blog post is a little confusing (it was meant to be!) in that there is no support for the Pivot and Panorama controls in the latest bits of Windows phone dev tools. The controls pictured above are courtesy of Stephane Crozatier.
Those controls are freely available on codeplex to download but were designed for the CTP bits of Windows phone. So as there were some breaking changes between the CTP and the recently released beta they won't work out of the box. But it very easy to fix.
Firstly you need to do delete the Microsoft.Phone.* references and add the Microsoft.Phone.dll to the project. All those additional dlls have been merged into Windows.Phone.dll.
Then you'll need to clean up the XAML namespaces. Luckily for me I have ReSharper 5.0 installed and all I have to do is press Alt+Enter and it fixes all my problems! nice


Now if you want the sample WeatherForecast app to run you need to do 1 last thing. That is the ApplicationBarIconButton class now has a mandatory Text property so you need to set this property for each of the buttons in the MainPage.xaml file.
Now once I clean up all that XAML, I rebuild and run and I get...

Sweeet....
Another nice cool thing with this emulator over the older Windows Mobile emulators is that you can do a ALT+Prnt Scrn to get a copy of the current focused window. You can't do this on Windows Mobile emulators.
Another nice cool thing with this emulator over the older Windows Mobile emulators is that you can do a ALT+Prnt Scrn to get a copy of the current focused window. You can't do this on Windows Mobile emulators.
Windows phone UK User group

I just learn't there has recently been a Windows phone 7 UK user group setup. The first meeting is 28th July at Conchangos offices in London. http://wpug.net/.
Microsofts Paul Foster and Rob Fonseca-Ensor will be speaking. There is now a wait list on the event but worth a try right!
Monday, July 12, 2010
First impressions Windows Phone Developer Tools beta
I just installed the beta bits released this evening and as per the CTP the install experience is brilliant. Except with the beta the greatest thing is support for Visual Studio RTM. So unlike the CTP, even if you had VS RTM installed, then you installed the WP7 dev tools, the installer would install the CTP of VS express and not integrate with VS RTM. Actually I found a whole bunch of errors when attempting this with the CTP. 
However this build is good. I'm running VS 2010 Ultimate and VS 2008 Team Suite and this build integrated with VS 2010 RTM nicely.
New project in VS 2010 RTM (no support for VB.NET though):

However this build is good. I'm running VS 2010 Ultimate and VS 2008 Team Suite and this build integrated with VS 2010 RTM nicely.
It is also worth noting in this release of WP7 dev tools, you get Expression Blend 4 for Windows Phone beta. In the CTP you had to download this separately.
So experience so far is great, well done Windows Phone 7 team.
Emulator running bing:
I'll post my experiences of actually writing WP7 code using these bits in later posts. In the mean time you can download and try for yourself.
Windows Phone Developer Tools Beta is here
Announced today at WPC. Get it from: http://www.microsoft.com/downloads/details.aspx?FamilyID=c8496c2a-54d9-4b11-9491-a1bfaf32f2e3&displaylang=en
Check out this post on breaking changes from CTP to Beta: http://blogs.msdn.com/b/jaimer/archive/2010/06/28/migrating-apps-from-windows-phone-ctps-to-the-beta-build.aspx?wa=wsignin1.0
I'll post my feedback once I've installed it and tried it out.
Notice this under "System Requirements:"
This Beta of the Windows Phone Developer Tools is compatible with the final version of Visual Studio 2010
This has made my day :)
Check out this post on breaking changes from CTP to Beta: http://blogs.msdn.com/b/jaimer/archive/2010/06/28/migrating-apps-from-windows-phone-ctps-to-the-beta-build.aspx?wa=wsignin1.0
I'll post my feedback once I've installed it and tried it out.
Notice this under "System Requirements:"
This Beta of the Windows Phone Developer Tools is compatible with the final version of Visual Studio 2010
This has made my day :)
Friday, July 02, 2010
Testing Motorola EMDK WLAN implementation on the desktop
I've been writing about testing recently and whether or not to use device test projects or desktop test projects. You can read my view on this in a previous blog post.
No doubt if you have written code for any of the Motorola rugged devices (or other rugged OEM devices) you might have encountered the EMDK WLAN class (or similar if not coding against the EMDK) - which wraps the low-level mobile specific Motorola Fusion API. This is a prime example of why you should use a desktop test project rather than device project. Hang on, you just said the Fusion API can only execute on the device, so don't we need a device test project? No. The reason is simple, again if you have a continuous integration, automated build process setup, your tests will be executing on the build server so you won't be able to execute those tests against a real Motorola device. If you have a device test project, the best you can do is execute those tests on the Windows Mobile emulator - but what will this prove? In this case this is really no different in terms of a test problem than executing them on the desktop.
So this is a reason to write your WLAN tests within a desktop test project. Let me demonstrate...
The WLAN class that comes with the EMDK (Symbol.Fusion.WLAN.WLAN) is a prime example, to make things worst, it doesn't implement an interface, take a look:

So this makes it almost impossible to test. Instead how I have overcome this problem is to write an adapter that wraps the WLAN class, then mock out the adapter using Rhino Mocks. Observe the following WLAN implementation, the interface isn't important:
The next thing is our actual adapter. The interface for the adapter looks like this
So if this were a device test project, we'd have to mock out the adapter by hand, then pass it in to the constructor to the MotorolaMC75WLAN class. But as we have decided to use a desktop test project we can use any mocking framework that we choose which enables us free of having to do the laborious hand mocking work.
You can download Rhino Mocks from here if you don't already have it: http://www.ayende.com/projects/rhino-mocks/downloads.aspx. Download the zip and extract it somewhere on your hard disk, then add a reference the Rhino Mocks assembly in your test project - there is only one dll you need to reference.

Add a
There you have it, a true mocking framework put at use in the mobile space.
If you want to learn more about mocking frameworks, use Google, there are millions of articles out there on the subject.
No doubt if you have written code for any of the Motorola rugged devices (or other rugged OEM devices) you might have encountered the EMDK WLAN class (or similar if not coding against the EMDK) - which wraps the low-level mobile specific Motorola Fusion API. This is a prime example of why you should use a desktop test project rather than device project. Hang on, you just said the Fusion API can only execute on the device, so don't we need a device test project? No. The reason is simple, again if you have a continuous integration, automated build process setup, your tests will be executing on the build server so you won't be able to execute those tests against a real Motorola device. If you have a device test project, the best you can do is execute those tests on the Windows Mobile emulator - but what will this prove? In this case this is really no different in terms of a test problem than executing them on the desktop.
So this is a reason to write your WLAN tests within a desktop test project. Let me demonstrate...
The WLAN class that comes with the EMDK (Symbol.Fusion.WLAN.WLAN) is a prime example, to make things worst, it doesn't implement an interface, take a look:

So this makes it almost impossible to test. Instead how I have overcome this problem is to write an adapter that wraps the WLAN class, then mock out the adapter using Rhino Mocks. Observe the following WLAN implementation, the interface isn't important:
public class MotorolaMC75WLAN : IWLANServiceSo that is our high level implementation that can be easily extended and contains no low-level mobile code. The adapter in this case is injected and can be anything we want it to be which allows us to test this class easily on the desktop.
{
private readonly IMotorolaWLANAdapter _adapter;
private bool _disposed;
public MotorolaMC75WLAN(IMotorolaWLANAdapter adapter)
{
_adapter = adapter;
}
public void Enable()
{
if (!_adapter.IsEnabled)
{
_adapter.Enable();
_adapter.PowerStatusChanged += OnPowerStatusChanged;
}
}
private void OnPowerStatusChanged(object sender, PowerStatusChangedEventArgs e)
{
//raise events to interested parties....perhaps using some sort of event aggregator
}
public void Disable()
{
if (_adapter.IsEnabled)
{
_adapter.Disable();
_adapter.PowerStatusChanged -= OnPowerStatusChanged;
}
}
public bool IsEnabled
{
get { return _adapter.IsEnabled; }
}
public void RenewDHCP()
{
_adapter.RenewDHCP();
}
public void Connect()
{
_adapter.Connect();
}
#region IDisposable Members
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
#endregion
private void Dispose(bool disposing)
{
if (!_disposed)
{
if (disposing)
{
Disable();
_adapter.Dispose();
}
_disposed = true;
}
}
}
The next thing is our actual adapter. The interface for the adapter looks like this
public interface IMotorolaWLANAdapter : IDisposableThe implementation is low-level that talks directly to the WLAN class (Fusion API). I'm not going to include a typical implementation for this but an example Enable() method might look like the following:
{
void Enable();
void Disable();
bool IsEnabled { get; }
void RenewDHCP();
event EventHandlerPowerStatusChanged;
void Connect();
}
public void Enable()It simply enables the first adapter it can find. Non-of the real adapter is testable.
{
if (IsEnabled)
return;
Symbol.Fusion.WLAN.WLAN command = null;
try
{
command = new Symbol.Fusion.WLAN.WLAN(FusionAccessType.COMMAND_MODE);
command.Adapters[0].PowerState = Adapter.PowerStates.ON;
}
catch (OperationFailureException ex)
{
//do something...
}
finally
{
if (command != null)
command.Dispose();
}
}
So if this were a device test project, we'd have to mock out the adapter by hand, then pass it in to the constructor to the MotorolaMC75WLAN class. But as we have decided to use a desktop test project we can use any mocking framework that we choose which enables us free of having to do the laborious hand mocking work.
You can download Rhino Mocks from here if you don't already have it: http://www.ayende.com/projects/rhino-mocks/downloads.aspx. Download the zip and extract it somewhere on your hard disk, then add a reference the Rhino Mocks assembly in your test project - there is only one dll you need to reference.

Add a
using Rhino.Mocks;to your test class. Now if you wanted to mock out the adapter Enable method, in Rhino Mocks world it could look like the following using the newer triple A syntax:
[TestMethod]So the only actual thing we are testing here is the real MC75 WLAN class and not the adapter. The code is fairly easy to read. We are simply telling Rhino Mocks to expect exactly 1 call to Enable() when _wlan.Enable() is called. The thing to bear in mind here is to ensure your actual adapter doesn't contain bugs as we can't automate those tests on the build server.
public void ShouldEnableWLAN()
{
IMotorolaWLANAdapter _mockWLANAdapter = MockRepository.GenerateMock<IMotorolaWLANAdapter>();
IWLANService _wlan = new MotorolaMC75WLAN(_mockWLANAdapter);
_mockWLANAdapter
.Expect(x => x.Enable())
.Repeat.Once();
_wlan.Enable();
_mockWLANAdapter.VerifyAllExpectations();
}
There you have it, a true mocking framework put at use in the mobile space.
If you want to learn more about mocking frameworks, use Google, there are millions of articles out there on the subject.
Thursday, July 01, 2010
Automated testing considerations for enterprise Windows Mobile projects - avoid a world of pain
I know in the past I have written blog posts on how to create unit tests that are actually executed on the Windows Mobile emulator which is great if you have mobile specific tests. But to be honest, when you are building large scale enterprise mobile solutions targeting a range of different devices i.e. Motorola, Casio, Intermec etc. Writing device specific platform tests for all these devices becomes quite hard to automate when using an application lifecyle management solution such as Visual Studio and TFS with its continuous integration and automated test execution support.
Even if you only support one type of device, when you do enterprise mobile development, using the tools mentioned above, you're not going to be able to automate those tests as part of a nightly build or even a CI build. As you will no doubt be using the vanilla Windows Mobile Emulators that know nothing about such specifics that you might be testing such as barcode reader, credit card reader, bluetooth stack etc. Instead you would normally write adapters or mock out implementation code when testing your barcode implementation. You'll generally never write an actual test that calls the true native code on that platform, why would you anyway unless it's part of an integration test. Ensuring you do this allows you to write unit tests, integration tests that do run as part of your nightly and CI builds that do improve code quality.
So what type of tests should you write for most of your code base, device or desktop? My advice is desktop even if you think your device project is small, there will come a time when your project becomes large and more complex. The benefit to targeting the desktop is the ability to use mocking frameworks. We tend to use Rhino Mocks and today there are 0 mocking frameworks available on the CF. If you start to go down to road of writing your own mocks, then you're entering a world of pain. When you think of it, most code can be tested on the desktop anyway. For things like data access, if you use SQL CE 3.5, then this can run on the desktop. For the features that require explicit device testing, then create a single device test project for this purpose and exclude it from the build definition.
Even if you only support one type of device, when you do enterprise mobile development, using the tools mentioned above, you're not going to be able to automate those tests as part of a nightly build or even a CI build. As you will no doubt be using the vanilla Windows Mobile Emulators that know nothing about such specifics that you might be testing such as barcode reader, credit card reader, bluetooth stack etc. Instead you would normally write adapters or mock out implementation code when testing your barcode implementation. You'll generally never write an actual test that calls the true native code on that platform, why would you anyway unless it's part of an integration test. Ensuring you do this allows you to write unit tests, integration tests that do run as part of your nightly and CI builds that do improve code quality.
So what type of tests should you write for most of your code base, device or desktop? My advice is desktop even if you think your device project is small, there will come a time when your project becomes large and more complex. The benefit to targeting the desktop is the ability to use mocking frameworks. We tend to use Rhino Mocks and today there are 0 mocking frameworks available on the CF. If you start to go down to road of writing your own mocks, then you're entering a world of pain. When you think of it, most code can be tested on the desktop anyway. For things like data access, if you use SQL CE 3.5, then this can run on the desktop. For the features that require explicit device testing, then create a single device test project for this purpose and exclude it from the build definition.
Wednesday, June 30, 2010
Versioning team builds to match assembly version numbers
Have you ever wanted to version your team builds to match your assembly versions. Stuart Preston shows how to easily achieve this in Team Build 2010 over at: http://stuartpreston.net/blog/2010/05/02/simple-assembly-versioning-with-team-build-2010/
I've just tried this and it works nicely, great stuff!
I've just tried this and it works nicely, great stuff!
Monday, June 28, 2010
Automating your Windows Mobile 6.x builds on TFS 2010
If you have recently attempted to build your Windows Mobile 6.x code using the new TFS 2010 recently you might have received this error:
(81): The imported project "C:\Windows\Microsoft.NET\Framework64\v3.5\Microsoft.CompactFramework.CSharp.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.
It is pretty clear as to what the issue is, so how do you fix this? Well you can install Visual Studio 2008 (Device development is not supported on VS 2010) on your build server - not nice, but then this won't fix my issue here. Notice the path above. The smart device project is looking in the 64-bit location for the Compact Framework build targets files: C:\Windows\Microsoft.NET\Framework64. As my build server is running on Windows Server 2008 R2 - which only comes in 64-bit edition, it makes sense to use 64-bit tools.
The easy fix for this type of configuration is to install the .NET Compact Framework 3.5 Redistributable which can be found here: http://www.microsoft.com/downloads/details.aspx?FamilyID=e3821449-3c6b-42f1-9fd9-0041345b3385&displaylang=en. Install that package on the build server which will allow your code to compile.
Then download the .NET CF 3.5 Power Toys - this will give your the Compact Framework build targets that MSBuild needs. This can be downloaded from here: http://www.microsoft.com/downloads/details.aspx?FamilyID=c8174c14-a27d-4148-bf01-86c2e0953eab&displaylang=en. Again that package needs to be installed on the build server. You may think it is odd that the build targets are included in this package, then so did I. They are also included with VS2008 but installing the Power Toys is a much better solution as it's a lot smaller install.
Now remember with my configuration I mentioned earlier, I am running 64-bit server, as there is no 64-bit edition of .NET CF Power Toys, the build targets get installed to the 32-bit location on the file system: C:\Windows\Microsoft.NET\Framework\v3.5 but by default my build definition is set to "Auto" which will choose the 64-bit edition first, then use the MSBuild path to find the build targets. This will still result in a failed build because the 64-bit edition will be running from: C:\Windows\Microsoft.NET\Framework64\v3.5 and that path doesn't contain the files we need. So a simple change to the build definition to use x86 is needed:
(81): The imported project "C:\Windows\Microsoft.NET\Framework64\v3.5\Microsoft.CompactFramework.CSharp.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.
It is pretty clear as to what the issue is, so how do you fix this? Well you can install Visual Studio 2008 (Device development is not supported on VS 2010) on your build server - not nice, but then this won't fix my issue here. Notice the path above. The smart device project is looking in the 64-bit location for the Compact Framework build targets files: C:\Windows\Microsoft.NET\Framework64. As my build server is running on Windows Server 2008 R2 - which only comes in 64-bit edition, it makes sense to use 64-bit tools.
The easy fix for this type of configuration is to install the .NET Compact Framework 3.5 Redistributable which can be found here: http://www.microsoft.com/downloads/details.aspx?FamilyID=e3821449-3c6b-42f1-9fd9-0041345b3385&displaylang=en. Install that package on the build server which will allow your code to compile.
Then download the .NET CF 3.5 Power Toys - this will give your the Compact Framework build targets that MSBuild needs. This can be downloaded from here: http://www.microsoft.com/downloads/details.aspx?FamilyID=c8174c14-a27d-4148-bf01-86c2e0953eab&displaylang=en. Again that package needs to be installed on the build server. You may think it is odd that the build targets are included in this package, then so did I. They are also included with VS2008 but installing the Power Toys is a much better solution as it's a lot smaller install.
Now remember with my configuration I mentioned earlier, I am running 64-bit server, as there is no 64-bit edition of .NET CF Power Toys, the build targets get installed to the 32-bit location on the file system: C:\Windows\Microsoft.NET\Framework\v3.5 but by default my build definition is set to "Auto" which will choose the 64-bit edition first, then use the MSBuild path to find the build targets. This will still result in a failed build because the 64-bit edition will be running from: C:\Windows\Microsoft.NET\Framework64\v3.5 and that path doesn't contain the files we need. So a simple change to the build definition to use x86 is needed:
Once you make that change, queue a new build and your build should succeed.
As for getting VS 2008 talking to TFS2010, I'll write a post on getting that to work. There is a lot of content on this in the community but a lot of it didn't work for me.
Thursday, May 27, 2010
Installing Windows 7 on a netbook

I recently bought an Asus Eee PC 1001 HA netbook for my wife to use for a really good price as it was an ex demo (end of line). This model has been superseded by a better model that includes a slightly faster CPU Intel Atom 1.66Ghz as the 1001 has a Intel Atom 1.6Ghz N270 processor. The newer model also comes with Windows 7 as oppossed to Windows XP which is what the 1001 model comes with. I have to say, I think it is brilliant.
As mentioned it came with Windows XP Home Premium edition but as this was for my wife she didn't care. But after getting home I relised I couldn't join it to the Windows Server 2008 domain controller because Home Premium doesn't support Windows Domains. So she couldn't print, fax, access family pictures, get an IP address from the DHCP, access TFS..(not really, shes not a coder!) etc etc You can't even access a network UNC path from Home Edition.
So XP clearly had to come off. So we installed Windows 7 Ultimate x86, bearing in mind this little machine only has 1gb of DDR2 RAM and it runs very well indeed.
But the problem I found was installing the Windows 7 OS without a CD drive and no access to a network share? All I have are USB ports. So as I don't have a optical USB CD drive, I simply downloaded Windows 7 USB/DVD Download Tool from codeplex, found here: http://wudt.codeplex.com/ It is actually written in C# under Visual Studio 2008, with full source code available to download.
This tool allows you to create a bootable USB flash card. So all I had to do was create a bootable USB flash card using the Windows 7 ISO, configure the BIOS on the Asus to boot from USB, install Windows 7, then job done.
Windows 7 USB/DVD Download Tool
In fact this tool works with DVD's as well, so it will be useful for future DVD burning.
This blog talks about disabling various Windows 7 services for optimization on a netbook pc, but to be honest I didn't need to disable anything, it just works really nicely.
I did forget to mention that I download Asus's drivers for optimal WLAN, display adapter etc to better performance and to get the machine to behave correctly.
Good job Asus...
Saturday, May 22, 2010
Moving Windows Azure CTP account over to RTM - don't forget to remove any unwanted services!
If like me you recently moved your Windows Azure CTP account over to an RTM account, ensure you delete any services that you don't want as you might be charged. I completely forgot I had 2 services deployed in Staging and 2 services deployed in production when I moved my account over. So a few weeks ago I had a bill for £187.10! I had been viewing my bills regularly and didn't see any charges until 24/04/10. So the charges were from 25/03/10 - 24/04/10.
The important thing to note here is the pricing model in Windows Azure - I'm talking about hosting services which is the deploying of services and running services in the cloud bit of Windows Azure - not the Service Bus or SQL Azure - they have different pricing models.
The charges are based on "compute hours". Although do note there are two types of pricing models within Azure. The first is a pay as you go type model so you only pay for what you use. The other model is a fixed contract where you agree to a fixed discounted monthly fee for a given time frame and any excess usage is charged at the standard rate.
Do be aware, no matter whether your services are being used or not even if your services are not running this still eats into your "compute hours". It sounds unfair from the outset, but I don't think it is unfair as for those charges you get a dedicated VM, CPU, memory etc to your services. So you can be sure you'll have the resources available to serve up requests when needed.
So as I am an MSDN Premium subscriber, I opted for the promotional offer of "free" services. So under this offer you get 750 "compute hours" under Windows Azure, 1,000,000 ACS transaction requests on AppFabric, 3 web edition databases etc. See here for more info on this promotional offer: http://www.microsoft.com/windowsazure/offers/popup.aspx?lang=en&locale=en-US&offer=MS-AZR-0005P
Utilization over the "free" 750 hours will be charged at the standard rate.
Of course that works out to be one service constantly deployed in the cloud for 24 hrs a day for 31 days. So essentially free.
Now regarding my bill I received, the good news is Microsoft refunded me the £187.10 due to the fact I forgot to remove the services and the fact that I didn't realize they were still deployed as I have only been using the Service Bus within Windows Azure lately (now known as the AppFabric). So I am grateful to Microsoft for doing this as they legally didn't have to.
So when I noticed the bill, the first thing I wanted to do was delete the services to prevent further costs mounting up.
So I went to the Windows Azure maintenance portal over at http://windows.azure.com/ clicked on Windows Azure and noticed the services. But the Delete button was disabled:
The important thing to note here is the pricing model in Windows Azure - I'm talking about hosting services which is the deploying of services and running services in the cloud bit of Windows Azure - not the Service Bus or SQL Azure - they have different pricing models.
The charges are based on "compute hours". Although do note there are two types of pricing models within Azure. The first is a pay as you go type model so you only pay for what you use. The other model is a fixed contract where you agree to a fixed discounted monthly fee for a given time frame and any excess usage is charged at the standard rate.
Do be aware, no matter whether your services are being used or not even if your services are not running this still eats into your "compute hours". It sounds unfair from the outset, but I don't think it is unfair as for those charges you get a dedicated VM, CPU, memory etc to your services. So you can be sure you'll have the resources available to serve up requests when needed.
So as I am an MSDN Premium subscriber, I opted for the promotional offer of "free" services. So under this offer you get 750 "compute hours" under Windows Azure, 1,000,000 ACS transaction requests on AppFabric, 3 web edition databases etc. See here for more info on this promotional offer: http://www.microsoft.com/windowsazure/offers/popup.aspx?lang=en&locale=en-US&offer=MS-AZR-0005P
Utilization over the "free" 750 hours will be charged at the standard rate.
Of course that works out to be one service constantly deployed in the cloud for 24 hrs a day for 31 days. So essentially free.
Now regarding my bill I received, the good news is Microsoft refunded me the £187.10 due to the fact I forgot to remove the services and the fact that I didn't realize they were still deployed as I have only been using the Service Bus within Windows Azure lately (now known as the AppFabric). So I am grateful to Microsoft for doing this as they legally didn't have to.
So when I noticed the bill, the first thing I wanted to do was delete the services to prevent further costs mounting up.
So I went to the Windows Azure maintenance portal over at http://windows.azure.com/ clicked on Windows Azure and noticed the services. But the Delete button was disabled:
This is not particularly intuitive, but you have to click "Suspend" which is the same as stop. Then the Delete button becomes enabled that allows you to delete the services!
Subscribe to:
Posts (Atom)