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.

DotNetNuke allows you to define custom roles to manage your site’s permissions.  Recently users have been reporting an error related to a corrupt cookie that stops them from logging in.  The problem is due to exceeding the number of roles.

Gemini Issue: http://support.dotnetnuke.com/issue/ViewIssue.aspx?id=8797&PROJID=2

Forum Thread: http://www.dotnetnuke.com/Community/Forums/tabid/795/forumid/-1/threadid/234880/scope/posts/Default.aspx

The problem is due to the need for the user’s portal role names to be saved in a cookie.  The list of role names is encrypted and then saved in a cookie called “portalroles”.  Cookies have a physical size limitation (2K to 4K depending on browser), and so there is a physical restriction to the number of roles.

But what is the limit? 

Unfortunately, as it is the names that are saved, which can vary in length, I cannot provide a definitive answer, but it appears to be in the 40-60 range depending on the length of names used for roles.

This is not an easy issue to solve.  If we used role ids then the number of roles could be increased.  However, the problem with this approach is that it means that we will need to do a database call to convert the saved role ids to role names, which is the problem we are solving by saving the names in the cookie in the first place.

However, if a user is being assigned to over 40 roles then there is probably a better role arrangement that can be used.

With the imminent release of version 1.0 of the ASP.NET MVC Framework, does this mean we should now all be learning MVC as the “old” Web Forms model will be replaced?

The answer is a resounding NO.

The Web is a stateless platform.  With the introduction of ASP.NET over 5 years ago, Microsoft provided a “stateful” programming model, so that developers who were familiar with “stateful” systems likes Windows Forms would feel comfortable, and wouldn’t have to learn something completely different to work on Web Applications.

This model has proven to be very successful as demonstrated by the number of ASP.NET sites and by the number of companies providing ASP.NET Controls which are built on Web Forms.

Enter ASP.NET MVC.

Now we have a new paradigm for Web development, one that does not attempt to build a “stateful” wrapper around a stateless platform.  However, it does solve other issues.

There are two big issues with the WebForms approach.  First is that it is not very easy to Unit Test as the model is tightly bound to a Web context.  Second, designers have little control over the rendered HTML from the controls used.

ASP.NET MVC addresses both of these needs.  It is much more testable, and designers have much more control over the HTML that is rendered.

So now we have two ways of building Web Applications, the more “traditional” Web Forms approach and the newer “MVC” approach.  If you like the older Web Forms approach – stick with it – as the ASP.NET team is adding many improvements for  ASP.NET 4.0, but if you are more comfortable with a more testable approach and you want more control over the rendered HTML, now you have a Framework designed for you – MVC.

DotNetNuke is firmly planted in the Web Forms camp.  While there may be new approaches, that we can consider, and lessons that we can learn, it is not likely that we will convert the DNN platform to be built using the new MVC Framework.  At least not anytime soon.

Welcome to a new series of short articles on miscellaneous tips, tricks and information for DotNetNuke Users and Developers.

Purge Cache Scheduled Task

Over the last few days I have been trying to solve an issue with the Scheduler in version 4.9.  There are a number of threads that discuss the issue in the DotNetNuke Forums.  One of the threads was concerned that the Purge Cache Scheduled Task wasn’t running properly, as the cache items were not being removed from the cache when this task completed.

While there was a “real” issue with the File Based Caching provider (which has been fixed), the user did not completely understand what the Purge Cache task actually does.

Of course, part of the confusion arises from the name given to the task, which could be read to mean that the task removes all the current items from the cache.  However, this is not what this task is designed to accomplish.

Both the File Based Caching provider and the Broadcast Polling Caching provider use mechanisms that can be used to synchronize the ASP.NET cache between servers in a web-farm. 

In the File Based Caching Provider, file stubs are saved to the Portals/_default/Cache folder which are used to create a file dependency on the cached items.  When the cache expires on one serer, the file is modified which causes the other servers to expire their copy of the cached item. 

Unless the cached item is explicitly removed (rather than scavenged) this file stub is left in the Cache folder.  Over time the number of file stubs will grow, so the Purge Cache task is used to clean up these file stubs.

So the Purge Cache task does NOT clear the ASP.NET Cache (there is a button in Host Settings that does that).  Also it is important to note that unless you are using a Web Farm you do not need to use this task at all, as the file stubs are only created in Web Farm scenarios.

I hope this helps.  If you have any ideas for this series of tips, let me know.

In the original Star Wars movie there is a classic scene where Obi-Wan and Luke enter the Tatooine Space-port.

Storm trooper: Let me see your identification.
Obi-Wan: [with a small wave of his hand] You don't need to see his identification.
Storm trooper: We don't need to see his identification.
Obi-Wan: These aren't the droids you're looking for.
Storm trooper: These aren't the droids we're looking for.
Obi-Wan: He can go about his business.
Storm trooper: You can go about your business.
Obi-Wan: Move along.
Storm trooper: Move along... move along.

Obi-Wan uses the “Jedi Mind Trick” on the Storm trooper to “suggest” what he should do.

Sometimes we need to do the same thing in .NET.

Consider the scenario where you have developed a class – MyClass - in a Library that you distribute - MyLibrary.  You want to reorganize your libraries and create a new – MyNewLibrary - and move MyClass to the new asembly.  The problem is that all your existing applications expect MyClass to be in MyLibrary not MyNewLibrary.

In .NET 2.0 a new assembly level attribute was added – TypeForwardedTo(typeof(MyClass)). This can be applied to the “old” version of the Library, and your applications will not break.

The procedure is as follows:

1. Move the MyClass code from MyLibrary to MyNewLibrary .
2. Put TypeForwardedTo(typeof(MyClass)). in MyLibrary for the MyClass type.
3. Compile the newly created MyNewLibrary .
4. Add a reference of MyNewLibrary into MyLibrary .
5. Recompile MyLibrary (because MyClass used to be located in that).

When your application attempts to get a reference to MyClass from MyLibrary  – it will be redirected to the correct MyNewLibrary.

Or as Obi-Wan would say - “This is not the assembly you’re looking for.”

There is one corollary to this.  In .NET 2.0 MyLibrary cannot be a VB.NET assembly – this has been fixed in .NET 3.5 (VB9).

I am currently investigating whether this could be an approach to the “Breaking Changes” issue, as we move forward with DotNetNuke development.