Just last week I did a presentation to the South East Queensland DotNetNuke User Group, on the topic of ‘What’s new in DotNetNuke 6.2’.

The slides from this presentation are shown below:

About the User Group Meeting

This was a very fun event – generously sponsored by Power DNN Australia and held in South Brisbane.  Unfortunately we were in the grip of one of the worst rain events in recent history – while I was presenting, over 370mm of rain fell on my house – that’s 14 inches of rain - in the space of a few hours, which caused widespread flooding.  It wasn’t as bad in Brisbane where I was giving the presentation, but the weather was foul enough to keep a few people away.

The next SEQDUG meeting is already in planning – make sure you join the Linked In Group to be a part of the DotNetNuke scene in my part of the world!

About the Presentation

The two main areas that my presentation covered were the changes in DotNetNuke 6.2 that people are most interested in – these being the Social Networking features and the Services Layer that powers them (and will be available to all developers to utilise).

Earlier this week, Scott Schlesier posted a timely blog entry entitled DotNetNuke Services Framework - a little context.  This expands further on the brief introduction to the services layer that is in the linked presentation above.  I highly suggest any DotNetNuke developer reads it to get more information on what will be one of the biggest revolutions in DotNetNuke history.

I’ll be having a lot more to say about 6.2 in the coming months, so stay tuned for updates!

Search engine optimization (SEO) has been on the top of most minds in the website design and development for many years now, so I won’t bore you with details about what it is and why it’s important.  At this point, that should be obvious.  However, maintaining your SEO is a never-ending challenge.  This is never more apparent than when you switch platforms on the web, no matter how big or small that platform may be.  I have recently run into such a challenge.

In case you haven’t noticed, I have switched blog modules.  This post not only introduces my newest open source module, but it also clearly outlines the use case for why I built it, and why it might be of use to you as well.  While my use case involves blog modules, this could very well relate to other types of modules like announcements, forums, and any other module that creates dynamic pages based upon content you are creating.

As of Sunday, March 25, I am now using Live Blog by Mandeeps instead of the “core” blog module.  Don’t get me wrong, the core blog module is great.  I’ve used it for many years now.  It definitely fits the needs of most bloggers and blogging websites, but I really needed more, and Live Blog offers it to me right now.  Also, the difficulties I outline are not to pick on Live Blog or Mandeeps.  Both are truly great!  What I speak about here would most likely be experienced with any software, platform, or module when making a switch that affects URLs.

URLs Changing

Anyhow, this switch of modules was really the motivating factor behind building the Simple Redirect Module for DotNetNuke.  When migrating from one module to the next, the URL structure has changed.  The change was minimal on the surface, but it certainly has the potential to have a pretty significant impact on SEO one way or the other.  It really depends on how the URLs are handled now. 

This is an example of a core blog module URL for a blog post, assuming the blog module is on a page named “Blog”: 

• http://domain.com/Blog/EntryId/123/This-is-Your-Blog-Title-in-the-URL.aspx

The Live Blog URL is very similar, and with very few differences in creating the page name – and sometimes no differences at all:

• http://domain.com/Blog/PostId/123/This-is-Your-Blog-Title-in-the-URL.aspx

On a site like mine, you can also pretend the page extension isn’t there as well, since I am using URL Master.

Luckily, Live Blog does an incredibly great job of importing blog posts and comments from many places, including the “core” blog module.  That feature is a life-saver!

Once again, on the surface such a transition appears to be simple.  After all, the blog posts are imported, so the URLs should match up pretty nicely.  However, on an installation of DNN where there have been multiple blogs on multiple sites and multiple test posts from applications like Windows Live Writer, there are some subtle differences.

First, some posts would not have the same “page name.”  Let’s take a title like “Simple Redirect Module 01.01.01 Released.”  The resulting page names would be slightly different for each blog module, shown below.  Also shown is an example of the blog entry ID’s being slightly off since the new entries in the database no longer have the history of having had previous blog entries that are now deleted.  Both issues are bolded to make it easier to see.

• Core Blog:  http://domain.com/Blog/EntryId/123/Simple-Redirect-Module-for-DotNetNuke-01-01-01-Released.aspx
• Live Blog:  http://domain.com/Blog/PostId/118/Simple-Redirect-Module-for-DotNetNuke-010101-Released.aspx

And worse… Sometimes (and this will likely be fixed by the time you use the module), you might have a URL that is truncated like seen here:

• http://domain.com/Blog/PostId/118/Simple-Redirect-Module-for-DotNetNuke-010101-Rele.aspx

As you can see, it is not very straightforward to perform any specific rewrite rules in this scenario.  At least, not easily and not without having some more information to more easily map blog entries between the two modules.

The Solution

I tried several things before finally resorting to writing a module.  I tried to find a rewrite method in URL Master, but nothing existed without writing a provider for URL Master.  I also tried using rewrite rules in SiteUrls.config, but not being able to predict the URL pattern changes consistently meant that there would need to be a direct 1-to-1 relationship in the configuration – and such a thing would adversely impact performance on every page load on the entire site and installation of DotNetNuke.

Finally, I warmed up to the idea of building a module for this.  Enter the Simple Redirect Module for DNN. 

This module allows you to simply enter a URL that no longer exists, and map that to a URL that does exist.  Easy stuff!  In the background, the module is not only pointing visitors to the right place, but it is also performing something known as a HTTP 301 Redirect, which also notifies search engines that the new page is the right one.  This instruction results in the search engine wiping out the original URL and replacing it with the new one.

This blog actually comes to you after 3 releases of the module.  While the first version worked fine, I found some performance issues when a certain number of redirects were loaded into the module.  That was release 2.  A significant amount of caching was added to address the performance issues.  Unfortunately, I had made a mistake in the packaging of the second release, so today’s release is the recommended download.

How Did I Map The URLs?

With over 700 blog posts, it wasn’t realistic to add a redirect record for every single blog post that I have.  Instead, I used Google Webmaster Tools to identify the most popular pages on my site that were impacted by the blog module change.  I mapped a redirect entry for every page that had 10 or more direct inbound links to it from another website.  Yes, that was quite a few pages.  I could have set a different benchmark to use, but that one seemed good to me.  For the rest, I am able to submit an XML Site Map to Google Webmaster Tools for indexing.  An XML Site Map is automatically generated for you by Live Blog.

In total, I’ve spent 4-5 hours working on the module, and another ~2 hours mapping URLs.  Of course planning, testing, and implementing the blog module itself took time too.  At the end of the day, that was all time well spent to retain traffic on my site, and put my best foot forward to minimize the impact to visitors that are visiting my site.

I invite you to play with the module.  There are many different types of redirect modules out there.  This one was meant to handle a very specific use case, hence the name.  I hope you like it!

Download the Simple Redirect Module

User groups in general are great.  They do for the average person what few other venues and mediums can…  They connect people in meaningful ways.  Sure, you can log onto your favorite social network and find people with similar interests, but you have to build a relationship first.  That takes time.  At a user group, everyone is there for the same reason.  They all want to learn more about the overall topic.  Once you share a slice of pizza or a drink with your fellow user group members, you have quite possibly built a meaningful relationship for life.

You may or may not know, but I assist in managing the user group program for DotNetNuke.  Over the past month or two, there have been a greater number of requests for helping people find user groups, but also people wanting to run a user group in their area.  This is very exciting!  There are numerous reasons that we could point to as possible reasons for this increase in activity.  Regardless to the reason, I just wanted to highlight some of the new user groups that are forming.

Queensland, Australia

The SE Queensland DotNetNuke User Group is being run by Ian Sampson (@glantonian), Director of Glanton Solutions.  He is a long time DNN user and supports some very impressive DNN websites for some of the higher profile customers any of us can hope for.  They have landed a heck of a first speaker too…  Bruce Chapman (@brucerchapman) of iFinity Software.  If that doesn’t ring a bell, iFinity’s flagship product is URL Master.

Their first meeting is on March 22, and their topic is “What’s New in DotNetNuke 6.2?”  This is certainly a must-see topic and presenter!

• User Group Homepage
• Meeting Details
• LinkedIn Profile

Portland, Oregon

The west coast of the US in general doesn’t have as much user group activity as I would like. I am not sure of the exact reasons why, but Greg Griffin hopes to be the catalyst to change that. He and the previous leader spoke and chose to handoff the responsibility. I don’t have quite as much information about the plans for this group, but if Greg’s emails are any indicator, Portland should have some great meetings very soon, beginning March 15.

• User Group Homepage
• Meeting Details

Tampa Bay, Florida

Tampa Bay had a user group in the past that began to catch some momentum.  It had several great meetings and included Joe Brinkman and myself as speakers.  However, it ended up having to cease having meetings.

Bernadette McCarthy has eagerly asked to take over this user group, and I am extremely glad that she has.  She brings a very high level of excitement to the group, and they haven’t even met yet!  This user group has great potential, considering that it is so close to the ODUG, and Tampa is a hot bed of Microsoft-related user groups.  I hope to see them grow quite quickly.

Their first meeting is a meet & greet on May 2. 

• User Group Homepage
• User Group Website (not quite live yet)
• Meeting Details
• Twitter Profile

Central Ohio

The Central Ohio DotNetNuke User Group has an extremely motivated individual taking the reins. He is quite simply the most excited person that I’ve spoken to about user groups in the recent past, and he cannot wait to meet all of the people in his area. Dustin Eastman is the new leader of this user group and has scheduled their kick-off meeting on March 15.

• User Group Homepage
• User Group Website
• Meeting Details
• Twitter Profile
• Facebook Profile
• LinkedIn Profile

Do YOU Want to Run a DNN User Group?

With all of this renewed interest in user groups, I have to ask… Are you interested in running a user group? If you are, please let me know.  I’d love to talk to you about the user group in your area.

Discuss Running Your Own User Group

For the March meeting of the Bay Area DotNetNuke User’s Group (3/6/12)at the DotNetNuke World Headquarters Adam Humphrey from Adammer LLC will be presenting “Pushing Pixels in the DotNetNuke Ecosystem Principles of DotNetNuke Skin Design”

You must RSVP via Meetup.com

The new DotNetNuke store arrived last week – and what a momentous day for vendors like myself who use the platform extensively.    The old Snowcovered store had remained quite stagnant for a long time, and while it had many strengths, there were a lot of weaknesses that needed to be fixed.  This  has been done, and everything is good!

Well, almost everything.  One feature that vendors use extensively is the ability to track visitors to both their product page and their vendor page.  While a vendor like myself has no idea overall what sort of traffic the site gets, we have the ability to create a Google Analytics account and see traffic to ‘our’ specific pages in the site.

One of the big changes with Snowcovered to DotNetNuke store was, of course, the domain name.  And anyone who knows anything about Google Analytics should know that it works on a combination of your tracking ID and the domain name. 

So it should be no surprised that many people will see analytics graphs that look something like this:

Oh dear-  all my customers disappeared about the 13th of February!

To fix this, it’s quite simple, you just need to change the tracked domain name so that it looks at the new store Url.

To do so, just follow this guide:

1) Click on the little ‘cog’ icon on the top right of the page

2) You will get to the profile page.  Click on the ‘Profile Settings’ tab:

Where you see ‘www.snowcovered.com’, change it to ‘store.dotnetnuke.com’.

Click the ‘Apply’ button at the bottom of the page.

That’s fixed that.  But the profile is still named ‘snowcovered’.  We’re all going to be using the term ‘DotNetNuke Store’ from here on in, so better get that fixed.

3) Click on the ‘Property Settings’ tab:

Where it says ‘snowcovered.com’ change it to ‘store.dotnetnuke.com’.  Of course, you can put anything in the ‘Property Name’ field – you don’t need to stick to the domain name.

Click on ‘Apply’, then refresh the page, and you’ve fixed it all up!

The changes will take up to 24 hours before traffic starts appearing again. 

Bonus : Better Tracking

In the old Snowcovered store, the plethora of Urls each page could be found under meant that tracking a canonical page was a bit of a dark art when it came to Google Analytics.  However, this could easily be done by viewing pages by title – no matter what the Url, the title was always the same.

Alas, when the new Google Analytics came out, the old ‘content by title’ report disappeared (or was buried further than I was inclined to look).   This was most frustrating.

However, salvation is at hand – the new and improved store uses the Url Master module with a custom Url Provider to deliver the store Urls.  No more messy, duplicate Urls, now each product listing has a canonical Url that all traffic will use.

You can see the difference in this pageview excerpt.  The duplicate Urls are highlighted in yellow, and the canonical, friendly Urls are shown in Green.  The old Urls were driven by the Product ID, while the new Urls are driven by the product name.  This makes it easier to track what they are for, are nicer to look at, and rank better in search engines to boot.  Chalk up another great use of custom module providers and Url Master.

By next months reporting period, the old snowcovered Urls will gradually dissappear into history.  But, because we can re-use our same Analytics account, we can still look at multi-year trends in pageviews, referrals, and all the other deeply interesting data you can slice and dice with Google Analytics. 

So if you’re a store vendor, and you haven’t yet fixed your Analytics, get clicking!

This blogpost is about disk permissions and asp.net applications like DotNetNuke. Although there are probably many posts like this I write this because permissions, or more precisely the lack of them, are the root cause of many support requests. And a little knowledge is all that would have been needed to avoid the situation.

Background: the worker process and its app pool

An asp.net application is just that: an application. It is a program running on your server calculating what HTML to spew out to the requesting browser. This is quite different from serving html in the classic way. There the server just streams files from your server’s hard disk over the wire. No processing as such. Just “serving”. But asp.net applications (and their predecessor ASP and alternatives such as PHP) require the server to process instructions of a program that will tell it what to send to the client. This has given us the data driven web site and the whole Web 2.0 revolution.

To do this processing the server starts up the so-called worker process. You can actually see this process in action if you’re on the server which is serving asp.net pages and bring up the Task Manager and flip to the “Processes” tab:

They’re called “w3wp.exe” (for WWW Worker Process) and in this screenshot you can see two of them. By the way: this is a really useful place to check the health of your site. It is probably always my first stop. You can quickly see if the worker process is clipping the CPU (i.e. it’s at 99% CPU) meaning it is consuming all processing power of your server, or if it is consuming a lot of memory (usually not a reason to panic).

The worker process encapsulates the code that is running for asp.net. Because the server is starting this up autonomously based on http requests, this process is boxed into an App Pool. The app pools are kept in a list in your IIS manager:

The app pools govern how much the worker process can consume from the server like in terms of memory for instance (lest they complete consume the server and bring it down). The app pool, therefore, protects the server from potentially hazardous code in the asp.net application. The app pool also gives the worker process its identity. It is the latter we are concerned with here but we’ll come back to this in a bit. What you need to know at this point is the existence of the worker process and the app pool, the relationship between the two and where you can find them.

Windows disk permissions

This should not be a big mystery. All items on your server’s hard disk (folders, files) have a set of permissions that commonly inherit down the folder/file tree. Right click on any folder on your server and select properties and you get a popup of that folder’s properties with a “Security” tab. Go to this tab and you’ll see something like this:

The concept is simple here. You can specify users and roles with the level of access to this resource. So giving someone Read but not Write access will allow them to see and download/open documents, but not change those documents or upload new ones. This paradigm is pervasive in computing. What you may not realize is that when the worker process (i.e. the asp.net code) accesses the hard disk it needs to have a “face” for the system to authenticate. It’s “identity” needs to have the right access level to what it wants to do on disk. The way that is implemented is through the identity of the aforementioned App Pool that is responsible for taming the worker process.

App Pool Identity

The app pool a worker process belongs to specifies which identity it will assume when it goes to Windows. Check out the advanced settings in IIS Manager for an App Pool:

So this app pool runs as “NetworkService” when accessing the disk. Note that the default for this depends on the IIS flavour. Commonly you’ll see “NETWORK SERVICE”. What is important to keep in mind though is that these default accounts are local to your server. I.e. NETWORK SERVICE on server SERV-A in your network is a different account than NETWORK SERVICE on SERV-B on your network. Even though they have exactly the same name. Well, actually their full names would be “SERV-A\NETWORK SERVICE” and “SERV-B\NETWORK SERVICE” but we don’t always see it like that in the UI. Keep this in mind!

The bottom line is that your app pool should have access to the files of your ASP.NET application. And write access as well in the case of an app like DotNetNuke as it is able to install extensions (modules, skins etc) which means writing files to the application’s file system. Let’s examine that in more detail.

DotNetNuke and its Installer

DotNetNuke’s most powerful feature is its ability to install and upgrade extensions which are uploaded as zip files. DNN’s installer unzips those and, based on the information presented in an XML manifest, it begins to write the contents of that zip file to the server’s hard disk. It will write files only inside it’s own application’s directory. Never beyond that. And that’s good. You want the server to encapsulate the application and not have the risk of some rogue module writing executable code to your Windows files. The installer typically writes ascx files to a folder it will create under DesktopModules. These files are template files that tell the server how to flow the HTML. Next to these ascx files it will also typically write one or more dll files to the bin folder. This folder is the most important folder of your asp.net’s application. It is where the compiled code sits. Waiting to be invoked by the worker process as the ascxs tell it to go to them and do some fancy processing.

The installer performs another very important function which will have some bearing on the problems we will describe below. That is the running of SQL scripts. The module programmer packages the zip file with a bunch of scripts that prepare the database so that the application may do its work. These scripts are incremental. That is: they are run in order and during an upgrade DNN’s installer works out which scripts it needs to run to upgrade the module. Keep this nugget of info in mind as we examine the common failure scenarios.

What you need to know by now is that the installer writes files to disk and very importantly to the bin folder of the DotNetNuke application.

Common Failure Scenarios

The focus of this post is on errors in disk permissions. These permissions can lead to serious malfunctions in your application.

After Server Migration

Servers die. Or you need a bigger/better etc server. There comes a moment in the life of your website that you’ll need to move it. So you (x)copy over the files of the asp.net app, register the app in IIS and away you go. But this is where the problem begins. The files with FULL permissions for “SERV-A\NETWORK SERVICE” are now running on SERV-B. And the asp.net app is now running as “SERV-B\NETWORK SERVICE” although all you saw was “NETWORK SERVICE”. If you’re lucky (or not depending on how you look at it) your site will still have read access for the new identity and the site will fire up correctly. But what will now happen when we try to install, or worse upgrade, a module? Check below.

After Restored Backup

Murphy’s law has it that a site will only die when we haven’t got a backup. But just in case you do have one please read this. Your backup might not have the full permission set of the files stored with it. It all depends a bit on your backup solution. What is also common is a combination of this and the above. I.e. a server has died and we restore to a new server from our last backup (pfew). Again what you need to keep in mind is that the permission set may not be right for the worker process’ identity.

Common Failure Effects, Symptoms and Solutions

These are common results from mishaps after the above.

Module Install Failure

Keeping in mind the application is unable to write to one or more places of the application’s file system it is easy to see that the installer would run scripts but not be able to write files. Although the installer is pretty smart this is still something that can happen and I’ve had customers report in with installation problems resulting from this. The biggest problem here is that DNN’s installer will have already run the SQL scripts to install the module but the actual installation failed. Now, when the user tries to install again the installer will re-run the scripts leading to all kinds of spectacular SQL failures as the SQL objects are already there that the installer should be creating. This is messy but ultimately easily solvable. Manually rip out all objects related to the module from SQL and correct the disk permissions then install again.

The main reason this scenario is not that dangerous is that (1) modules are usually (if well programmed) encapsulated so they will not damage other bits of the system and (2) there is no user data yet as we are just installing. So you can afford to horse around with the bits that came with the module provided you don’t touch the rest of the application.

Module Upgrade Failure

This is the real nightmare scenario. And it is not uncommon. This is also the main reason that I advocate making a backup of your installation before you upgrade a module. Why is this scenario so bad? Let me explain. The installer will begin to upgrade the database objects of the module first. At this time the data may well be transformed (columns being deleted, added and data being moved to other tables for instance). In short this is typically irreversible. DNN has no concept of uninstall largely due to the complexity of this bit. The scripts run first and then the file copying begins. So now the server has to begin adding files, overwriting files and possibly deleting files. Presuming this has become impossible due to a permissions issue, we are now left with module code (in the bin folder for instance) that thinks it is version A and the database tables thinking we are now version B. The installer will bomb out of the install process with “cannot overwrite file XYZ” or “cannot access ABC” and it won’t register in DNN that the module updated. Even though the scripts have run just fine.

The effects are generally that the module will fail spectacularly with messages of the kind “Column XYZ could not be found in table ABC” etc. The error is easy to spot but harder to solve. In fact you are going to have to do one of two things. You can mimic the DNN installer and continue where it left off. But for that you need a lot of DNN knowledge. In short you’ll need to (1) copy the files from the zip to their correct destination, (2) update the versions in Packages and DesktopModules tables and (3) update the module definitions if there are any changes. The latter can be quite elaborate work. And then we don’t know if upgrade code should be run from within the module. If it does then … well, we’re stuck. But this is relatively rare, as are changes to the module definitions, so just doing 1 and 2 above might do the trick.

But really the best way out of this is to roll back to the last backup. As you followed my instructions you have a backup ready to be restored. And then you just set the permissions correctly and try the upgrade again.

Internal Module Failures

Many modules use the file system. Certainly my Document Exchange does so. So having permissions on disk can be crucial to the operation of these modules. Keep this in mind. Typically you’ll see error messages starting with “Could not find a part of the path” or “Could not access”.

Setting Disk Permissions

So how to set these permissions correctly?

1. Look up the identity of the worker process in the app pool settings
2. Open up the folder of your DNN installation and select properties and go to the “Security” tab
3. Click “Edit …”
4. Click “Add …”
5. Type in the name you looked up under 1 (you may need to Google on alternatives at this point if you are still not having luck)
6. Make sure to transfer these new permissions to all children
7. Verify a couple of levels down on a random file. Are permissions as they should?

Final Note

First and foremost I am a programmer and not a Windows administrator. What is in this post is the result of me having to solve installation issues over the years. I will not claim this is the definitive guide to asp.net permissions debugging. But it is a good overview of the causes of a number of issues I’ve dealt with in DNN/DMX support. And it is not uncommon unfortunately. Though the above may at times be considered common knowledge, I know it is not. And I also know it is hard to explain in a paragraph or two. Hence this post so I can point you here.

The 13th February, 2012, marks 10 years since the .NET Framework 1.0 was released, well, according to Wikipedia, anyway.  I don’t recall the specific date, but I remember the general period vividly.

This little point of achievement will probably pass most people by as they spend another day creating new software based on this platform, or use one of millions of websites that the platform provides, or any number ways of interacting what has become an incredibly successful framework by any standard to measure.  But I thought it might be fun to just pause for a minute and reflect back on the last decade.

Is ten years such a long time?  Realistically, in computer industry years, it’s an absolute eternity.  The internet has really only been around for most people since the late ‘90s. The Windows 95 platform only lasted for 5 or so years before being dropped.  Visual Basic (the original version) went from 1.0 to 6.0 in 7 years, before being shelved to make way for .NET.  Many programming languages have come and gone in less time than a decade.

The way we were

It’s all too easy to take for granted the powerful tools we software developers have at our disposal.   It’s very easy to forget the kind of world Microsoft-technology developers had 10 years ago.   But let’s just cast our minds back to the late 1990’s and early 2000’s.    If you wanted to build a website using Microsoft kit, you’d probably have been using:

- Either C++ or VB6 to build back end components.

- SQL Server 6.5, or, if you were lucky, SQL Server 2000.

- Windows NT 4.0 server, or, if you were lucky, Windows 2000 Server

- Microsoft IIS 4.0 or IIS 5.0 running ASP pages.

In reality, in any fair comparison with alternative web development tools at the time, it wasn’t ideal.  In fact, many frustrating times, frankly, it was painful to get things done.  You’d spend half you day producing something, peppered with thoughts like ‘there has to be a better way’.

The Genesis of .NET

I was working on a large development project for a financial services company at the time.   It was a sophisticated setup, where VB6 components plugged into a business layer which was all based on DCOM, written in C++ and somehow connected it all up and made sure it scaled.  I say somehow, because it really was an obscure black box of dark arts, and there was only one guy on the floor who really knew what was going on.  He was brilliant in the way an older developer with a bushy beard can be.  But he wasn’t good at explaining what was going on in that layer.  You just had to take it on faith that it all worked, which it did, most of the time. 

The problem was in deploying to production.  In those days, IIS had a tendency to eat up a pile of memory and then freeze up.  The notion of automatically dropping an application pool on a periodic basis hadn’t happened yet.  And all those COM/DCOM components had to be installed on the server.  I don’t mean sent via FTP to the \bin directory, I mean, create an installer package, log onto the server, and run the installer.  And hope over all hopes that someone didn’t include a bad reference and send the entire team to “DLL Hell”, as it was known.

And that’s just the deployment part.  I was employed as a VB6 programmer, which I knew well, having come up through the VB ranks from 16bit Visual Basic 3.  While you’d never find me defending VB in an online forum, it wasn’t a bad way to quickly build software. But the not-quite-OO patterns in VB6 really made a developer do some unsavoury things.  And if you had a friend who was programming on the hot-new-language ‘Java’ they’d always guffaw, and talk about the language purity of Java.  Yes, never sit around with a bunch of developers discussing programming languages.

As the company I was working at was quite a large one with a substantial IT budget and a pure Microsoft technology platform, it got very good treatment from the Redmond HQ.  And one of those things was an early look at what was called ‘Next Generation Windows Services’.

This sounded like the answer to the frustrated VB/IIS developers requests.  This was going to be an entirely new programming platform, one that you could get enthusiastic about.   Gone would be COM/DCOM – although you could still use it if you wanted to (I didn’t ever want to, again).   Gone would be the VB6 platform, gone would be the VB IDE.   In would be an entirely new programming language called C# as well as a total rewrite of VB to make it a proper language.  This was going to be a proper object oriented language in either the less-verbose C style, or in the more verbose VB style.  Funnily enough, on first inspection C# looked exactly like Java.  Hardly a coincidence, one would suspect.   All new was a event-driven web page programming style, which smelled a lot like VB forms.  There was to be ‘xcopy deployment’ so you could just copy the program up to the server.  DLL Hell was to be banished forever by keeping the component metadata in the component itself, rather than in the operating system registry.

Funny thing – in true Microsoft style – they had a melange of names for it.   When I first heard of it,  the new version of ASP was going to be called ASP+.  And that’s why it has the .aspx extension – you couldn’t have a + in a Url, so they rotated it 45 degrees, and you had an ‘x’ on the end of the old .asp extension.    And C# itself, was basically C++,+ – with another ‘+’ thrown in for good measure.  Arrange 4 + in a square and you get #.  And thus C# was named.

I don’t remember when I officially heard the name .NET – it was probably closer to the launch – by that time I no longer worked at that company, and so lost access to the stream of new announcements from Microsoft.  It’s hard to believe today, but back then Microsoft didn’t do a lot of public BETA testing.    But at some point it was announced, then released.   And the .NET world was born.

.NET Leads the Microsoft Developers out of the Wilderness

It’s hard to understate the difference this change made in my life and career.  At the time, a lot of developers (and companies) I knew were jumping ship, and moving across to Java.  This generally meant a change in web server, programming tools and probably database platform for good measure.  And none of those were provided by Microsoft.  I’m sure the board reports at Redmond had some metric for measuring this.   One of the biggest secrets of success for Microsoft has always been the support of developers.  Having an operating system without third-party developer buy-in means failure.    The original success of Visual Basic was the ease in which people could build ‘GUI’ apps quickly, in an era when DOS based programs and mainframe terminals were still the norm in companies.  Users would have fits of delight when they could use drop-down boxes and update buttons instead of command line driven programs.

But the sea change from Windows GUI to Web was fast, and the tide was running away from Microsoft.   The challenge was on – how to take all those experienced and Microsoft-trained VB developers and turn them into web developers?

The answer was ASP.NET Webforms.  Now, to some web purists, the way in which this was solved still makes them go cross-eyed with indignation, but the simple matter was that it not only worked, but it did so in which it didn’t take a massive retraining for an efficient VB developer (or even a C++ developer, for that matter) to start being productive.

Of course, some of the bloated buggy and run-at-a-crawl sites that resulted are probably not excusable, as too many desktop developers didn’t really take the time to learn that programming for the web really did require a new mindset.  But, for Microsoft, it worked.  Within a short time, websites with the now-familiar .aspx extension were popping up all over the web.   The flow of companies and developers to Java was stemmed.   People like myself stayed on board.  It wasn’t necessarily that someone like myself couldn’t see the faults in Microsoft – clearly I could – but it’s crazy to pretend that no platform or environment is free of shortcomings.   As always, it’s about getting something that works, to market, in the quickest possible time.  By 2005/6, it was very common to find jobs looking for ‘3 years C# experience’ – which meant you had to be on board from the get-go.  Having conducted interviews around this time myself, I found that many people were being quite liberal with the truth on their experience, but .NET was here to stay, and anyone looking for a future in Microsoft platforms had to start collecting experience, fast.

.NET grows and grows

Despite the busting of the ‘internet bubble’, in reality, web developers were about to enter a golden age.  The truth of it was that the cost of building websites and launching them was falling quickly.  Part of that was cheaper hardware, and part of that was the growing stack of frameworks that added layer upon layer, each abstracting away a previously difficult and troublesome task, and making it a simple job.  Open source was, and remains, a huge part of this.   Of course, the leading web server, Apache, has always been an open source product.  But little by little, Open Source made it’s way into Microsoft as well.  But even without Open Source, there were plenty of free things that were getting added to the .NET family.   

Of course here is the appropriate point to mention DotNetNuke.  This is not to belittle other open source .NET projects, but it’s the one I work on and know most about.   Given that ‘.NET’ is part of the name, it should be obvious to all how intertwined these two things are.  DotNetNuke was (and remains) an open source framework which allowed you to quickly create websites, without having to build all the associated messy bits like authentication, logging, not to mention the killer app of DotNetNuke which was the ability to easily install third-party modules to infinitely expand the site with new functionality.

It sounds so simple and expected now, but this was such a massive jump in productivity it is hard to believe the old way of working.  In the heady days of the ‘internet bubble’, if you did find someone building an ASP based site, they would have had a team of developers working for 6 months to produce an approximation of what you could get from a DNN install in 6 minutes.  And it probably would crash too frequently, especially at dreaded upgrade time when it was time to release new code and find out if a trip to DLL Hell had been unwittingly scheduled.

I worked on one project that was building a social network site.  This was just before Facebook exploded out of it’s college niche and out to the greater public.  This was a sophisticated site that had blogs, forums, chat, video and photo uploads, and all the social features you’d expect including friends, groups and all the rest.   I’ve never know the exact figure, but my guess is that a 7 figure sum was spent in an 18 month period with developers to create this site, myself being one of them.   And without a shadow of doubt, I could build that same site today in DotNetNuke with a few third-party modules for more like $7000 and 18 days, and most of the money would probably go to a talented designer.

It’s easy to nod your head and say ‘yeah, that’s true’, but in few industries does this type of productivity leap occur.  Of course, this is nothing special with regards to a Microsoft platform – indeed many open source advocates would argue that anything built on a Microsoft platform is not truly open source.  But for a person who is tasked with producing a website that matters little.  But what shouldn’t be skipped over is that DotNetNuke wouldn’t exist without the .NET platform.  And I don’t mean that obviously because of the inclusion of the name, but more that the old VB6/IIS 5/ASP era was just not a good enough design to produce a modular masterpiece like DotNetNuke.  It just wouldn’t have been possible.

.NET Did it Right

The reason that great solutions like DotNetNuke can be built is because of the inherent correctness of the .NET platform.  It’s a true object-oriented platform.  The way the programming languages were designed dumped out all the nasty workarounds and hangabouts caused by trying to maintain backwards compatibility.   This was a true masterstroke of Microsoft, and one which they copped a lot of criticism for.  To build a good .NET application, you had to build it from scratch, you couldn’t upgrade your old code (well, you could, but the results were usually awful).  But by forcing people to start from scratch, everyone could start with a clean sheet of paper.  And, as anyone who has accidentally deleted a first draft will know, the second draft is not only better, it’s written faster as well.

From the in-built memory management to the well-executed ability of .NET code to ‘reflect’ upon itself, .NET was a really good platform to build with.  It’s like the difference between a toolbox full of half-broken, unsuitable tools, and a toolbox full of shiny tools designed exactly for purpose.   Having the ability to select the right tool for each little job, no matter how trivial, means that the finished product always comes out better, with fewer rough edges, and always with a more elegant feel.

And we can tell .NET has been a success.  Not because Microsoft tells us so, but because they’ve never changed the name (well, not since it was released, project names and working titles notwithstanding).    The easiest way to detect a floundering Microsoft product is to look for frequent name changes.    We all can rattle off several products that go through a series of names before quietly being shelved (the various old versions of Microsoft phone operating systems being a prime example).   But .NET is still there, still being used, not being tinkered with.  Visual Studio is still Visual Studio, C# is still C#, with most people being blissfully unaware of how the name came about.  The true measure of developer stickiness, however, is a quick peruse of a jobs site.  And there are still plenty of jobs to be had working in .NET.  Sure, there are newer, ‘hotter’ platforms out there, I’m not a one-eyed Microsoft supporter in the least.  But can I still deliver a cost effective solution to someone who has chosen to use Microsoft based operating systems?  I sure can.  Are there still plenty of people choosing Microsoft Operating systems?  There sure is.  IIS is still the second-highest Web serving platform on the internet, and the best way to deliver websites through IIS is by building an ASP.NET website.

The next 10 years

10 years ago a lot of people I knew were either moving, or seriously considering moving from Microsoft products into Java as a platform.   I haven’t heard someone say that in years.  In fact a couple of the Java people I know are starting to dabble in other platforms and languages, and they tell me that they feel Java has lost its way.  I couldn’t say myself – I’ve been deep into the .NET stack for a decade and haven’t spent much time exploring outside of that.  There has never been a shortage of opportunities for me, there has never been a point where I’ve felt that the platform was going nowhere.   In fact, every time I look up, I find lots of new and interesting stuff coming down the road.

There’s an entirely new Windows version coming along which is destined to bust out of the traditional desktop and onto other devices, there’s lots of new ways of building traditional ASP.NET websites,  there’s Azure cloud services to build, as well as plenty of traditional desktop applications.   The next 10 years is going to see the explosion of web-enabled mobile platforms, either through on-device apps or mobile-optimised website apps.   There’s still a long ways to go in terms of building websites on platforms like DotNetNuke.   Yes, it’s fair to say I still feel the same level of optimism about the future as I did 10 years ago.   I guess I’ll see you in a decade!

What do you think?  Did .NET get it right 10 years ago?  Will it still be around in 10 years time?  What’s your experiences in the last 10 years – please feel free to share in the comments.