Net Data Design, LLC Blog

Perhaps I was a little quick in singing praises about the way DotNetNuke (DNN) is handling releases. I posted a blog not long ago about this subject, and at the time it seemed true, but not so fast my friend.

In the last two or three releases there have been some major issues, one that directly effects me is a missing method from the DataProvider in 5.4.3. What’s makes it slightly more strange is a very similar issue was found in the previous release (5.4.2). Two other “showstopper” issues that also appeared in recent builds are DNN -12501 and DNN-12412.

In DNN 5.4.0 a change to the PageBase class in DNN has caused aspx pages to break in 3rd party modules. Meaning scripts wouldn’t run, RSS and some AJAX callbacks where broken. The problem was fixed, but a game of Jenga has begun.

When it was first announced the rigid release times sounded like a good idea. Every quarter there is a minor release, every Month a bugfix release. The dates for these releases cannot be missed. And to the Core Teams credit, they haven’t missed a date yet. That said, perhaps DNN needs to find a way to detect breaking issues before RTM, beta has always been an expensive way to do so, but one that DNN seems to avoid.

Of course, you’re going to get the people who press a beta into production, but the beta releases would certain produce a better production build to the DNN community.

Over the last nine years we’ve built a reputation for creating websites that are top-shelf  both aesthetically and functionally. In addition to being  very good at what we do, we also like having fun when the time and place are right. So when a client says yes, what is it that they’re buying from us?

• A website? That may be why they came to us and what the end goal is, but that’s not why they choose us. A lot of companies create great websites.

• A good time? Fun is a big part of it, who wants to deal with up-tight people all day. But even we know that there are better ways to spend money and have fun than hire us.

• Our methodology? They definitely want to know we have one, but the details aren’t as important to most clients as they are to us.

• Experience? Again, this is part of the reason but not what makes them say yes.

See, they don’t decide to hire us for the website they’ll get or the promise of  a cold beer, cocktail or even because we’ve got hundreds of web projects in our portfolio.

So why do they hire us?  Because we put them at easy about their project.

When most clients set out to select a web firm they are probably apprehensive at best. But somewhere along the project, some clients turn overbearing and feel they need to micro-manage. Most clients like to be in the front seat, but they prefer the shotgun position, not behind the wheel. So, what do you do with the client who insists on driving?

In my eyes, there are several ways to approach this issue.

• First, you could resign from the project and request the client find someone else to finish it (or recommend a company you don’t care for).
• Second, you could tactfully push back on the client and tell them who is in charge of the project and ask that they allow us to do our job.
• Third, you could take what the client says, give them what they want, and finish the project as quick as humanly possible so you can move on.

So which do you choose?

In my mind, the best thing to do is to finish the project as soon as you can (without jeopardizing the integrity and quality) and put the whole thing behind you. When it’s done you can always elect not to work with the client again. It may be difficult to handle it that way, as some dialogue will be needed in the future. However you always want to make sure you remain professional in all business situations regardless of whether or not the client is right or wrong. This will ensure that your reputation will always be positive and no bridges will be burned. At the end of the day, your responsibility is to make sure the client is happy.  Stick with that principle and you’ll be in a good position.

An alternative method of installing DotNetNuke on IIS 7.5 9or IIS 7) is using the free helper application by Mike van der Meulen. MakeDNNSite is a nice little package that will give you a new DNN install without a lot of hassle. There is no manual web.config editing, Application Pool creating or setting of permissions (see note below). It will even download the latest build for you or use a package that you already have downloaded.

I have used this method several time in testing and found it to be flawless (2008 R2, 64-bit). It does come with a few restriction, such as you can’t install using a sub-domain. It said to work on IIS 7 and 7.5 both 32-bit and 64-bit and SQL Server 2005 and 2008 both full and Express editions.

Because MakeDNNSite works on both IIS 7 and 7.5, the Application Pool created uses the NetworkService account. While this is fine for IIS 7, however it is not the preferred account for IIS 7.5, rather the IIS AppPool Idently account should be used. This can be simply changed by right-clicking the newly created AppPool and selecting ‘Advanced Setting’. There, under Process Model, change the identity to ‘ApplicationPoolIdentity’.

If you opt to use the ApplicationPoolIdentity you will need to update you permissions on the website directory as well. I have blogged about this in detail (IIS 7.5 AppPool Identities).

In short, it’s a really nice tool at a great price (Free.) I highly recommend it for all DNN users, regardless of your environment or skill level.