Thoughts from the Wet Coast

DotNetNuke Community Edition in the New Web Application Gallery

charles.nurse.nospam@nospam.dotnetnuke.com (cnurse) — Wed, 18 Mar 2009 10:38:51 -0700

Today (March 18th, 2009) during the keynote at MIX 09, Scott Guthrie announced the release of version 2 of the Web Platform Installer (WPI) and the release of the new Web Application Gallery.

Bill Staples, the Program Manager responsible for the Web Application Gallery described it as an “App Store for the Web”. I am pleased to say that DotNetNuke Community Edition is part of this initiative and that Bill Staples used DotNetNuke as his demonstration install during the keynote.

If you want to download and try DotNetNuke Community Edition you can install it from the Web Application Gallery by clicking the image below.

The Installation Experience

When you click on the install link, you will get a popup (in Firefox 3) that confirms which program you want to use to run the installer. In my case I already have the Web Platform Installer on my machine.

The Installer will launch and you will get the following screen.

Clicking on Install will download the application (in the case of DotNetNuke it will download from Codeplex) and display the following screen, where you can provide an “Application Name” – the default is dotnetnuke.

The second page allows the user to configure the database.

Clicking continue will set up IIS and SQL Server. You will then see the final screen, which lets you know that the install was successful.

Finally clicking the link will automatically launch the DotNetNuke Install Wizard to complete the installation of your DotNetNuke Application.

Scott Hanselman has blogged about the new installer, using Das Blog as the example. He describes some of the technical details behind the installer. In a future article I will describe the set up of the DotNetNuke package, which I created for this initiative.

The New Extension Installer Manifest – Part 6, The Script Component

charles.nurse.nospam@nospam.dotnetnuke.com (cnurse) — Fri, 27 Feb 2009 10:18:56 -0700

In DotNetNuke v 4.6 a new installer system was introduced to handle the new Authentication Systems. In DotNetNuke 5.0 we have extended the use of the Installer to all extensions, including Modules, Language Packs and Skins.

In previous blogs in this series I introduced the new Extension Installer Manifest, and the 3 components that most developers would be fairly familiar with – Module, Assembly, File, as they are similar to the legacy module manifest, and I began to detail the individual component manifests by describing the Cleanup Component and the Assembly Component and File Component.

In this article I will dive deeper into the Script Component (see Listing 1).

Listing 1 - The Script Component manifest fragment from the BroadcastPollingCachingProvider

   1:  <component type="Script">

   2:    <scripts>

   3:      <basePath>Providers/CachingProviders/BroadcastPollingCachingProvider</basePath>

   4:      <script type="Install">

   5:        <path>Install</path>

   6:        <name>Install.SqlDataProvider</name>

   7:        <version>05.00.00</version>

   8:      </script>

   9:      <script type="UnInstall">

  10:        <path>UnInstall</path>

  11:        <name>UnInstall.SqlDataProvider</name>

  12:        <version>05.00.00</version>

  13:      </script>

  14:    </scripts>

  15:  </component>

The Script component is another Installer that inherits from the base File Component. The <basePath> element identifies the root location for the Script. It uses the <scripts> and <script> elements in place of the base class <files> and <file> element.

Note that there a few enhancements (compared with the legacy Module Installer) in how scripts are handled.

Each script has a “type” attribute, which identifies whether the Script should be used in Install/Upgrade mode or is used 'in “UnInstall” mode
Each script has a required version element which identifies which version the script corresponds to. This means that you no longer have to use the convention of naming the script with the version “xx.xx.xx.SqlDataProvider”. ou can of course still use the legacy naming convention, but you are not required to.
The installer does support the “Install.SqlDataProvider” special script which is run first when installing an Extension.

Kudos to Dell

charles.nurse.nospam@nospam.dotnetnuke.com (cnurse) — Thu, 26 Feb 2009 10:02:27 -0700

Last week my Dell XPS M1330 laptop died.

After searching the internet I discovered that the problem was a faulty NVidea graphics card, which was quite a well-known problem.

On Thursday, I called Dell’s Canadian XPS Customer Support line and the representative immediately recognised the problem and arranged to have a box shipped to me so I could pack it up and send it to their Canadian Service Centre in Newmarket, Ontario.

The box arrived Friday morning, and I packed the laptop into it and dropped it off at the local Purolator office in Langley.

Yesterday, I was surprised when a Purolator delivery man knocked on my door with my laptop, and its running great now!!

So Kudos to Dell, who expedited this repair taking 4 business days to ship a box 3 times across the country as well as repairing my computer.

The New Extension Installer Manifest – Part 5, The File Component

charles.nurse.nospam@nospam.dotnetnuke.com (cnurse) — Wed, 25 Feb 2009 11:15:50 -0700

In this article I will dive deeper into the File Component (see Listing 1).

Listing 1 - The File Component manifest fragment from the FileBasedCachingProvider

   1:  <component type="File">

   2:    <files>

   3:      <basePath>Providers\CachingProviders\FileBasedCachingProvider</basePath>

   4:      <file>

   5:        <name>license.txt</name>

   6:      </file>

   7:      <file>

   8:        <name>releaseNotes.txt</name>

   9:      </file>

  10:    </files>

  11:  </component>

Most of the components which handle files inherit from the base File Component. The <basePath> element is used to identify a base (or root) path for all the files identified. Each <file> element has a <name> and <path> which is combined with this base path to identify the file completely. The <file> element also has a <sourceFileName> element. This is used to identify the file’s location within the zip file, if different from the file location in the destination.

The component installers that inherit from the File Installer essentially have the same general structure – they use different names for the <file> and <files> nodes, but in most respects are the same. They use the base class’s logic to manage the file copying etc. implementing only the custom behaviour they need.

In addition to <name> and <path>, there are two other elements that are defined in File component but have no effect in the base class.

<action> is used by the Assembly Installer to determine whether the assembly should be added or removed
<version> is used by both the Assembly Installer and the Script Installer

Backup and Restore

As the new Installer supports a limited rollback model, the File Installer will backup existing files before copying a new copy during Upgrade. If there is a failure in some other component, the backups will be copied back to their original location, so the old version of the file is still present.

If the installation/upgrade is successful, during the commit phase the backup copy is deleted and the new file is used.

The New Extension Installer Manifest – Part 4, The Assembly Component

charles.nurse.nospam@nospam.dotnetnuke.com (cnurse) — Wed, 11 Feb 2009 09:14:37 -0700

In this article I will dive deeper into the Assembly Component (see Listing 1).

Listing 1 - The Assembly Component manifest fragment from the FileBasedCachingProvider

   1:  <component type="Assembly">

   2:    <assemblies>

   3:      <assembly>

   4:        <path>bin\Providers</path>

   5:        <name>DotNetNuke.Caching.FileBasedCachingProvider.dll</name>

   6:        <version>05.00.01</version>

   7:      </assembly>

   8:    </assemblies>

   9:  </component>

Most of the components which handle files inherit from the base File Component, and so the Assembly Component has a <path> element and a <file> element. The element name for the collection is <assemblies> rather than <files> and the element name for a single assembly is <assembly> rather than <file>, but in code the actual copying of the file is handled by the base FileInstaller.

While the <version> element is defined for the File Component it is not really used for standard files. However the version element is important for assemblies.

Registering Assemblies

One of the problems with earlier versions of DotNetNuke is in handling assembly versioning. Each module, when installed just extracts its assemblies and copies them to the /bin folder, regardless of whether an existing version of the assembly is already in use.

This makes life difficult, if module developers use 3rd party libraries of any kind – either their own shared code or controls from commercial vendors. For example, if Module A uses Assembly A version 1 (Assembly A1) and Module B uses Assembly A version 2 (Assembly A2), then if Module A is installed after Module B it could break Module B as the older version (A1) is installed over the version Module B expects (A2).

Conversely, on uninstall, Module A will remove the associated assembly, which will again break Module B.

This situation is solved in the new Installer, by using the <version> element and by using assembly referencing.

Listing 2 – The InstallFile method of the AssemblyInstaller

   1:  Protected Overrides Function InstallFile(ByVal file As InstallFile) As Boolean

   2:      Dim bSuccess As Boolean = True

3:

   4:      If file.Action = "UnRegister" Then

   5:          DeleteFile(file)

   6:      Else

   7:          'Attempt to register assembly this will return False if the assembly exists

   8:          'and true if it does not or is older

   9:          Dim returnCode As Integer = DataProvider.Instance.RegisterAssembly(Me.Package.PackageID,

  10:                                                           file.Name, file.Version.ToString(3))

  11:          Select Case returnCode

  12:              Case 0

  13:                  'Assembly Does Not Exist

  14:                  Log.AddInfo(Util.ASSEMBLY_Added + " - " + file.FullName)

  15:              Case 1

  16:                  'Older version of Assembly Exists

  17:                  Log.AddInfo(Util.ASSEMBLY_Updated + " - " + file.FullName)

  18:              Case 2, 3

  19:                  'Assembly already Registered

  20:                  Log.AddInfo(Util.ASSEMBLY_Registered + " - " + file.FullName)

  21:          End Select

22:

  23:          'If assembly not registered, is newer (or is the same version and we are in repair mode)

  24:          If returnCode < 2 OrElse (returnCode = 2 AndAlso file.InstallerInfo.RepairInstall) Then

  25:              'Call base class version to copy file to \bin

  26:              bSuccess = MyBase.InstallFile(file)

  27:          End If

  28:      End If

  29:      Return bSuccess

  30:  End Function

The AssemblyInstaller overrides the InstallFile method of the base FileComponent (it also overrides the DeleteFile method – see later), and before copying the file into the /bin folder, it registers the assembly in the database (see Listing 2). The RegisterAssembly method checks if the assembly is already registered by another extension and returns one of 4 return Codes.

0 – Assembly does not exist
1 – An older version of the assembly exists
2 – The same version of the assembly exists
3 – A newer version of the assembly exists

If the return code is 0 or 1 then the file is copied (as the assembly does not exist or is older than the current version) by calling the base FileInstaller class’s InstallFile method. If the return code is 2 the assembly is only copied if we are repairing the install, and if the return code is 3 the assembly is not copied as it could potentially break another extension that is already installed.

The RegisterAssemby method adds an entry into the Assemblies table, recording the PackageID of the Extension which registered the assembly.

Figure 1 – The Assemblies Table

UnRegistering Assemblies

On uninstall the reverse process happens. As mentioned above, the AssemblyInstaller also overrides the base FileInstaller’s DeleteFile method.

Listing 3 – The DeleteFile method of the AssemblyInstaller

   1:  Protected Overrides Sub DeleteFile(ByVal file As InstallFile)

   2:      'Attempt to unregister assembly this will return False if the

   3:      'assembly is used by another package and cannot be delete and

   4:      'true if it is not being used and can be deleted

   5:      If DataProvider.Instance.UnRegisterAssembly(Me.Package.PackageID, file.Name) Then

   6:          Log.AddInfo(Util.ASSEMBLY_UnRegistered + " - " + file.FullName)

   7:          'Call base class version to deleteFile file from \bin

   8:          MyBase.DeleteFile(file)

   9:      Else

  10:          Log.AddInfo(Util.ASSEMBLY_InUse + " - " + file.FullName)

  11:      End If

  12:  End Sub

In the DeleteFile method (see Listing 3), the UnRegisterAssembly method is called. This method removes the record from the assemblies table and returns a boolean value:

true – the registration was the only registration for this assembly and the assembly can be safely deleted
false – there are other extensions which still require the assembly and the assembly should not be deleted

So the result of this is that, by using assembly counting, we can improve the situation where shared assemblies are being used. The only remaining case which could break Extensions is if a shared assembly does not retain binary compatibility in newer versions.

Nurse Family History – Samuel Nurse of Hanham (Born 1809)

charles.nurse.nospam@nospam.dotnetnuke.com (cnurse) — Tue, 10 Feb 2009 07:20:42 -0700

In the previous article in this blog series I described the life of Robert Nurse (my great-great-grandfather). Robert was the youngest child and his older brother Samuel, was also my great-great-grandfather, as Robert’s son Robert Francis Nurse married Samuel’s daughter Sarah Elizabeth Nurse.

Samuel married Dinah Willis on Christmas Day 1848.

Figure 1 – Samuel Nurse (c 1860)		Figure 2 – Dinah Nurse

Dinah was the eldest of six children (5 daughters and one son) of Robert Willis and Dinah Leonard.[1],[2]

Willis [3] is quite a popular name in Hanham, most of the Willises being labourers or quarrymen. [5] Robert however, was quite well off, being classified, as a Yeoman in both the 1851 and 1861 [5], [6], [7] censuses and his will,[8] where he leaves most of his estate to his daughter Dinah Willis, Samuel Nurse’s wife.

Figure 3 – The Family of Samuel and Dinah Nurse

While both Samuel and his brother Robert had inherited the family malting business, it was Samuel who operated the business. Samuel and Dinah had three children a boy Robert Willis and two daughters Sarah Elizabeth and Frances Willis.

Bibliography and Notes

[1] Personal Notes of William Richmond Nurse, 1882-1937.

[2] Parish Register of St. Nicholas Church, City of Bristol, 1754-1812. Microfiched by the Bristol Record Office, Bristol.

[3] Due to the number of Willis families in the Hanham/Bitton area it has proven quite difficult to trace the Willis line back very far. Robert Willis and Dinah Leonard were married 24 Jun 1810 at St. Nicholas Church in the city of Bristol.

Robert, born 28 Feb 1777, was the one of eleven children (6 boys and 5 girls) of Samuel Willis and Sarah Rawbone, who were married on 1 May 1774 at St. Mary, Bitton. [4]

Samuel Willis was the son of Thomas Willis and Elizabeth Hicks and Sarah Rawbone was the daughter of John and Jane Rawbone (and the sister of Betty Rawbone who married John Couch and was the mother of Salley Couch).

[4] Parish Register for the Parish of St. Mary, Bitton, including the chapelries of Hanham and Oldland, 1571 - 1934. Microfiched by the Bristol Record Office, Bristol.

[5] 1851 National Census. Microfiche copy held at the Bristol Reference Library.

[6] 1841 National Census. Microfiche copy held at the Bristol Reference Library.

[7] 1861 National Census. Microfiche copy held at the Bristol Reference Library.

[8] The Will of Robert Willis, dated 19 Jun 1863; Bristol Wills, vol. 26, Bristol Record Office.

Back Again

charles.nurse.nospam@nospam.dotnetnuke.com (cnurse) — Mon, 09 Feb 2009 09:12:15 -0700

I was checking this blog yesterday, and I realized that I haven’t posted a single blog in 2009.

Well, that’s not good.

The last few weeks I have been busy fixing bugs from the recently released DotNetNuke 5.0, and preparing for some of the enhancements we hope to introduce in the next major release. We have three new developers and we will need to introduce some more formal practices. This will be good for me personally and for the project.

My initial plan, when I started this blog was to blog daily. I hope to get back into a routine of frequently posting here, but with a more achievable goal (3-4 times weekly).

So please check back here frequently, or subscribe through the subscribe link, and hopefully you will find my musings of interest.

Happy New Year - 2009

charles.nurse.nospam@nospam.dotnetnuke.com (cnurse) — Wed, 31 Dec 2008 19:04:58 -0700

It is dinner time on New Years Eve, here on the Wet Coast. Most of the world is already celebrating the New Year, but as in many things we are a bit late here in North America.

Looking Back

2008 has been a challenging year for many people as the financial crisis struck. Many retired people or people approaching retirement took a big hit in their income as their savings were decimated. Thankfully, I still have a few years to go, for my retirement savings to recover.

For me 2008 was quite a good year. In January, my Microsoft MVP award was renewed for a 2nd year, and a month later I was nominated to the prestigious ASPInsiders group. Both of these “groups” held summits in Seattle and I met a lot of other ASP.NET developers who I respect.

In June, my wife Eileen and I celebrated our 25th Wedding Anniversary by travelling to Italy for 17 days. I have blogged about this in some depth.

The fall was full of speaking engagements. It began with Open Force Europe in the Netherlands in early October, followed by a trip to England to visit family. In November I spoke at the .NET BC User Group meeting at BCIT and at Open Force North America/DevConnections in Las Vegas.

Finally, in late November, DotNetNuke Corporation received Series A Venture Financing which hopefully will allow us to grow, both the company and the community.

Looking Forward – 2009

2009 starts tomorrow. For me, January 1st sees me start a new job as I become a salaried employee of DotNetNuke Corporation (I had previously been working on a personal services contract). We have already hired a few new developers that will also be starting early in the new year, and in February or March we should be able to open an office, somewhere in the Fraser Valley, just east of Vancouver.

It will feel strange to go back to commuting to work again – I have worked from home since 1995 – but I am looking forward to working closely with a team of excellent programmers as we grow DotNetNuke.

We don’t have any travel plans (yet) this year, although I expect I will be at one or both Open Force conferences. I would really like to travel to Australia (hint, hint).

To conclude, I wish everybody a Happy New Year. If 2008 was bad for you, I hope 2009 will be better. If 2008 was good for you, I hope 2009 will continue that trend.

Merry Christmas from the Wet Coast

charles.nurse.nospam@nospam.dotnetnuke.com (cnurse) — Wed, 24 Dec 2008 11:14:58 -0700

It is Christmas Eve on the Wet Coast, and I am sitting in my office looking out on a Winter Wonderland - and to prove it below is a picture taken from the front porch of my house, just a few minutes ago.

As you can surmise we are not going anywhere soon. Thankfully we finished all our holiday preparations yesterday, so today and tomorrow we can focus on enjoying the holiday spirit (my favourite is GlenMorangie Single Malt Scotch Whiskey).

For those of you who are Christian like us, we wish you a Merry Christmas, and for everyone we wish you the best for the Holiday Season.

Oxite – An update

charles.nurse.nospam@nospam.dotnetnuke.com (cnurse) — Fri, 19 Dec 2008 14:11:41 -0700

In my last blog I criticized the team that released Oxite recently. My concern was that they were promoting Oxite as a “real-world sample using ASP.NET MVC”, but as many others have said it is a poor example.

Since my earlier blog there have been a few more blogs on the topic.

Casey Charlton - Oxite - An Example of How Not To Write MVC Applications

Rob Conery - Oxite Refactor, Take 1

Scott Hansleman - ASP.NET MVC Samples, Oxite, and Community

Oren Eini - Oxite: Open eXchangable Informative Troubled Engine

While Rob and Scott take a more conciliatory take – they are now of course Microsoft employees - the comment that for me “hits the nail on the head” is from Glenn Block, who is also an MS employee.

He has a refreshingly honest comment.

There is no excuse for this. There are tons of folks both internal to Microsoft or external that can help people who want to learn good practices for developing software. The fact that the MVC team was not even consulted by the Oxite guys is literally stunning.

It is pretty clear now that releasing this was a marketing blunder. As I mentioned in my earlier blog, I hope the development team can provide some better examples of how they believe this new “tool” can and should be used.