I have a build of DotNetNuke 4.8.2, which has some extensive customizations to the DNN codebase made to it.  More and more, my customers are looking into DNN itself and requesting that DNN get updated to the latest version, for both security and functional purposes.  Because of the customizations, it's not a matter of simply installing a newer version over the current because I would obviously lose any customizations I make.

I recently took my customized 4.8.2 code, and did a 3-way merge (using KDiff) with the 4.9.5 source and original 4.8.2 source.  While it was by no means trivial (it took a few days to get everything in place and working), I was able to successfully upgrade the system to 4.9.5 while leaving my customizations intact.

Looking at 5.x, however, it doesn't seem that this solution will work out too well - it seems that a large number of files and folders have changed places (I'm assuming this is due to the change from "modules" to "extensions"), and it's not something that a simple 3-way merge could easily handle.

Right now each client site we host resides in its own installation of DNN, which is a TFS branch of a central DNN codebase project - that way any changes made in the TFS codebase project can easily be merged into the client sites and propagated out to our servers. 

My current plan is to:

1. Start a new 5.x codebase from scratch, and manually redo all of the customizations over again
2. Migrate sites to that codebase manually on an as-needed basis (that is, physically bring over any skins, custom modules, and content to a brand new branch of the new codebase)
3. For future DNN updates, subscribe to the Codeplex server's RSS feed and manually apply the code changes as they come along (this should be manageable, as code changes only seem to come along a couple times a week).

So my questions:

• Is this plan realistic or good in any way, shape, or form?
• What best practices or suggestions do you guys have to making modifications to the DNN source while still keeping your site upgradable to later DNN versions?
• Is there a cleaner way to upgrade a customized 4.x install to 5.x rather than redo all my changes (as I'm planning to at this point?)
• Is there a simple way to automate (or at least simplify) the patches in change 3?  Obviously something that completely automates and merges in new changesets from the Codeplex server to my branch is unrealistic, but maybe something that would actually let me merge in code from Codeplex itself instead of just manually going through each file and copy-pasting in changes/

 

Most of the changes are to admin pages and not to the framework itself; they're mostly small usability enhancements made to the pages themselves with a few lines of codebehind added, though there is some changed code for bugfixes (some of which are probably not needed anymore), as well as some pages changed more significantly.  Since (at least in 4.x; not sure about 5.x) admin pages weren't really modular or easily installable the changes were made to the source code of the admin module itself.

In addition, some of the user controls (for example, the Breadcrumb control) had some properties added and implemented to expose more functionality to the skinner.

Offhand, I can only think of one or two changes made to the framework itself, and they're both small changes.  I try to avoid making changes to the actual DotNetNuke.Library code unless absolutely necessary.  However, a few changes I have in mind would potentially require changes to that as well.  For example, a common request I'm getting is for getting certain domains to point to a subsection of the site, without redirecting, in situations where adding additional portals is either not an option or just overkill.

I am guessing you don't have a document of the changes but hopefully you at least have some code comments (or maybe you did it). With/without knowing what was originally changed, you may want to test what exists today in a new install to see if some of the changes are not necessary. 

Now, to move onto your other comments. You may have to merge/diff or beyond compare a couple of these to identify a pattern. Maybe it was just location of some of this (I honestly can't remember what changed between these core versions besides the admin modules becoming independent of the core which Sebastian mentioned) You could review release notes since the last core changes were made (potentially blogs/gemini here too) or maybe do all of the above. 

As for the skin objects, I would put these under different names and update the skins for them (if you are using HTML skinning or ascx skinning, this should be a simple find/replace for path and namespace/name). You basically just create a new namespace and manifest installer (dnn file) and potentially a project (you could add data changes here too, if you were doing this before). You could create your own sub-folder (MyCompany) under admin/Skins/. If the changes are mostly UI, this should be simple enough to maintain under a new namespace manually (since I don't see the location of this changing and don't believe it has)

About the redirection, you can use url-rewriting but it does add overhead to the application. You can satisfy SEO requirements with this as well. One of the ones available today is pretty good here and can be helpful (and thus offloaded as a change, for a nominal fee). For the record, the core is already doing some re-writing of its own and you could configure it for some, if not all, of this (or update it on your own, as a new provider if it doesn't meet your requirements). 

---

Chris Paterra

Get direct answers to your questions in the Community Exchange.