Codebureau - Matt Simner

1. install iis60rkt.exe from http://www.microsoft.com/downloads/details.aspx?FamilyID=56fc92ee-a71a-4c73-b628-ade629c89499&DisplayLang=en on your local machine. It's intended for IIS 6.0 but it works in IIS 5.1.
2. Select custom install if you only want to use SelfSSL. Otherwise, install all.There's a lot of other useful stuff there.
   
3. Select Programs --> IIS Resources --> SelfSSL --> SelfSSL command prompt
4. In the command prompt, you'll see a list of all possible command parameters..
1. Type 'selfssl.exe /V:60'     This indicates the certificate is valid for 60 days
2. Type Y to answer the question "Do you want to replace the SSL settings for site 1 (default website) ?
3. Type 'iisreset' to restart IIS.

1. It's open source, well tested and an open design.  This means you write less code and you can rely on functionality just 'working' in different browsers - or gracefully failing if something's not right.
   
2. It's really light (especially when 'packed' - 31kb)
   
3. It's got a strong community with lots of really cool plugins (just take a look before you start developing that 'widget' in flash)
   
4. It plays well with other libraries and code.  you just use it for what you need and plugins sit with other plugins.
   
5. It's obviously gaining momentum, as Scott Hansleman announced Microsoft are going to ship it with ASP.NET MVC and Visual Studio (that's a pretty amazing move from Microsoft).
   

CSS is great, until you're faced with a deadline and a broken IE6 layout.  You get the cowboy gear out and - 'Welcome to Hacksville!'  

There's been a growing trend of CSS frameworks recently as people are obviously crying out for 'something' to save them from the madness. 

I'm trying out the 960 grid system at the moment, as it's not too prescriptive and gives me the flexibility I need.

There's a great review of the best frameworks on adactio.  I'm sure there's one to suit almost every need.  Remember they're just the starting point if you're doing serious design, but they'll take most of the pain away, because the heavy 'hack' lifting is done for you...   

Also - more on Wikipedia (Update: 17/09) - BlueTrip's the way to go - best of several worlds - nice.

Had some fun this morning as we're trying to get a simple framework set up for a web app, that others can understand, using out-of-the-box functionality if possible.  I tried to avoid the normal tendency to put the 'architecture hat' on and overcook it.  If you can't be bothered to read all of this then just scroll to the bottom for the 'take home' on binding against typed datasets with null values.

We started off the prototype with a typed Dataset (including a couple of DB tables, and key relationships between each), a table adapter for each table, and a DetailsView at the front end, bound to an objectdatasource, which in turn talks to a business object that calls the TableAdapter.  That's a lot for one sentence so from top to bottom...

DetailsView --> ObjectDataSource --> BusinessService --> TableAdapter --> Database

This all sounds pretty straightforward, and it is - unless (as in this case) you decide to have your business object pass back a single (strongly typed) DataRow for your front end to bind against.  This seemed reasonable at the time because I only ever want to show one row here.

You'll basically get a StrongTypingException for every null field you try and bind, because by default a null field value will raise an exception when accessed through its generated property. 

We got distracted for a while exploring this as the natural tendency is to think 'ah - I'll make sure it doesn't raise the exception' - treating the symptom rather than the cause.

It turns out that any non-string field in a typed dataset table can't have a default of null (or anything other than 'raise exception').  If you stuff in a _null value directly in the XSD your fields will disappear from the public properties (rather curiously) when you compile - so that's not an 'enterprise' option.

I tried changing the return type in my business method to a generic DataRow to try and force the data binding to NOT use the strongly typed properties (getting warmer but still no dice.  I knew I was missing something really simple...

I then stumbled across a post (bottom of the page) that illustrated databinding will use different methods to bind based on what interfaces it finds.  The binding mechanism basically has no choice but to use the strongly typed public properties on a strongly typed or generic DataRow, as there's no way for it to successfully enumerate the values.  If you bind against almost anything else you'll most likely have no issues (it appears the databinding doesn't rely solely on ITypedList).  We're now binding against a typed DataTable (rather than generic DataView) and all's fine.  If you want (rather) more info on ITypedList then look here.

So...

Don't databind against a typed (or untyped) DataRow!

Useful reference material if you're trying to get a usability focus in your agile projects

http://www.uie.com/articles/best_practices

http://www.uie.com/articles/best_practices_part2

We start with Windows XP SP2 (doesn't really need to be a 'server').  My requirement is to rely on the .NET framework and open source tools - i.e. not requiring a Visual Studio Licence.  We're using .NET 2.0 so everything will be in reference to that.

I assume here that you'll be familiar with the actual software below and just want to get a Build Server up and running without having to install Visual Studio.  If you're not familiar with Continuous Integration then start by looking at Martin Fowler's Continuous Integration article and then the info on CruiseControl.NET, as that's the tool that pulls everything together. 

There's help on each of the sites below for installing and using each of the tools, so I won't go into detail about each one.  The order of the list isn't critical, but you'll probably have some issues unless all are done.

1. Install IIS from Add/Remove Windows Components (used for CruiseControl.NET) if not already present
2. Open up a command prompt and run C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe -i (to install ASP.NET in IIS)
3. Install CruiseControl.NET (1.4) from http://confluence.public.thoughtworks.org/display/CCNET/Download.  NOTE:  If you're using a remote SubVersion repository (as in my case) then you'll need to run the CruiseControl.NET Service as a domain user that has access to the network location of the repository  rather than LocalSystem.  This is because CruiseControl will be using the SVN client to poll for changes. 
4. Install Microsoft .NET Framework 2.0 SP1 from http://www.microsoft.com/downloads/details.aspx?familyid=029196ed-04eb-471e-8a99-3c61d19a4c5a&displaylang=en
5. Install latest SubVersion (1.5) from http://www.collab.net/downloads/subversion/
6. Install appropriate NUnit from http://nunit.org/index.php?p=download (targeting .NET framework 2.0 - I have 2.4.6)
7. Install latest FxCop from http://www.microsoft.com/downloads/details.aspx?familyid=3389F7E4-0E55-4A4D-BC74-4AEABB17997B
8. Install .NET Framework 2.0 SDK from http://www.microsoft.com/downloads/details.aspx?familyid=fe6f2099-b7b4-4f47-a244-c96d69c35dec&displaylang=en (you'll need this to get around a NAnt bug whereby it can't resolve an internal property to load the .NET framework)
9. Download latest NAnt from http://nant.sourceforge.net/
10. Download latest NAntContrib from http://nantcontrib.sourceforge.net/ (You'll need this to run MSBuild)
11. To save getting errors when building Web Projects (and other types) the easiest thing is to copy c:\program files\msbuild from your dev machine to the build server (otherwise you'll have to alter the path of where the targets are in each project).

Once you've got all of these set up then you'll be able to add some builds to your ccnet.config file ( most likely c:\program files\CruiseControl.NET\server\ccnet.config)

Test CruiseControl's happy by going to http://localhost/ccnet It should come up OK but basically show 'no projects'.

I'm not going to go into detail about setting up the builds here but may cover that in a follow up article, as it requires some more setup with SVN and a 'standard' project structure (to get benefit from reuse of build scripts).  If you're still with me then I'll share one last thing which might help... 

Some people choose to have NAnt in a standard place and just reference it from the PATH, but I now use the power of svn:externals to drag in NAnt, NUnit and other common external dependencies like MS Enterprise Library from a shared SVN location to each project.  This means you just get latest of a project and it has 'everything' needed to build - no installations or assumptions about locations of tools.

I've been using WikidPad for a while and have been struggling with it's usability so I had another google around the printing capability of Guidance Explorer (my eventual medium is likely to be some other wiki-like product, so this is likely to just be my 'input medium').  I found the (rather obvious) Guidance Explorer Overview on Codeplex that explains that printing is indirectly supported through the export formats. I tried it and - whoa!! I take it all back. 

The export to Word format at different levels and different views is just great.  It gives you an index at the top with links to the actual content.  The formatting's nice too.  The HTML format's just the same as the Word doc visually, but spits out the content to separate files which is a bit nicer for deployment.

I still can't believe how little-known Guidance Explorer is, but much of the Patterns and Practices work is documented, along with many other resources.  I'll certainly be saying Bye bye to WikidPad.

At last I've found a good reference on which browsers support which types of icons/png's etc for the Favicon.  I guess the news is that you need more than one approach if you're wanting to serve a favicon to the most potential users.