Outpourings

Getting Unity to resolve a parameter to a named type/instance of a registered type/interface

Dependency injection and IoC are a particularly wonderful kind of magic – I’m really only just beginning to get to grips with using it in a practical sense (and resisting the urge to spend the next month or three just writing tests and refactoring code to be tested) but once you start it becomes addictive as you see the benefits.

I use Unity. Whether that’s the right solution doesn’t really bother me – I have it and it works and it does all the things I want…

So, a simple problem – I have a set of providers of that impement IThingyProvider, they in turn require a a ThingyProviderConfiguration or a descendant (since Thingies can have varying number of parameters depending on the nature of the Thingy). How then do I inject the right Configuration object into a given ThingyProvider ?

How about:

public MyThingyProvider([Dependency(“My”)] ThingyProviderConfiguration config)

{

    this.Config = config;

}

Huge amounts of “it just works”

I found the answer on stackoverflow here so kudos (and an upvote if this is useful) to Chris Tavares

I need a better deployment Story - Part 2 of Several

Just Deploy Something

Ok, so I need a better deployment story – for it to work well for me it needs to be driven from my Continuous Integration server – the very wonderful TeamCity from JetBrains. But before I get there (the reason for writing all these words) I need to think about the actual deployment process.

It turns out that Microsoft have made it very very easy to do one-click deplyoment from Visual Studio and in a better/nicer way than just FTP. If you set up (or have set up) MSDeploy/Webdeploy at both ends i.e. on your dev box and on your server then a very small amount of configuration goes a surprisingly long way…

I ought to have pictures here!

Running IIS7 with WebDeploy installed I can export a Publish Settings file which when splatted into the appropriate boxes in the Publish Profile dialog causes magic to happen. The magic in this case being to push the defined/required content for your web application to the server (and potentially to delete any spurious files that are still on the server so you may need to exercise caution).

This is great, load up visual studio, push a button and it compiles and builds and gets deployed to the server… great!

The are two problems here first is configuration – and that’s trivially dealt with – the second is that way before we got to “if you’re using xcopy you’re doing it wrong” I (and more than a few others) had worked out that if you’re deploying from Visual Studio you’re doing it wrong.

This bears a bit of review – what you’re aiming for is a high level of confidence that you can build and deploy your application to order. In practical terms this means you need to be able to do a build and your application from a clean checkout from source control ideally on a minimally configured box (i.e. not your dev box). Further you want to create from this build something you can deploy.

The first bit you do by having a proper CI server set up so that you know when you commit that what has been committed will build. (If you’re good you also know that it has passed a whole pile of unit type tests too and, if you’re really good, that a scheduled overnight build has run a pile or repeatable integration type tests.) The second bit I currently do (courtesy of former colleague) is post build to have all the needed files packaged into a zip file that I can copy to the server (which is interesting for reasons we’ll come to in a minute) and from which I can to do an xcopy to my site directories (test and live) meaning that I have the same thing in multiple places.

One of the nice things you can do is autmagically assign assembly version numbers as part of the build process – so mine are 1.0.{revision}.{build number} where the build number comes from team city (its simply a count of how many times a build configuration has been triggered). Given this I can know how to get to the source for a given deployment and have some confidence that I’m dealing with the same version of the code across the board if investigating discrepancies between Test and Live.

This brings up another reason why deploying from Visual Studio is a problem – you want nice incrementing version numbers to go with your (deployed) builds. Whilst there is support for this built in its a bit hairy with multiple developers building and committing – and doing it by hand it just another opportunity to forget a step. The version number for anything I build locally is 1.0.0.0 (or similar its the trailing .0.0 that’s significant). So deploy from Visual Studio is very nice… but it ain’t right!

A few paragraphs ago I said that configuration was trivially dealt with, well maybe not entirely trivial but Visual Studio 2010 (more accurately MS Build) introduced Config Transforms that let you vary your web.config (and other config files if you bing enough) according to your build configuration (e.g. Debug, Test, Release). Transforms are applied as part of the deployment process.

Ok, at this point I’ve meandered around a bit – lets try and get back on track…

I have a web application, I have a server upon which I wish to deploy that application,  I can easily set up visual studio to publish to that server using Web Deploy in the process of that deployment I can make changes to my web.config to change application settings and connection settings by using config transformations. Nice, but not ideal – not least because you want to be certain that the code you deploy is the code that is safely committed to your version control system.

Fortunately Microsoft have you covered! Right about the publish option on the context menu for the application is another option:

Build Deployment Package – what this does is, erm, build a deployment package – a what? – A deployment allpackage is a zip file containing your site and some other things that you can copy to your server and with a right click in IIS you can import the contents into a website – its not unlike the .zip file that I mentioned earlier that I currently use excepting that its considerable smarter.

What gets even more interesting is that when this file is built Visual Studio doesn’t just output the package it also creates a few more fun things:

Packaging into C:\Dev\ComoStreet\StopMailSender\StopSaleMailer\obj\Test\Package\StopSaleMailer.zip.
Package "StopSaleMailer.zip" is successfully created as single file at the following location:
file:///C:/Dev/ComoStreet/StopMailSender/StopSaleMailer/obj/Test/Package
To get the instructions on how to deploy the web package please visit the following link:
http://go.microsoft.com/fwlink/?LinkId=124618
Sample script for deploying this package is generated at the following location:
C:\Dev\ComoStreet\StopMailSender\StopSaleMailer\obj\Test\Package\StopSaleMailer.deploy.cmd
For this sample script, you can change the deploy parameters by changing the following file:
C:\Dev\ComoStreet\StopMailSender\StopSaleMailer\obj\Test\Package\StopSaleMailer.SetParameters.xml

A .cmd that will allow you to deploy this thing automagically (outside of visual studio) and a parameters that will allow you to twiddle some things when you do.

At this point its important to remember that Visual Studio doesn’t actually build things itself, it uses MS Build or other things plugged in… so if I can build a package within Visual Studio it stands to reason that I can do so outside of visual studio…

At this point I need to actually work out the next step for myself so I shall publish this and start on the next post

I need a better deployment story – Part 1 of several?

The adage has it that if it isn’t broken don’t fix it. I have two deployment methods on my current live systems and they both “work” in that I can do deployments with some confidence.

For reference the two methods are:

1. Build a nice zipped package of things to deploy (copy into the live folder) on my build server (as an artifact) download, unzip (I have a script to do this), check and xcopy.
2. Deploy a website by SVN update.

These both work, but neither is without issues and there are far too many steps with the former and for the latter in one case I need to remember to build (and commit) to deploy.

The biggest problem comes if one needs to deploy several things at once (and usually early in the morning) that the processes are to varying degrees manual means they’re both slow and there is potential for error (this is true any time you’re attempting to deploy under pressure). This has bitten me recently…

So its become clear that I need to do better – lots more automation and *cough* a bit more testing (especially something to give me confidence that the newly deployed code is running nicely – never mind working right, working at all is your first test)

The other thing is that the world has moved on a bit recently – this is covered by Scott Hanselman in his post and video Web Deployment Made Awesome: If You're Using XCopy, You're Doing It Wrong and so not only do I need a better deployment story but its easy (or at least it should be!) to write one. So here we go…

Getting jQuery to apply in update panel in ASP.NET Dynamic Data

I recently spent a lot of time attempting to solve what ought to have been a relatively simple problem - not because its necessarily a hard problem to solve but rather because I didn't know what the (simple) solution to the problem was.

The problem

I'm using ASP.NET Dynamic data to allow me to create maintenance apps for various databases (or views of databases) that underpin the suite of web applications I'm working on. There are date fields so I need a date picker. Previously I've used Microsoft's AJAX Extender but the css for that doesn't play nicely with the css for dynamic data so its not really useable (and my css skills aren't up to fixing it). Since I've started doing very simple things with jQuery (probably simple because of jQuery!) I though there's bound to be a date picker and indeed there is, as part of jQuery UI.

So far so simple... add jQuery and jQuery UI to the project the solution to providing a date picker becomes a matter of adding a class to the TextBoxes that are used to edit dates and then running 1 line of javascript to cause the necessary magic to occur.

This line in fact:

  $(".datepicker").datepicker()

So where to run this? Well that's easy - one $(document).ready(...) later and you're all sorted right? Erm, no - wrong.

Why is there a problem?

That's easy - dynamic data is more than a little bit clever, full of good stuff some of which makes life a bit more interesting than one would like. Specifically - in addressing this problem - it makes use of update panels which are Ajax wrappers that mean that the page is going to get changed dynamically after its been loaded. This in turn means that when you load the page it may well be in a view mode and only when you choose to edit add or a record will it dynamically create the text (input) boxes without fully reloading the page and hence, if I've got this right (!) without firing .ready

How to solve it

Clearly to sort this out you need to find a way to trigger the script when the page is updated after its been initially loaded. So quite a lot of bing and a smidge of google later I found this Simplify ASP.NET AJAX client-side initialization and suddenly things become very easy... setup a pageLoad() function that contains the right incantation and each time the page is updated it goes hunting for the elements decorated with the right css class attribute and there you are, it all works.

Walkthrough the solution

As I said, I want to use this on my dynamic data sites. These use various forms of magic to assemble list and edit pages from a Linq to SQL or Linq to Entities dataset, some page and field templates and some specialist server controls. If we assume that we want to have the date picker on all DateTime fields then the first thing we need to do is edit the user control that's used to edit DateTime fields (or you could copy this to a new user control for plain Dates but that requires a bit more work).

The nice thing about this solution is that the changes to the edit control are almost none...

So first find the Field Templates which are (from the root of the website) in DynamicData\FieldTemplates and open DateTime_Edit.ascx - in there you will find a text box as follows:

<asp:TextBox ID="TextBox1" runat="server" CssClass="droplist" Text='<%# FieldValueEditString %>' Columns="20"></asp:TextBox>

All we need to do is add a new class which we're going to use to indicated to jQuery that this should have a datepicker, I've used "datepicker" so we add that to CssClass and we get:

<asp:TextBox ID="TextBox1" runat="server" CssClass="droplist datepicker" Text='<%# FieldValueEditString %>' Columns="20"></asp:TextBox>

That's it for that (did I mention that I like jQuery!)

Ok, now we need to make some stuff happen, first thing is to go off to jQuery UI and download the required files, the project I did this in already had jQuery added. I used the jQuery UI custom builder, the only required element is the jQuery UI core. Add the downloaded files (a jquery ui .js file, some .css and a pile of images for the theme) into your project in appropriate folders.

I like simple so I'm going to add this to the master page for the site so that it always "just works" when needed. Yes that means a bit of a teeny overhead but not one that you'd notice and Dynamic Data apps are not what you'd call optimised in the first place.

So... in site.master you need to add the following (adjusted appropriately for your site structure).

    <link type="text/css" href="/css/ui-lightness/jquery-ui-1.8.1.custom.css" rel="Stylesheet" />  
    <script type="text/javascript" src="/scripts/jquery-1.4.2.min.js"></script>
    <script type="text/javascript" src="/scripts/jquery-ui-1.8.1.custom.min.js"></script>
    <script type="text/javascript">
    function pageLoad() {
    $('.datepicker').datepicker({
    changeMonth: true,
    changeYear: true,
    dateFormat: 'dd-M-yy',
    gotoCurrent: true
    });
    }
    </script>

First load the stylesheet, then the jQuery file then the custom jQuery UI file then a pageLoad() function that has the one line magic. $('.datepicker') means find me all the elements which have the class datepicker, .datepicker() means add a datepicker to each of those elements and the rest are options which define how we'd like the picker to appear/work - so changeMonth means I'd like a month drop down, changeYear means I'd like a year drop down, date format will give us 22-May-2010 or equivalent (I have users in the UK and the US and that will help avoid errors) and finally gotCurrent means that I want it to default to the date in the text box (assuming there is one) rather than today's date.

So that was half a day or so to work out how to write a function containing one line of code that gives me a really tidy solution to my problem... jQuery is wonderful, Dynamic Data is pretty damned impressive too... either untouched or if you can work out how to make it do what you want (ideally without having to write custome pages)

Challenges with Dynamic Data and Connection Strings

I'm almost certainly missing something here - but DynamicData is somewhat under-documented and there are lots of assumptions about connection strings (not just in dynamic data) that I have problems with in the real world (where I want to trivially configure same on a per instance basis).

 

When I had the data model class in the web application there wasn't a problem - data comes from the web.config (well actually from a connections.config) but when I moved the data model into its own class things got interest (i.e. they stopped working)

 

But... the model has lots of extensibility hooks so I've now got a simple fix for using a custom connection string - still pulled, indirectly, from the app's web.config.

 

First off lets deal with the location of my connection strings. I play with web applications, these need to work on my local box, in a test instance and in one or more live instances and therefore with multiple  connection strings as each has its own database. Similarly other developers will have their own databases. One way to approach this would be to store a connection string per instance - but that can get messy fast - so what you can do is to push bits of a config file out to an external file, so in my web.config you will see the following:

 

<connectionStrings configSource="connections.config" />

 

And then the connections.config looks something like:

 

<connectionStrings>

    <add name="MyConnectionString"

connectionString="Data Source=ServerInstance;Initial Catalog=DatabaseName;Integrated Security=True"

         providerName="System.Data.SqlClient"/>

</connectionStrings>

 

The advantage here - for web applications at least - is that "debug" aside they can be version controlled safely as they are the same everywhere. Then for each deployed instance you have the instance/site specific file which is NOT version controlled and NOT part of the deployed content. Its not perfect... But it works and it makes application updates easy.

 

So where was I? Oh yes... I can pull the connection string using the standard configuration methods easily enough - but how can I persuade the DataContext to use it? After all when you set up the model you have no mechanism to tell it the context string so its going to make assumptions based on your model and for my solutions those assumptions are going to be wrong.

 

Well the answer is that the generated DataContext class is partial and that one of the hooks put in is an OnCreated method - and that we can use to set our connection string.

 

So we add the following to the DataContext class :

 

    public static string ConnectionString { get; set; }

 

    partial void OnCreated()

    {

        if (!string.IsNullOrEmpty(ConnectionString))

    {

    this.Connection.ConnectionString = ConnectionString;

    }

    }

 

Note that 1) I'm (hopefully) ensuring that we get the default behaviour if we don't explicitly set the connection string and 2) the connection will be the same for all instances  even if you use the constructor that explicitly sets the connection string... However given that you're setting the connection string "globally" I would expect that in most cases you won't need to do that any more.

 

Then, before you do model.RegisterContext in global.asax.cs, you just (!) need to set the connection string:

 

    string connStr = System.Configuration.ConfigurationManager.ConnectionStrings["MyConnectionString"].ConnectionString;

    MyDataClassesDataContext.ConnectionString = connStr;

 

And that should pretty much be that. When an instance of the DataContext is initiaised the OnCreated method overrides the connection string with the value that was set at startup and all should, hopefully, be well!

 

A perhaps slightly better other option might be to subclass the DataContext class and override the default constructor to get similar behaviour - but you still want to use a property as above to avoid having to wire and understanding of config into your DataContext class.

At what cost

Nick Sieger writes about Microsft, Competition and the Right Fork and says that they should make their tools free - in particular referencing "the goodies being dangled in front of developers". A good argument too - it would be even better if it weren't the case these things are free - with the one caveat that you need to pay for the operating system they run on.

IIS? In the box with XP and Windows server - and there are alternatives to IIS. SQL Server? The big hefty ones ain't free but currently MSDE is (mostly) and soon the far less restrictive SQL Server 2005 Express will be. Devtools? Now this is where is gets interesting - the framework is free, the libraries (all the good stuff referenced) are free, the compilers are free the tools that go with the compilers are free. What isn't free is the Visual Studio IDE but equally it isn't necessary to the production of software - and there are open source IDEs for .NET

So two different questions then, should Visual Studio be free? It would be nice but I can't make a good argument (even allowing that there's all this very nice stuff in Team System that's out of our budget). Should Microsofts operating systems be free? Well no, that's the business model isn't it - make the platforms attractive by giving (oh yes they do) the developers all the tools they need - if not quite all the tools they want.

Oh well, that was possibly foolish but here we go (reaches for save button)

When is a Virtual Directory not a virtual directory

It has been suggest that one of the smart things to do with a blog is to record those things that you discover that you will forget later. This is kind of one of those.

I wanted to put a new application up for test on our server, so I created a folder, fired up IIS admin, created the new site, set the host header and copied the app into the new folder. Of course it didn't work.

I got this:

It is an error to use a section registered as allowDefinition='MachineToApplication' beyond application level. This error can be caused by a virtual directory not being configured as an application in IIS.

Which, a short google later, I determine means that IIS doesn't think that its an application folder.

The solution is trivial - do things in the right order:

• first you copy the folder containing the application to the appropriate location on your server
• then you add the the virtual folder - pointing to the folder already in place - to IIS6 and lo and behold it "just works".

Obvious with hindsight...

How stupid can you get

One of the guys who sort of works for me has spent all afternoon being massively stressed by his inability to get an HTML page to render properly... and of course I've been stressed by his being stressed (long story).

Actually its worse than that. The HTML is generated by an XML->XSL transform (all in .NET). And comes out nicely formatted with the tags on separate lines - if you remove all this spare whitespace (not just the cr/lfs)it renders as designed, leave it in an you get a mess.

But whitespace isn't supposed to count in markup... it certainly isn't supposed to be this significant and yet this has cost us hour

Now all we have to do is persuade the rendering sequence not to do the nice formatting. I have my other minion looking at that.

This has cost us hours, ruined my ability to concentrate all afternoon, is going to chew up yet more time 'til we work out how to anti-formatting and its something that probably shouldn't even be an issue in the first place!

Mote a helpful rant all round - but that's what we did today so that's what I've written.

Making what works now work (better)

Robert Scoble asks how to deal with the problem of "how Microsoft isn't solving current problems and is overhyping tomorrow's technology".

Well there are some fairly obvious ones - firstly there should be a great big huge wall in MSDN between material for current/released products and that for forthcoming projects. If I run search today for help and support it should by default only return results for products I'm can currently develop for/with.

Actually this works both ways, one should be able to filter out historical stuff too - but it needs some kind of timeline based window and to be very easy to pick.

Secondly, fix the current tools - have people working on them aggressively for as long as possible (which is way longer than perhaps those in microsoft will feel is necessary). In terms of the .NET framework I'm not sure whether I want it to be incrementally upgradeable as this leads us to a variation on .DLL hell... but then again this problem has to be fixed for Longhorn!

Thirdly - give Joel his linker... this will help in all kinds of ways in buying mindshare from wavering developers - and that, ultimately, is how you get .Net apps onto the desktop.

Finally, and this is a generic issue not too a specific one, Microsoft needs to understand that no matter how good its latest and greatest techology the days of the "must have" upgrade are gone - for all its faults Windows 98 does a more than adequate job for a great many people now and when longhorn arrives WinXP will still be doing and will continue to do a far more than adequate job for a long long time thereafter. So in dealing with its developer community MS needs to remember that for every one who gets the opportunity to run with cutting edge platorms there are two or three or four or more of us for whom the entry level target is Win98 (or possibly 2K).

Blogged Gossip

A lot of weblogging is like gossip (mind you a lot of journalism is about spin so perhaps one can't complain) - take a look at this headline from Robert Scoble: Desktop PC to go way of Dodo? which implies that the desktop will be completely replaced by Tablet type PCs (of which he is, with considerable justification, a fan). Except that that is not at all what the article in AustralianIT: Tablets will take over says. Even that headline has a chunk of spin as what the content suggests is that the 45 per cent of corporate users will have a traditional desktop as their main information device, 40 per cent will mainly use a notebook or Tablet PC with the remaining 15% off playing with other devices - so in fact trad desktops will still be dominant (at least in corporates).

So from research saying that there will still be more desktops than tablets (or notebooks!!!) we move to a headline saying that Tablets (where did the notebooks go) taking over from desktops and from there to a headline predicting the death of the desktop...

Almost textbook example of how gossip distorts stuff (:

Mind you, this isn't going to stop me reading Robert's stuff as its fun and besides his opinions are generally good!