Brian Swanson

Check out TotalRM.com

bgswanson@purpleant.com — Wed, 30 Dec 2009 23:14:02 GMT

If you haven’t yet, go check out TotalRM.com. TotalRM.com is the new site we’ve launched for our upcoming product TotalRM, a Customer Relationship Management (CRM) application. If you want to know more about TotalRM, check out the What is TotalRM? blog post that is already available. If you’d like to help us beta test, there is an application to sign up as a beta tester available on the home page.

Time for my MicroISV product not related to the development of the ACTUAL product

bgswanson@purpleant.com — Fri, 13 Nov 2009 20:14:55 GMT

I have had to develop and build several sub-systems related to the eventual launch of my MicroISV product, TotalRM. While there are many off the shelf products available in some of these areas, I choose to develop my own to ensure my ability to control and in the future support them if any issues were to occur. I’m sure I’m forgetting something, but here’s what I can think of:

Registration/Subscription validation
Updates based on product and version without running an installer (like QuickBooks, or World of Warcraft)
a separate app to identify and upload those updates to the server
Error Report submission

The time spent developing these items ranges from weeks to months, all of which is not spent on the most important thing, which is adding functionality to TotalRM, and getting it released.

In addition to the above items that I’ve directly programmed, I’ve also spent considerable time analyzing and researching other areas that are relevant to a software product, and the company trying to market it:

Source Control
Bug Tracking
Website software
Forum software
Obfuscation tools
Credit Card processor (including integration with)
e-Commerce storefront

There’s a LOT that goes into to creating, marketing, and eventually launching a software product or website beyond the development of the product itself. If you’d like a bit of an easier time with it, and don’t want to spend countless hours doing the research that many have already done, you should check out StartupToDo.com, Micropreneur Academy, and Answers.OnStartups.com.

Get Excel Column from Column Number with VB.Net

bgswanson@purpleant.com — Wed, 16 Sep 2009 16:00:31 GMT

I haven’t been blogging much lately, as I’m working full-time on TotalRM trying to get it to Beta very soon.

One of the things I’ve had to do for one of the companies that is using TotalRM internally on a limited basis, is importing data from an Excel spreadsheet. As a result, I had need to parse a column number into an Excel column (column 1 is ‘A’, column 27 is ‘AA’, etc). I searched the internet and found a solution which seemed to work perfectly until I ran into a spreadsheet that went beyond Excel column AY (column number 52). Below is my updated function for creating the Excel Column from the column number being passed in:

   1:      Public Shared Function GetExcelColumn(ByVal ColumnNum As Integer) As String

   2:          Dim Result As String = String.Empty

3:

   4:          Dim Primary As Integer

   5:          Dim Secondary As Integer

6:

   7:          Primary = Int((ColumnNum - 1) / 26)

   8:          Secondary = ColumnNum - (Primary * 26)

9:

  10:          If Primary > 0 Then

  11:              Result = Chr(Primary + 64)

  12:          End If

13:

  14:          If Secondary > 0 Then

  15:              Result = Result + Chr(Secondary + 64)

  16:          End If

17:

  18:          Return Result

  19:      End Function

Hopefully this will be helpful to some other .Net (especially VB.Net) developer out there attempting to read data from an Excel spreadsheet.

Announcing PaleDNN.com

bgswanson@purpleant.com — Wed, 25 Feb 2009 02:09:17 GMT

Purple Ant is pleased to announce the immediate launch of PaleDNN.com, a partnership with Lokheed Enterprises, created for the development and marketing of DotNetNuke modules. Our first module launched earlier today, a Weather Module, that has completely customizable layout based on CSS (along with many other features). We have several other modules in the works, and will be working to get the released as soon as possible.

Also, with the launch of PaleDNN.com, I am going to start posting my DotNetNuke related blog posts on PaleDNN.com, instead of on this blog. I have many interests, and write about (when I do actually write) a lot of different topics that may or may not be of interest to everyone. Separating my DotNetNuke related blog posts will allow those who are interested in DotNetNuke to read those blog posts, but not suffer through my other sometimes random musings.

Purple Ant announces the immediate availability of "SnagDaBits" v1.1

bgswanson@purpleant.com — Wed, 11 Feb 2009 22:13:06 GMT

Purple Ant LLC in partnership with Black and White Medical Consulting LLC, a Raleigh, NC-based medical consulting firm, is pleased to announce the immediate availability of SnagDaBits v1.1, an advanced data export tool designed and built specifically for customers of PatientImpact, a healthcare provider patient-survey company.

The initial set up of a doctor's office or clinic with Patient Impact typically requires more than a casual understanding of the database driving their Practice Management System (PMS) or Electronic Medical Record (EMR) applications. Black and White Medical Consulting having a deep understanding of PMS/EMR applications in general, and a specific knowledge of many vendors applications, can provide the technical knowledge to "mine" the necessary data from the database. After this initial set up, SnagDaBits takes what used to be a manual process of running queries against the database, and exporting to a specific file format, and automates the process via a Windows Service. SnagDaBits enables PatientImpact, and as a result the medical practice to get more consistent results from the export process.

With the release of version 1.1, SnagDaBits now includes the PMX (Practice Management eXtension) Client, a windows client that augments the PMS/EMR by providing additional data entry points for a patient that cannot easily or otherwise be incorporated into the PMS/EMR. Many of the older Practice Management Systems do not have a field for entering a patient's email address, which is a necessary component of the email surveys that PatientImpact provides to its' customers.

SnagDaBits and the PMX Client both run on Windows, and require the .Net framework v2.0 or higher.

For information on purchasing SnagDaBits, contact Purple Ant, Black and White Medical Consulting, or PatientImpact.

Black & White Medical Consulting, LLC (www.bandwmedicalconsulting.com) is a Raleigh, NC-based consulting firm that specializes in revenue cycle management for medical practices across the US. They also provide services to healthcare professionals who need assistance in selection and implementation of electronic medical records systems.

PatientImpact LLC (www.patientimpact.com) helps healthcare providers better understand their patient customers through its proprietary web-based outcomes measurement application that captures patient feedback in real time.

Budget 4.4 for Windows Released

bgswanson@purpleant.com — Tue, 03 Feb 2009 20:05:05 GMT

Snowmint Creative Solutions has released version 4.4 of their personal finance software Budget.

This release has several fixes and enhancements:

Balance window almost completely re-written, for faster performance and easier filtering/sorting functionality. Fixes bug with “view more info” checkbox on balance window.
Find Transactions now works beyond December 31st, 2008.
Text Export of Transfer records (includes history export for deleting an envelope) now includes an eighth field for whether the transfer was in or out of the envelope.
Enhancements to the registration process to improve issues with 64-bit Vista, and others experiencing errors during registration.

Purple Ant is responsible for creating the Windows versions of several of Snowmint Creative Solution's products.

DotNetNuke, secured pages, load balancers/firewalls, and infinite 302 redirects.

bgswanson@purpleant.com — Thu, 15 Jan 2009 18:00:21 GMT

DotNetNuke is more and more being used and implemented in enterprise environments. Having recently celebrated its 6th anniversary, it has become not only a full featured application framework/content management system, but a VERY stable environment for deploying high quality sites that demand high availability and quick response times. Different companies, of course, go about providing the "high availability and quick response times" in different ways: load balancers, web farms, etc.

As of version 4.5.x (I believe) DotNetNuke introduced support for SSL as a core feature of the framework. This functionality allows you to enable SSL on the site, which instantly cause all host and portal admin pages to be redirected to an HTTPS URL, and selectively individual pages on the site to be required to be viewed over HTTPS as well. By enabling SSL on DotNetNuke, and marking a given page as "Secured", DotNetNuke will no longer allow that page to be viewed over the unsecured HTTP URL. This presents a HUGE challenge when you've got what I refer to as an "intelligent" firewall/load balancer in between the web server hosting DotNetNuke and the end user's browser.

Let me explain... Every time a user browses to a new page on your DotNetNuke website, at least one (if not several) requests are made from the user's web browser to the web server. If the page is being viewed over an SSL link the user's request is encrypted by the user's web browser, and then decrypted by the web server. Next, the web site's response is encrypted by the web server, and then decrypted by the user's web browser when received. The conversation looks something like this:

(User's Web Browser) <--- Encrypted ---> (Web Server)

While the processing of a few of these requests would likely take less than a second, if you have a website with 10,000, 100,000 or even more hits a day, then the encryption/decryption process on the web server could amount to minutes or more of processing time. Granted a few minutes a day doesn't sound like a lot, but remember users require quick responses times so whatever that can be done to speed that up will make users happier. Somewhere along the way the firewall/load balancer companies realized that if they could offload the SSL encryption/decryption process from the web server, it will make the web servers more responsive. So when you put one of these "intelligent" devices in between the end user's browser and the web server, the conversation goes more like this:

(User's Web Browser) <--- Encrypted ---> (Firewall/Load Balancer) <--- Unencrypted ---> (Web Server)

The unencrypted traffic is not a problem, because it is assumed that the firewall/load balancer is on the same local network as the web server, so the chance of the data being captured and compromised is unlikely. This presents a HUGE problem for companies implementing DotNetNuke and enabling SSL and secured pages though. At the point you turn on SSL and secure a page, DotNetNuke will NOT let you view that page without HTTPS in the requested URL. If you try to view a given page over standard HTTP, it will perform a 302 redirect to the HTTPS URL, to which the end user's browser will respond by going to the HTTPS URL, which the firewall/load balancer strips and turns in to a HTTP request to the web server, to which the DotNetNuke site does a 302 redirect to the HTTPS URL...You get the idea...

As of this writing the only solution I know of (short of modifying core code in the DotNetNuke framework), is to NOT enable SSL and secured pages in DotNetNuke, and hard-code links to pages you'd like to have viewed over SSL with an HTTPS URL. This will allow the end-user to view the site using SSL, but allow the firewall/load balancer to perform requests to the web server over HTTP. I personally would like to see the DotNetNuke team make some modifications to the core framework that allows for the hardware environment I've described. An example would be them allowing you to mark a page as "secure" without enabling SSL for the whole site. This would tell the site that when you go to a given page to provide an HTTPS URL, but not require that page be viewed over SSL. I've submitted the described situation to their bug tracker, and have yet to receive a response. This will require some discussions on their part, and some thinking about the overall architecture of how to implement a proper solution to this situation.

So, if you are running into a similar situation on your DotNetNuke site (as of version 4.9.1, and 5.0.0), the only "easy" solution is the one I've described above. Hard code your links to secured pages to HTTPS, but don't enable SSL or secured pages on your site.

Upgrading DotNetNuke from 4.0.x to 4.9.1 or 5.0.0

bgswanson@purpleant.com — Wed, 14 Jan 2009 21:33:50 GMT

I recently went through an upgrade from a custom compiled DotNetNuke release 4.0.3. It was interesting to say the least, but I faced quite a few challenges. All of which would have been so much easier if I just thought about what I was doing instead of blindly following someone else's guide for the upgrade.

Keep in mind for minor revisions where you are only upgrading to a release that is a couple revisions newer the upgrade process SHOULD be fairly straight-forward. In the past, when upgrade from 4.7.x, or 4.8.x to version 4.9.x it was as simple as unzipping the upgrade package and copying the contents into your website folder overwriting whatever files already exist. Since this was a major jump in revisions, I assumed at least some things had changed significantly enough that I'd do a search on the Internet for a guide on the upgrade. I couldn't find anything to go from 4.0.x to 4.9, but I did run across Mitchell Seller's guide to upgrade to 4.5.x. Following the steps in his guide, I tried to upgrade to 4.9.1, but kept getting some strange issues and errors along the way. Sometimes the "upgrade" process would install a completely new instance of DotNetNuke. Other times, the upgrade process would fail with an "Object Reference not set to an instance of an object" error, sometimes in the Membership Provider, sometimes in the GetHostSettings routines.

Here are the steps I've gone through to finally get the upgrade to successfully complete...Of course props to Mitchell and his guide, but one of his final steps glosses over the areas where I had issues, so I thought I'd write my own upgrade guide adding some of the specific steps on which I had issues

Backups

First and foremost, make sure you have a GOOD BACKUP of both the database and your website folder. During this site upgrade, I restored both the site folders and the database probably 50+ times. So I can't stress this enough. Even if the upgrade does successfully complete, you might that the release of DotNetNuke that you are upgrading to has incompatibility issues with some of the modules that you have installed on your site. Also, if you have any custom files in the site that DotNetNuke provides with their installation/upgrade packages (favicon.ico), you'll need the backup folder for a copy of those files to restore to the site folder.

Taking the Site Offline

If you have a site that has any significant traffic, then it will be important to let your users know what is happening during the upgrade process. Since the release of 4.0.x, DotNetNuke has been targeted to version 2.0 of the .Net framework. One of the neat features that came about in ASP.NET 2.0 (part of the .Net v2.0 framework) is the ability to place the "app_offline.htm" file in the root of the website folder. If this file exists, ASP.NET will automatically display this to user's trying to access the site. It provides a friendly and easy way to display a maintenance page to your users. When the upgrade process is completed, all you have to do is remove the app_offline.htm file from the website's folder, and your site will be live again for users.

Keep in mind, you do not have to make any changes in IIS to have the site start showing the app_offline.htm file, it will automatically start displaying if it exists. As noted in Scott Guthrie's article above (app_offline.htm link), you should also ensure the file size of the app_offline.htm is over 512 bytes, or Internet Explorer will display a "friendly error" instead of your maintenance page.

Updating your web.config

If you are not logged in locally to the server (like a shared hosting environment), you will likely need to do the following steps on your local PC, and only upload the modified web.config.

Because of changes that might have occurred (or in my case, DEFINITELY have occurred) in the web.config, it is recommended to rename your existing web.config to something like web.config.old, and then rename release.config to web.config. Load both files up in your text/XML editor of choice as we'll be copying items from the web.config.old to the new web.config file.

Look for the section, and copy the active "SiteSqlServer" connection string from the old file to the new. If you aren't 100% sure which one is active, you could copy over the entire section from the old file to the new file. You will also need to look for the legacy connection string in the section of the web.config file and ensure it is updated from your old file.

It is recommended (especially if you opted not to use the app_offline.htm file), that you update the key "AutoUpgrade" to "false", to ensure that you start the upgrade process (and thus see any output from it), instead of one of your users.

The last Item in the section of the web.config to remember to copy over is the "InstallationDate" key. I'm not 100% sure what this is used for, but I'd copy it over just to make sure, since DotNetNuke created the key.

In the section of the web.config, you'll find a element that contains a ValidationKey and a DecryptionKey. Copying over this line(s) from your old web.config is VERY important, as this is used for encrypting and decrypting passwords (and other information) in the database. If you forget this step, when your upgrade is complete and you try to login to the site, you will get an invalid password response from DotNetNuke. It can be corrected by updating these values in the web.config from the old web.config file.

Locate the element next, and if any modules have added a folder, you'll need to copy them over to the new web.config. By default the web.config has the section commented out, so you'll need to copy the start and end tags for the section, or uncomment them.

When I was doing my upgrade, I ran a file comparison utility and noticed the default MembershipProvider had changed some time between 4.0.x and 4.9.x (and 5.0.x). Initially I was copying over from my old config the entire section of the old config, as I was (incorrectly) assuming that the change in MembershipProvider would keep me from logging into the site after the upgrade. While the change didn't seem to affect the final outcome of the upgrade, it appears that the DotNetNuke team successfully migrated from one default provider to the other without breaking anything. So I'd recommend leaving these settings AS IS in the new web.config.

Finally you should check the remainder of the config file for custom settings, especially the config sections that contain provider information and settings for those providers. The main mistake I was making during my upgrade process, and what resulted in a new instance of DotNetNuke being installed (instead of an upgrade of the existing instance), was not looking at the provider section under . In my case, the line was too long to be viewed on my screen, and since I never scrolled over to look at all the settings, I didn't notice that an "objectQualifier" had been specified for the SQLDataProvider. It is key that both the "objectQualifier" and the "databaseOwner" attributes match up between your new web.config and your old one.

Removing old DLLs

I'm not exactly sure when the changes in the DLLs being distributed with DotNetNuke occurred, but at some point around 4.5.x several of the core DLLs were consolidated, and other DLL changes occurred as well. The challenge with this is that ASP.NET wants to analyze (Reflect) over each of the DLLs and the older DLLs even though not being used anymore will cause ambiguous references, or other issues. In my website's bin folder I had 20-30 DLLs that matched DotNetNuke.*.dll. Unfortunately some of those are core modules developed by the DotNetNuke team, but not affected by the DotNetNuke framework upgrade. So, I ended up deleting all DotNetNuke.*.dll files that were not DotNetNuke.Module.*.dll, and then re-copying in from the upgrade package all DLLs from the bin folder.

Doing the ACTUAL upgrade

At this point you are ready to open a web browser and go to (your URL)/Install/Install.aspx?mode=upgrade.

If all goes well you should see "Upgrading DotNetNuke", followed by the "Current Assembly Version", "Current Database Version", and several other items. If the process completes successfully at the bottom of the page you should see "Upgrade Complete" followed by a link that says "Click Here to Access Your Portal". Follow the link, and browse the site both as an anonymous user, and as a logged in user and admin. Ensure that everything is working as expected. You'll need to remove the app_offline.htm file to bring the site back online.

BACKUPS BACKUPS BACKUPS

I figured it was worth mentioning again that you are STRONGLY ENCOURAGED to do both a website folder backup as well as a database back before attempting any of these steps. It'll be well worth the trouble if anything goes wrong than trying to have to re-build the site from scratch because of a failed upgrade.

Known Errors and possible solutions

Server Error in '/' Application.

--------------------------------------------------------------------------------
Runtime Error
Description: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed remotely (for security reasons). It could, however, be viewed by browsers running on the local server machine.

First and foremost change the element to "mode=off" in your web.config, restore your original website folder and database, and start over. Hopefully you'll get better information about what actually went wrong. Just remember to change the element back to "mode=RemoteOnly" afterwards. No sense in making your site users see the Yellow Screen of Death.
Check for errors in your copying of elements from one web.config file to another. Small errors like missing a closing tag could cause the whole file to appear invalid to ASP.Net.

Object reference not set to an instance of an Object

I saw several variations on this error, but all ultimately ended up being a result of incorrectly copied, or lack of being copied settings from the old web.config. Double check to ensure you don't have some custom setting information somewhere that hasn't been copied over to the new config.

SqlDataProvider Error! (see x.x.x.log for more information)

The best advice I can give on errors like this are check the site's functionality, and if all appears to be working OK, then you probably shouldn't worry about it. It's difficult at best for the DotNetNuke team to make sure that all of their SQL scripts are 100% compatible with all previous versions of the DotNetNuke schema.

I hope this guide helps. I wouldn't wish the hair-pulling frustration that I experienced during my upgrade from 4.0.3 on anyone. If I can be of any help, please don't hesitate to contact me, or post a comment below.

Speaking at the Memphis .Net User's Group meeting this month

bgswanson@purpleant.com — Tue, 13 Jan 2009 02:58:33 GMT

I've participated in the local Memphis .Net User's Group on and off for the past couple of years...More off than on to be completely honest. I always have the best of intentions of going to the meetings, but then something comes up and I don't end up making it. Last month I made a concerted effort to attend as I had contacted the current president of the group, Colin Neller, about running a food drive for the Memphis/Mid-South Food Bank, an idea that came from Steve Andrews and GeekFoodDrive.com. During the break at the meeting last month, I introduced myself to Collin, and we discussed a few things about the food drive and potentially starting a "geek lunch" in the Memphis area.

After the meeting, I started thinking more and more about the User's Group, and how I could contribute to it. If you don't know me very well, let me go ahead and tell you that I am EXTREMELY shy, unless we are talking about a subject I am confident about. For the past 18 months I have lived and breathed DotNetNuke in the projects I have worked on for clients (I've tried half-heartedly to start a DotNetNuke User's Group in the Memphis Area). So, I began convincing myself that I could give a presentation on DotNetNuke to the group. Well lo and behold if Colin didn't contact me right around New Years and ask me if I wanted to present to the group. He didn't specify the topic, but just asked if I was interested and wanted too. We went back and forth via Twitter a few times, but I finally agreed to do the presentation at the January 22nd meeting for the group.

I am honestly nervous as hell about this, but know that I am capable of doing a good job on the presentation. Colin has tried to ease my anxiety by letting me know that January is usually a "light" month for attendance, so it'll be a good time for me to get my feet wet, but that hasn't really helped me much.

The topic we agreed on? An Introduction to DotNetNuke, and enhancements in version 5. The following is the summary for the discussion:

DotNetNuke is an open-source Web Application Framework/Content Management System idea for creating and deploying projects such as commercial web sites, corporate intranets and extranets, online publishing portals, and custom vertical applications. As the leading open source web application framework based on Microsoft ASP.NET (VB.Net) platform, it has been downloaded and installed hundreds of thousands of times. In this presentation, we will go through the basic features and functionality of DotNetNuke, and then discuss the enhancements in the recent release of version 5.0.

So if you don't have anything to do, and are interested in hearing about DotNetNuke, and the latest release, come on out on January 22nd...But please, try not to laugh and point too much during the presentation...

Budget Workbook for Windows v1.1.5 Released

bgswanson@purpleant.com — Tue, 04 Nov 2008 12:30:00 GMT

Snowmint Creative Solutions has released version 1.1.5 of their expense tracking software Budget Workbook.

This release REALLY fixes a minor bug found in the previous version that kept the preferences file from being saved. Ah the joys of different operation systems and their nuances...

Purple Ant is responsible for creating the Windows versions of several of Snowmint Creative Solution's products.