Thursday, 17 February 2011

Package Manager With Source Download

I was skinning up some code and I used my package manager of choice to add NLog to the project.  All good, very easy and away I coded.

The project required a single DLL as an output.  So, I thought hey – I’ll use Paul Stovell’s Tape to save using ILMerge in the build.  Good plan, but after 5 minutes browsing the NLog source on GitHub it realised I was not sure how to find the version I needed.  That’s fine, ILMerge is pretty easy to use so I used the build to save the day.

On the same day (today) I read this post about ReSharper 6 features and suddenly realised how powerful it would be for package managers to be able to give me the source, not just binaries.  Now that’s a killer feature and would be even better if the source came with a single file option so I didn’t even have to run Tape.

Oh, please, soon…

Thursday, 3 February 2011

A Better Deal

Red Gate are now going to charge for Lutz Roeder’s Reflector.  This tool has been free for it's life – more years than I care to remember.  Its as much part of a software developer’s toolkit as a hammer is part of a builder’s toolkit.

I have dealt with Red Gate as part of a very small company and as part of a very large company.  I am sorry to say that each time I have come away feeling less than happy.  Any company that sends be a maintenance bill at the end of year one that exceeds my original purchase price isn't going to make me happy to deal with them!

Reading Red Gates’ pricing strategy, written by their co-founder, Neil Davidson, I struggle to believe their other CEO, Simon Galbraith, when he says how sorry he is about charging for Reflector.  I just kept thinking that they just want my cash - like the other times I’ve dealt with them.

Maybe Galbraith and Davidson should go and listen to Seth Godin’s pricing advice.  Maybe then I’d want to buy stuff from them! 

35USD is good value for Reflector and I may have to buy a copy.  I’d really just rather buy from another company and get a better deal.

Saturday, 23 October 2010

Install the Full .Net 4 Framework with Tarma Installer

If you haven’t seen Tarma InstallMate before, the you need to check this little beauty out.  It’s a fully featured installer that  have been using it in production for just under a year now and the end-user setup installer just drops out of the end of my build process – sweet!

There’s one thing that is very different with Tarma and all the other installers out there – Tarma doesn’t charge stupid rip-off money like all the other suppliers seem to like to do.  You can get their top-of-the-range product for under $90USD per developer.  Couple that with totally superb support, rock solid performance and a really rich feature set, Tarma’s a total winner!

Out of the box, Tarma has support for a number of prerequisites like .Net Framework, Access runtimes and Windows Installer.  However, it doesn’t differentiate between the Full and Client Profiles for .Net 4 – if the Client Profile is detected then it will not install the full framework and I need to get the full framework onto my user’s machine. 

Detecting the Installed Framework Version

To detect which version of the .Net Framework 4 has been installed, you need to check the presence of the following registry keys.

HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Client
HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full

More details on that here.

We can set up Tarma to do that easily, like this:

Read Registry Key into a Variable

Go to Symbolic Variables and add a new variable called IsFullDotnet4.  Then use Tarma’s support for symbolic expressions to read whether the registry key exists by setting the new variable’s value to this:

<$rkaccess(<HKLM>\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full)>

It should now look like this:

SNAGHTML6641ea8

Adjust Prerequisites Condition

Go to the prerequisites section and adjust the condition to install the .Net 4 Runtime by setting the condition to this:

NOT IsFullDotnet4

It should look something like this:

SNAGHTML7d171

That’s all you need – Tarma will now upgrade .Net 4 Client Profile installations to the Full version.

Monday, 4 October 2010

Replacing Strings in XPObject.SetPropertyValue with Lambdas

I came across a post on Aussie Alf’s blog today about removing magic strings from the persistent property setters in the XPO ORM from DevExpress

The Aussie Alf blog is written by Michael Proctor who is a member of the DevExpress community DXSquad, specialising in XPO.  The blog is a superb resource for any XPO developers and really worth reading.  Michael is also a very active member on the DevExpress forums and may well come to your help with an XPO issue there.

XPO uses a classic INotifyPropertyChanged pattern and passes a string of the changed property name into SetPropertyValue method.  You can see this below:  

  1. public class Customer : XPObject
  2. {
  3.    private string _number;
  4.    public string Number
  5.    {
  6.       get { return _number; }
  7.       set { SetPropertyValue("Number", ref _number, value); }
  8.    }
  9. }

The problem with this approach is that the compiler can’t determine whether the string is correct or not, leaving you open to potential runtime errors.  Michael’s solution to this to generate a helper class that can be used in the property setter and he has a Visual Studio plugin that generates and refreshes the helper class for you based on your domain model. 

This is a great approach to the problem and you can read more about it on the homepage for Michael’s plugin, XPO_EasyFields.

Michael’s XPO_EasyFields plugin uses the free DXCore Visual Studio plugin from DevExpress.  Personally, I use Resharper and don’t have DXCore installed, so I thought I would share my approach to removing the magic strings - I use a helper class and lambdas to do this.  It looks like this:

  1. public class Customer : XPObject
  2. {
  3.    private string _number;
  4.    public string Number
  5.    {
  6.       get { return _number; }
  7.       set { SetPropertyValue(Property<Customer>.Name(x => x.Number), ref _number, value); }
  8.    }
  9. }

This relies on the use of a generic Property class and a helper method that gleans the property name from a Linq Expression.  The property class looks like this:

  1. public static class Property<T>
  2. {
  3.    public static string Name(Expression<Func<T, object>> expression)
  4.    {
  5.       if (expression == null) throw new ArgumentNullException("expression");
  6.       if (expression.Body is MemberExpression) return ((MemberExpression)expression.Body).Member.Name;
  7.  
  8.       if (expression.Body is UnaryExpression && ((UnaryExpression)expression.Body).Operand is MemberExpression)
  9.       {
  10.          return ((MemberExpression)((UnaryExpression)expression.Body).Operand).Member.Name;
  11.       }
  12.  
  13.       throw new ArgumentException(string.Format("Could not get property name from expression of type '{0}'",
  14.                                                 expression.GetType()));
  15.    }
  16. }

The magic comes from translating the little lambda expression x => x.Name to a string.  If I remember right, I originally based this on some code from Jeremy Miller, but there are various implementations out there.  Here’s and elegant one from Paul Stovell that’s focused purely on INotifyPropertyChanged. 

As Paul mentions in the above link, it’s worth noting that there is a performance hit when using this approach.  Michael’s approach of generating the code does not have any performance hit.  You may need to consider the performance issue if you have very high rates of properties being set. 

I did some simple performance tests that show a 10-15x overhead with my approach compared to Michael’s.  However, this only becomes relevant with a very large number of property sets.  For my usage scenarios the added quality benefit outweighs the performance hit, but you will need to carefully consider your scenario.

Lastly, to take this further, and get an even tighter syntax, I add this helper method to my persistent classes:

  1. protected void Set<T>(Expression<Func<Customer, object>> property, ref T holder, T value)
  2. {
  3.    SetPropertyValue(Property<Customer>.Name(property), ref holder, value);
  4. }

This allows the setter to be even more compact:

  1. private string _number;
  2. public string Number
  3. {
  4.    get { return _number; }
  5.    set { Set(x => x.Number, ref _number, value); }
  6. }

The downside is that you need the helper method in each class.  Down to taste that really, but I always go for the tighter syntax wherever possible! 

You can get the code from bitbucket and browse the salient parts here.

Thursday, 21 January 2010

Sometimes It Just Works

Some things in life that just do what they say they will do and when this happens you get blown away. 

VMware Workstation says it lets you use Visual Studio to debug an application that is running on a virtual machine.  I used this recently and was blown away by how easy it was to set up and by how amazingly useful it was.

The story is that I released a new build for informal testing, but it could not be installed.  I installed it onto a clean XP VM (yeah, I should have done that already…) and got the error myself.  However, there was no error information coming back from the application as the failure was happening before the logging layer was instantiated.

I was stuck.  I could reproduce, but had no other information to help.  Then I remembered that VMware Workstation had the facility to debug apps running on VMs.  So, I followed the instructions (yes, I was desperate enough to read the VMware help file!!) and set up a VM for remote debugging.  This was pretty swift to achieve and I then started a debugging session on the VM from Visual Studio. 

Almost immediately I could see what was happening: it was my bad – I’d just forgotten to include a third-party assembly with the build.  My dev box was happily loading it from the GAC and so I couldn’t see I’d missed anything.

VMware Workstation just did what it said it would do.  in doing so, it got me out of a sticky situation.  Also, it says it has the ability to record and replay a debugging session…maybe next time, eh?

In the meantime, and whilst loving the things that go right, here’s a shot of the error from VS debugging on the VM:

image

Thursday, 7 January 2010

Friendly OS Name from WMI

When you want to find out what operating system your application is running on, System.Environment.OSVersion is not very readable.  You can get a nice friendly name using WMI like this:

  1: private static string GetOSName()
  2: {
  3:    const string query = "SELECT * FROM Win32_OperatingSystem";
  4:    var searcher = new ManagementObjectSearcher(query);
  5:    var results = from x in searcher.Get().OfType<ManagementObject>()
  6:            select x.GetPropertyValue("Caption");
  7:    return results.Any() ? results.First().ToString() : "Unknown";
  8: }


This will give you something like "Microsoft® Windows Server® 2008 Enterprise ".

Saturday, 18 April 2009

Cloud Computing – SMD Services

Rinat Abdullin has recently put up an interesting post about cloud computing, along with another post as a response to a comment of mine.  Rinat pointed out the benefits cloud scenarios bring when there is a need for distributed computing resources, highlighting Amazon’s recent announcement along with Microsoft’s offerings in that space

I agree with Rinat that distributed computing scenarios are clearly winners for cloud computing.  However, my view is that one of the critical success factors for the success of cloud computing will be developer adoption.  If you have developers using your product it will succeed (as a cloud platform), if you don’t then…well, you get it!  My view is that the larger organisations who already have their own infrastructure will certainly adopt cloud resources, but it will not be these organisation that will drive the adoption of cloud technologies.  It will be the small to medium enterprises (SME) for whom the effort to host themselves is a large compared to their overall effort to stay in business.

What is going to drive SME uptake – having software that delivers business advantage.  How does this get to them – by developers producing it for them.  Making your cloud platform accessible and usable for developers will drive wider adoption.

In Rinat’s second post he mentions a scenario where if he had had a cloud platform like Azure available, cost could have been saved.  He also outlines the basis for how cloud computing will reduce the overall costs of the adoption of a the provided in the cloud – the larger data centres selling their idle CPU cycles. 

He then points out that there is fast evolving market for hosted developer environments where you can easily and cheaply access version control, wiki, issue tracker services, etc.  In an earlier post I mentioned one such provider, WUSH, with whom I have had a positive experience throughout the last year in the smaller scale development work I do out of normal working hours. 

It is this area – developer services – that I see as the key to making cloud computing ubiquitous.  If you can provide developers with full-lifecycle support from your platform they will come in their droves.  By full lifecycle, I mean support for planning, production, test and live all in an integrated set of cloud services.

As mentioned, there we see some support for planning and some aspects of production already out there (search for “hosted subversion”, take a look at Scrumy or Manymoon, etc.), and you can but cost efficient test and live  environments (by renting your own server).  But to get other aspects running, like a build or CI environment, involves setting it up yourself on a server you have rented yourself.  However, doing that would not be using SaaS beyond having a server hosted in the cloud.  Unfortunately, I know of no decently priced build service that for commercial projects.

What do I want to see?  In the short term, I’m missing a sensibly cheaply priced build services for commercial projects (see James Kovac’s recent announcement of their new Team City service for OS projects).  In the longer term I want to be able to have a fully hosted CI environment that prices me by disk and CPU usage. 

The ultimate goal: Microsoft to host TFS and reduce the cost of adoption for SMDs (small to medium developers :) ) to the Team System versions of Visual Studio.

In the meantime, will I be using the current set of cloud services?  Absolutely, both in my production processes as an SMD and for services that my clients will use.  And, I am doing this for the the reasons Rinat has outlined!