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
Friday, July 16, 2010
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!
Wednesday, May 12, 2010
MSTest: Not Executed after aborting a debugged MSTest
If you try to debug a MS Test unit test in VS 2008 but stop the debugger before the test is completed (abort the test) the test status will be marked with "Aborted". Which is fine and expected. But if you then try to execute any other test, whether this is debugging a test or just executing a test, it will fail and the status of all attempted tests will be "Not Executed". And from here in no tests will ever execute again..until you kill process "vsperfmon.exe". If you kill that process, then unit tests will then continue to execute.
This defect seems to be fixed in VS 2010 which is great but it still exists in VS 2008 which is a pain as Windows Mobile developers still require VS 2008 to develop WM apps (this defect applies to both desktop and device tests).
There is a bug report on Microsoft Connect: https://connect.microsoft.com/VisualStudio/feedback/details/299925/after-debugging-a-unit-test-vsperfmon-exe-must-be-killed-to-be-able-run-further-tests
As always, if you find this defect annoying, then use the site above to vote for a fix.
This bug has been around for sometime and it's only today I learned the workaround!
This defect seems to be fixed in VS 2010 which is great but it still exists in VS 2008 which is a pain as Windows Mobile developers still require VS 2008 to develop WM apps (this defect applies to both desktop and device tests).
There is a bug report on Microsoft Connect: https://connect.microsoft.com/VisualStudio/feedback/details/299925/after-debugging-a-unit-test-vsperfmon-exe-must-be-killed-to-be-able-run-further-tests
As always, if you find this defect annoying, then use the site above to vote for a fix.
This bug has been around for sometime and it's only today I learned the workaround!
To inject IServiceLocator or not to inject
I had a discussion the other day about it being a bad idea to inject the IServiceLocator as a dependency into the constructor of consuming types. Now I'm talking about the Common Service Locator by the p&p team at Microsoft (http://commonservicelocator.codeplex.com/) but to be honest this applies to the Service Locator pattern in general.
The argument was based on the fact that it makes testing more difficult as you not only have to mock or provide types to the constructor but you have to add them to a service locator if injecting the service locator interface.
There are valid reasons for not doing this but we don't live in an ivory tower and sometimes we need to pull types from the container at runtime that we simply do not know at design time. In this case it makes perfect sense for using a service locator, right? as the whole point of the pattern is to abstract container from implementation code.
I'm curious of other developers feel for this and their approach as to whether they do this or not, and if so why.
The argument was based on the fact that it makes testing more difficult as you not only have to mock or provide types to the constructor but you have to add them to a service locator if injecting the service locator interface.
There are valid reasons for not doing this but we don't live in an ivory tower and sometimes we need to pull types from the container at runtime that we simply do not know at design time. In this case it makes perfect sense for using a service locator, right? as the whole point of the pattern is to abstract container from implementation code.
I'm curious of other developers feel for this and their approach as to whether they do this or not, and if so why.
Friday, April 23, 2010
Turning off the context menu scrolling in VS2010
UPDATE (28/03/2011): This has been fixed in VS2010 SP1: http://www.simonrhart.com/2011/03/unnecessary-context-scrolling-in-vs.html
If you have noticed in VS2010 when right clicking something and displaying the context popup menu. You sometimes get a scrollable menu appear in which you have to use the mouse wheel, or press the up or down arrows that are displayed for this type of menu to see all items in the popup menu.
Sadly turning off this "feature" is not possible as it seems to be a bug: https://connect.microsoft.com/VisualStudio/feedback/details/532806/context-menus-open-in-scrolling-mode-while-there-is-place-to-show-the-whole-menu/?wa=wsignin1.0
If you find this bug annoying enough, please vote on the connect site so hopefully we will get a hot fix rather than having to wait for SP1.
If you have noticed in VS2010 when right clicking something and displaying the context popup menu. You sometimes get a scrollable menu appear in which you have to use the mouse wheel, or press the up or down arrows that are displayed for this type of menu to see all items in the popup menu.
Sadly turning off this "feature" is not possible as it seems to be a bug: https://connect.microsoft.com/VisualStudio/feedback/details/532806/context-menus-open-in-scrolling-mode-while-there-is-place-to-show-the-whole-menu/?wa=wsignin1.0
If you find this bug annoying enough, please vote on the connect site so hopefully we will get a hot fix rather than having to wait for SP1.
[TFS 2010] (1835): Task failed because "resgen.exe" was not found
I recently upgraded my build server from TFS 2010 RC (which worked fairly well I have to say) - although its worth pointing out here that VS 2010 RTM doesn't work with TFS 2010 RC. You get all kinds of build errors.
I recently checked some code in and the build server gives me the following error:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets (1835): Task failed because "resgen.exe" was not found, or the correct Microsoft Windows SDK is not installed. The task is looking for "resgen.exe" in the "bin" subdirectory beneath the location specified in the InstallationFolder value of the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0A. You may be able to solve the problem by doing one of the following: 1) Install the Microsoft Windows SDK. 2) Install Visual Studio 2010. 3) Manually set the above registry key to the correct location. 4) Pass the correct location into the "ToolPath" parameter of the task.
So I have given in and installed Visual Studio on the build server and this seems to fix the problem! - I know this just doesn't sound right.... I could of tried and installed the Windows SDK on the build server but I do want to build Windows phone 7 Series apps on my build server and I know that bits in WP7 are not in the Windows SDK.
I recently checked some code in and the build server gives me the following error:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets (1835): Task failed because "resgen.exe" was not found, or the correct Microsoft Windows SDK is not installed. The task is looking for "resgen.exe" in the "bin" subdirectory beneath the location specified in the InstallationFolder value of the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0A. You may be able to solve the problem by doing one of the following: 1) Install the Microsoft Windows SDK. 2) Install Visual Studio 2010. 3) Manually set the above registry key to the correct location. 4) Pass the correct location into the "ToolPath" parameter of the task.
So I have given in and installed Visual Studio on the build server and this seems to fix the problem! - I know this just doesn't sound right.... I could of tried and installed the Windows SDK on the build server but I do want to build Windows phone 7 Series apps on my build server and I know that bits in WP7 are not in the Windows SDK.
Wednesday, April 21, 2010
ServiceLocator.Current - calls the SetServiceLocator delegate everytime!
If like me you were under the impression that calling ServiceLocator.SetLocalProvider result would be cached when using static member ServiceLocator.Current then you'll be wrong.
I was surprised to find out that the ServiceLocator implementation passed to ServiceLocator.SetLocalProvider was created everytime I called ServiceLocator.Current.
I know I should always inject IServiceLocator into the ctor of the consumer types, but there are rare occasions that I need to use ServiceLocator.Current in static classes.
The implementation of ServiceLocator.Current looks like so:
So instead of doing this:
If you have no idea what I am talking about in this post, please see the Common Service Locator by the p&p team at Microsoft here: http://commonservicelocator.codeplex.com/
I was surprised to find out that the ServiceLocator implementation passed to ServiceLocator.SetLocalProvider was created everytime I called ServiceLocator.Current.
I know I should always inject IServiceLocator into the ctor of the consumer types, but there are rare occasions that I need to use ServiceLocator.Current in static classes.
The implementation of ServiceLocator.Current looks like so:
public static IServiceLocator CurrentcurrentProvider() is a good old fashioned delegate and looks like so:
{
get { return currentProvider(); }
}
public delegate IServiceLocator ServiceLocatorProvider();
So instead of doing this:
ServiceLocator.SetLocatorProvider(() => new WindsorServiceLocator(_container));Do this:
IServiceLocator castle = new WindsorServiceLocator(_container);You will get a load less garbage collections as a result.
ServiceLocator.SetLocatorProvider(() => castle);
If you have no idea what I am talking about in this post, please see the Common Service Locator by the p&p team at Microsoft here: http://commonservicelocator.codeplex.com/
Monday, March 29, 2010
Making use of the Command Pattern on Windows Mobile/phone
The Command pattern is a great pattern for abstracting business processes from your implementation code. This pattern is becoming very popular throughout different types of systems. Whether this is MVC thin client, fat clients such as MVP, MVVM.
The Command pattern works really nicely in combination with a IoC container and DI framework that I have talked about before on this blog.
Often it is desirable for a command to take a context or state. A command should only have one method and should only have one role (single responsibility). The interface for a command could look like so:
So imagine we have a CRM system that when a customer is registered, we want to send that customer an email to confirm he/she has been setup correctly. You might have a domain model in this case that raises an event that is caught on the middle tier. When this occurs, instead of baking that code into the presenter/controller/business class, you abstract it out into a command. This not only makes your system more readable/maintainable but makes it easier to test too.
So in this case you could have a context class that contains the state such as the Customer domain object like so:
Very clean approach. Of course the more dependencies you add to the command, the more complex it will become which means harder to test. So sometimes commands can become over complex. Bear this in mind when adopting this pattern.
Executing the command could look something like the following(assuming you are using the service locator):
The Command pattern works really nicely in combination with a IoC container and DI framework that I have talked about before on this blog.
Often it is desirable for a command to take a context or state. A command should only have one method and should only have one role (single responsibility). The interface for a command could look like so:
public interface ICommand<T>So our context here is a generic and is defined when the command is registered with the container.
{
void Execute(T context);
}
So imagine we have a CRM system that when a customer is registered, we want to send that customer an email to confirm he/she has been setup correctly. You might have a domain model in this case that raises an event that is caught on the middle tier. When this occurs, instead of baking that code into the presenter/controller/business class, you abstract it out into a command. This not only makes your system more readable/maintainable but makes it easier to test too.
So in this case you could have a context class that contains the state such as the Customer domain object like so:
public class EmailCustomerConfirmationContextOur command might look something like the following:
{
public EmailCustomerConfirmationContext(Customer customer)
{
Customer = customer;
}
public Customer Customer{get; private set;}
}
public class EmailCustomerConfirmationCommand : ICommand<EmailCustomerConfirmationContext>Registering the command with the container (Compact Container - see previous posts on using this container) would look something like the following:
{
private IEmailAdapter _emailAdapter;
public EmailCustomerConfirmationCommand(IEmailAdapter emailAdapter)
{
//inject dependencies here.
_emailAdapter = emailAdapter;
}
public void Execute(EmailCustomerConfirmationContext context)
{
_emailAdapter.Send(context.Customer);
}
}
container.AddComponent<ICommand<EmailCustomerConfirmationContext>, EmailCustomerConfirmationCommand>();
Very clean approach. Of course the more dependencies you add to the command, the more complex it will become which means harder to test. So sometimes commands can become over complex. Bear this in mind when adopting this pattern.
Executing the command could look something like the following(assuming you are using the service locator):
var command = ServiceLocator.Current.GetInstance<ICommand<TContext>>();In terms of handling errors etc, this could be handled via events using some sort of event aggregator pattern or the context itself to pass back data so the middle tier can act accordingly.
if (!command.IsNull())
{
command.Execute(context);
}
Sunday, March 28, 2010
TFS 2010 - the new build definition window
Jason Prickett has recently written a good article on the new Build definition window in VS 2010 - it's now dockable! It also has a new CI type named Gated-checkin. So developers need to have a green CI before they can checkin. Cool. I have been checking this new Gated-checkin feature out in the RC version recently, and I'm not sure it is working correctly. But will write back soon on my findings.
See here:
http://blogs.msdn.com/jpricket/archive/2010/01/19/tfs-2010-the-new-build-definition-window.aspx
See here:
http://blogs.msdn.com/jpricket/archive/2010/01/19/tfs-2010-the-new-build-definition-window.aspx
Cool new feature with VS2010 and TFS 2010
I recently installed TFS 2010 RC x64 and only now got round to playing with it. I have to say once I got over the 'gremlins' during the installation everything else is pretty slick. There are many features I like and many that are going to make our lifes better.
One of the really horible things I hated about VS 2008 and TFS 2008 was after a partially succeeded build, opening up the build output in Build Explorer would only tell you something went wrong. In other words, the build partially suceeded. What? what does this mean? we know from experience this generally means a unit test had failed, but which one, and how do I fix it?
The only way to know which unit test had failed would be to troll through the build log - very painful when you have a large build script spanning multiple projects and 1000's of unit tests. I used to search for "FAIL". But some developers name their unit tests with the word "FAIL" in it so this doesn't help matters as it takes forever to find the real error.
So I created a really simple test project and added a test method that throw an exception, after I checked in under a CI build definition, I got the following:
Now, how cool is that! Weldone Microsoft. I think this will make many developers very happy. Look at the options we get at the top, [Open Drop Folder], [Retain Indefinately] etc it just makes our lifes easier. But the best bit, the reason for posting this blog entry, If I click "View Test Results" I get the following:
I'm impressed, this will make us so much more productive, a reason alone to upgrade. Excellent stuff!
One of the really horible things I hated about VS 2008 and TFS 2008 was after a partially succeeded build, opening up the build output in Build Explorer would only tell you something went wrong. In other words, the build partially suceeded. What? what does this mean? we know from experience this generally means a unit test had failed, but which one, and how do I fix it?
The only way to know which unit test had failed would be to troll through the build log - very painful when you have a large build script spanning multiple projects and 1000's of unit tests. I used to search for "FAIL". But some developers name their unit tests with the word "FAIL" in it so this doesn't help matters as it takes forever to find the real error.
So I created a really simple test project and added a test method that throw an exception, after I checked in under a CI build definition, I got the following:
Now, how cool is that! Weldone Microsoft. I think this will make many developers very happy. Look at the options we get at the top, [Open Drop Folder], [Retain Indefinately] etc it just makes our lifes easier. But the best bit, the reason for posting this blog entry, If I click "View Test Results" I get the following:
I'm impressed, this will make us so much more productive, a reason alone to upgrade. Excellent stuff!
Subscribe to:
Posts (Atom)
