TechBubble

A couple of days ago, I blogged about my VS.Net Solution for DotNetNuke that allowed me to work on custom modules without making my solution file bloated with unnecessary DNN project references. After I posted about this in the ASP.Net forums, I got quite a few questions and comments. This led me to investigate further and see if it was possible to create a DNN development environment that would leave the core package untouched, yet allow you to develop your modules without having to worry about file references.

After several iterations, I believe I have a good solution. I have decided to call the solution “My Modules.” Here is how it works:

1) The “My Modules.sln” file resides in the root of the DNN folder. It consists of one required project and as many custom module/control projects you wish to add to it.

2) The required project I have named _DNNStub. This is a VB web project that is so named because it will always appear at the top of your list of projects. The only purpose of this project is to have a startup project for the solution. The project has one file — Default.aspx. This is the standard (unmodified) DNN Default.aspx file. In the file properties within the solution, the compile option is set to “None”. This file is included so the solution can have a startup page for debugging.

3) You may now add any of your custom modules projects from DesktopModules to this solution. I prefer to use web projects because I can easily add web-related resources to my project without resorting to tips/tricks. Also, once I load VS.Net, I have it open for days on end so the issue of load-time (which is frequently cited as a reason not to have web projects) is not relevant for me.

4) Whenever you add a custom module project, you must remember to add a reference to this project from the _DNNStub project. This will ensure that whenever you recompile, your compiled assembly will be placed in the root “bin” folder where it belongs. Alternately, you can set your project to build directly to the root “bin” folder. However, this may cause file locking problems and is not something I would recommend you do.

I have packaged everything you need into the Speerio My Modules zip file that is attached to this post. As an added bonus (and to prove that my solution really works), I have also added two custom modules projects — one C# and one VB.Net to the package. I have also added one webcontrol C# project. Here’s the 411 on these:

- Speerio RandomImage Module: This is a C# DNN module project. This module will randomly display one image from a folder of images. As a shortcut to creating a settings page, I coded the module so that it looks for images in a sub-folder based on the title of the module. So if your module’s title is “Random Images,” it will look in portals/{portal id}/Random Images. The complete source code for this is included and you may do with it what you wish. If you just want to install the PA, use the included zip (in the root).

- Speerio WeatherOutlook: I have setup a Speerio webservices server with some free webservices. One of these is a simple weather service. To illustrate use of webservices in DNN modules, I have included the Speerio WeatherOutlook module. This module will display the 7-day weather outlook for any U.S. zip code (sorry to others). It calls the Speerio Weather webservice at http://speerio.ws/Weather/Weather.asmx. Same as the Random Image module, full source is included, but in VB.Net

- Speerio Stock Quotes control: Another freebie in the package, is the Speerio Stock Quotes control. Written in C#, this calls the Speerio StockQuotes webservice at http://speerio.ws/StockQuotes/StockQuotes.asmx. A test page is included called Test.aspx.

Finally, I have included a script called DNNDebug.aspx in the package. I use this script anytime I see a parser error because it tells me that something is amiss in my ascx file. DNNDebug will let you load any ascx control and will display the exact error message that is preventing it from loading. Within the DNN environment, this message is obscured by the skinning engine and you see a generic parser error. I am confident this script will save you many hours of debugging. It has saved me on countless occasions.

I have tested all of these as best as I can, but it is possible that I have overlooked something. If so, please let me know so I can fix the problem.

Enjoy, and happy DotNetNuking!!!

Speerio My Modules.zip (110.12 KB)

Cross-browser support of web applications is generally overrated. Sure, it makes good business sense to make your product appeal to the broadest audience possible. But when it comes to web applications, I disagree.

Just today, when I released a public preview of NukeHTML (a HTML editor for DotNetNuke) there was a post on the ASP.Net forums about this issue. The poster was of the opinion that due to IE security flaws, more people use FireFox to edit their site content. This is impossible to prove and is therefore not a line of thought worth pursuing. It did get me thinking though. IE completely and totally dominates the browser market. That’s what the numbers say and is not an opinion. Even if a growing number of people are adopting FireFox, for a software business, does it make sense to make their web-based products cross-browser compatible?

After a few minutes of Googling, I decided that no one really knows. The obvious answer is that if your product is going to be used by website visitors, it makes sense to design it so that it remains accessible to non-IE browsers. Of course, if most of your site visitors use non-IE browsers, a different decision would be forthcoming. However, if you are building a web application, for a specific use (in this case HTML editing), for a specific audience (DotNetNuke portal content editors), then cross-browser compatibility is a complete waste of time from a pure business standpoint.

Businesses exist for one reason — to make a profit. If the total cost of developing a web app is increased by 20-40% to make it cross-browser compatible, is it better to go that route or is it better to keep the price down and make up for the (highly questionable) non-IE sales with an increase in IE volume? I think the latter strategy is going to be more profitable.

You can crunch the numbers in many ways, but here’s a quick and dirty example. Let’s say you have a product that will sell for $100 with IE-only compatibility and $120 with cross-browser compatibility (more development time = higher price). Assume the market size is 10,000 of which 9,000 are IE users and 1,000 are non-IE users. If 10% of the market purchased the IE-only product, you would get $90,000. Now, increase the price and make it cross-browser. Higher price causes the sales volume to decrease, let’s say by 3%. Now, you would only make $84,000 ( (630+70) * 120). These numbers would vary, but if you add the long-term costs of upgrades, support, testing etc. cross-browser becomes less and less attractive.

My conclusion: cross-browser compatibility has its place, but is not always the best decision. Sometimes it’s better (and more profitable) to stick with an IE-only solution.

Peace out.