Friday, April 23, 2010

Turning off the context menu scrolling in VS2010

UPDATE (28/03/2011): This has been fixed in VS2010 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:

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.

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:
public static IServiceLocator Current
get { return currentProvider(); }
currentProvider() is a good old fashioned delegate and looks like so:
public delegate IServiceLocator ServiceLocatorProvider();

So instead of doing this:
ServiceLocator.SetLocatorProvider(() => new WindsorServiceLocator(_container));
Do this:
IServiceLocator castle = new WindsorServiceLocator(_container);
ServiceLocator.SetLocatorProvider(() => castle);
You will get a load less garbage collections as a result.

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: