I've been trying to upgrade DNN version 4.09.05 to 5.0.0. and higher but I always encounter errors in upgrading. Each version presents different errors. I really need help.
Due to the vagueness of your posting, we aren't going to be able to help you much except point you to the Wiki for upgrade scenarios
http://www.dotnetnuke.com/Resources/Wiki/Page/Upgrading-DotNetNuke.aspx
First things first, you should just attempt to upgrade from 4.9.5 to the latest 6.1.1 release, see if that works (after backing everything up)
Related
After Upgrading successfully by transferring upgrade zip file and completing upgrade wizard process after host login, Error HTTP 503 came up when I clicked on "Visit Website" button. After going through Log files below error log was found
DotNetNuke.Services.Exceptions.Exceptions - System.IndexOutOfRangeException: TermsTabId
at System.Data.ProviderBase.FieldNameLookup.GetOrdinal(String fieldName)
at System.Data.SqlClient.SqlDataReader.GetOrdinal(String name)
at System.Data.SqlClient.SqlDataReader.get_Item(String name)
at DotNetNuke.Entities.Portals.PortalInfo.Fill(IDataReader dr)
at DotNetNuke.Common.Utilities.CBO.FillObjectFromReader(Object objObject, IDataReader dr)
Issue happened at Live site
Going from DNN 9.1.1 to 9.3.2 (and maybe beyond that) requires some careful attention to detail. In that series of releases, there are some important breaking changes, most of them related to the removal of APIs that have been deprecated since DNN 7. Most of these issues can be solved by making sure that any modules you have added to the basic DNN Platform have been update prior to doing the upgrades. Essentially, you'll want to make sure that your modules (and possibly skins) are compatible with the DNN version to which you are upgrading.
Read the release notes for all of the intermediate releases, especially 9.3.1 and 9.3.2. There are some important breaking changes to DNN.
Also read the notes at the bottom of https://dnndocs.com/content/getting-started/setup/upgrades/suggested-upgrade-path/index.html
Before doing the upgrade, you should identify any modules that need to be upgraded because of breaking changes and removal of deprecated APIs.
If you need additional help with this, I'd recommended visiting the forums at dnncommunity.org and asking questions there. Among other things, you may find that the community of people who can help is larger over there.
I want some suggestions about web-application versioning system.
Currently I use SVN commit number as version number of the application. So if the commit number is around 596 then I call it version 5.96
What is the most used approach for keeping a transparent versioning system of web application?
Check out 'semantic versioning'
It's a pretty popular standard these days.
Essentially version numbers consist of three numbers
major.minor.patch
major version is only updated any time you are doing a major release which has 'breaking' changes in it (essentially 3rd party integrating with your site will need to adjust their code for it to work with yours again)
minor version is updated when you are adding non-breaking changes
patch version is updated when you check in any small changes/bug fixes.
If the major version gets reset then the other two go back to zero. So you might be at 3.1.17 and when you move to 4 it becomes 4.0.0 then you might do a small bug fix so it goes to 4.0.1 the you might add a small feature and it goes to 4.1.0 and another bug fix so it goes and another bug fix so it goes to 4.1.1 and another feature so it changes to 4.2.0 etc.
My explanation isn't perfect so go look it up. It's a pretty sensible versioning system and allows anyone using your library / integrating with you to instantly know whether or not to expect breaking changes, new functionality or bug fixes.
Since I've not done this before I am not sure if the way I am planning to do this is okay or is there a better way. Like using Windows Installer or Install Shield or Windows Installer XML (WiX) toolset. Any help would be great, as I have no clue.
We have a product and we ship new version every few months. So far we've only been rolling out complete versions i.e. Either Version 1.0, or Version 1.5, but no upgrade from 1.0 to 1.2 to 1.3 to .... you get the picture, right! So any customer that get version 1.0 cannot upgrade to version 1.2 or 1.3 or even the latest. They'll have to uninstall old version and install the latest version. This is not right, but thats what we could do until now. But we'd like to change it.
My plan is to have a install file with (Sql Scripts) for each upgrade path. Check the table in database that stores the version info and depending on it run different script to upgrade database.
My concern is that this method may not be scalable, once we have more than 5 or 6 different versions.
If you could point to any articles or books on this topic, that would help a lot too.
Also, could we use Windows Installer or Install Shield for this?
thanks,
_UB
We've been using DBGhost for a year or so now to keep our database under source control along with our codebase, and it makes this kind of thing dead easy. It's not just well thought through, but they've been using it to roll out their own code for years, so it's dead solid.
Your problem is a pretty common one, and I've had to deal with this kind of problem at my last job. There is another tool aside from the RedGate tool that may help you do what you need to do. It's a tool called DB Ghost. They explicitly address the versioning problem, and have a packager as well. I would suggest doing a trial of the DB Ghost product because they have some interesting claims concerning multiple version upgrades. This was taken from their FAQ (http://www.innovartis.co.uk/faqs/faqs.aspx):
Q: Our problem is going to be managing
data structure changes during
upgrades. Our product line is
Shrink-Wrapped, or downloadable from
the website. So when a user downloads
an upgrade, they can be upgrading from
a very recent version, with few
database structure changes, or the
upgrade may be from a very old version
with a multitude of structural
changes. One upgrade needs to manage
it all. The user would be offsite, so
we can't hold their hand. We have
users in Greece, Australia, Malaysia,
Norway, etc. How would DB Ghost, if at
all, handle updates in remote
locations?
A: The DB Ghost Packager Plus product was
design to specifically address this
issue as it can dynamically handle the
required updates to a target database
seamlessly.
I'm just mentioning this because our company is trying to do something similar and I was doing research on this tool.
Thanks,
Eric
Do you insist on doing it yourself, or could you see yourself committing and investing in a tool?
I really like the idea of Red-Gate's SQL Packager, which will "diff" your two database versions, and then create a SQL script, a C# project, or a stand-alone executable to upgrade from version 1 to version 2.
Not 100% how you'd be able to upgrade from 1.0, 1.1, 1.2, 1.3 all to 2.0 - check out their website and see if they offer something for that scenario!
Otherwise, I guess it'll get quite thorny and messy......
Marc
In the Rails world they are using a tool/method called Migrations.
Basically is boils down to creating a small sql script to upgrade and downgrade each little change to the database.
When you are testing the application you migrate your database to the version you want and on deployment the application can check what version it needs and migrate to that version.
There are free migration toolkits for most popular languages, they might be part of some MVC framework though.
A nice side effect of migrations is that you have database source code that is easily stored in you source control repository.
We are in the process of migrating our bug tracking to Bugzilla from a really old version of track and I am running out of Advil.
We have a legacy application that has been around for a long time. Mix in the fact that our versioning management has been through a few iterations it generated a lot of different versions in the wild. To make matters worse, because of contractual limitations it is not always possible to upgrade the clients to the latest and greatest, so we must branch, fix, test and release, on the version they currently have, yielding yet another version number.
The end result is that the version combo box is ludicrously long. Lastly, for various reasons, we want to track three different version information :
the version in which the bug was found (version), the version in which we plan to fix (milestone) the bug and the version in which it has ultimately been fixed (open to suggestions). here is my problem in fact... this can actually be multiple numbers where we did a retroactive fix for some of these customers (this happens VERY often).
This is where I need your collective wisdom :
How do you keep track of these versions (found, planned and multiple fixed) in Bugzilla?
What are the best practices around linking versions and bug tracking ?
Answers
It seems that cloning the bug for each version is a good way to track, thus the target version is always tracked in the milestone as well as the fixed version, and the buggy version is always the native version.
Also to have each clone block the original bug make it a good way to trace the history back to the original submission.
Although I have accepted the answer I still welcome your input.
Often, if we need to fix something in multiple released versions (generally branches in the source code repository), the bug will be cloned for each branch so that all the commits and release status can be tracked separately. I think the only time we don't do this is when the change is not directly related to the codebase itself and cannot be fixed simply by updating our libraries.
As for version tracking in general, this has struck me as a reasonable way to do things, given that we generally only need to support 2-3 major versions (plus the trunk) at any time. If you have multiple disjoint versions that need supporting, e.g. customer-specific deployments, then things are going to be harder to track. (Arguably this is going to cause headaches in general and it would be better to unify things to a more central version theme).
I use Bugzilla to keep track not only of bugs, but also of new features, enhancements, and vague ideas. For each planned and released version, I have a Tracking Bug (something that I saw on the original Mozilla bugzilla, and found to be useful).
So if you have a bug report, you enter the bug with the version number that it was reported. Create additional bugs (one for each version you plan to fix it in) which all depend on (block) the original bug and block the version-specific Tracking Bugs.
If all bugs blocking the original bug are closed/verified (whatever your QA implements), you can also close the original bug.
I was looking for a similar feature in TFS, and while doing some investigation, I found that there is an enhancement request to manage "sightings" in Bugzilla:
"Bug 55970 - (bz-branch) Bugzilla needs to deal better with branches (implement sightings)":
https://bugzilla.mozilla.org/show_bug.cgi?id=55970
There is also a proposed design:
https://bug55970.bugzilla.mozilla.org/attachment.cgi?id=546912
For information, we are going to implement something similar in TFS 2010, with a "Bug Parent" or "Bug Master" to hold the information about the bug itself (repro steps, severity, technical info, impacted components...), that can have child of type "Bug Child" or "Sighting" that will hold the information specific to a given branch (target milestone, priority, specific information for that branch...).
We are using jira and still have this problem. I think it is a question of requirements and how are versions used rather than any one tool.
Who uses versions and how do they use them?
How are versions related to milestones in a project plan?
We use a 4 dectet version (major.minor.patch.buildNO). buildNo is the SVN head revision # at time of build. Each version is stored in JIRA and issues have an affects version and fixed-in version field that's a multi select.
After a short while we have many versions. Jira does allow us to control the list in two ways
1. Archive versions (greyed out from pick list)
2. Merge versions (rolls several versions together into a new version - no undo)
We have used Archive, but have avoided Merge due to the lack of the undo. So we still have a list of many many versions.
I'm sure you could probably accomplish a merge action in Bugzilla with some scripting and time, the question is: when is it OK to merge several older versions together?
If I have released, do I need to know that I have 17 builds between start and release? Do I need to keep the knowledge of a bug being found in build 1, fixed in 2, found again in 7, fixed again 9? Or is Found in release 1.0.0 fixed in release 1.0.1 good enough?
i'm going to ask a large question on this topic later on today, but I know the basic answer already:
- Depends on how your team wants to track things.
Implementation is fun, but it all comes down to requirements, goals and working back from user experience to solution. Which is rough when people don't necessarily know how that want to use something that doesn't quite exist in the form they'd like to use.
I have created a custom field (string) to list to version(s) (as V.M.P.B) where a bug has been fixed.
I have created also another custom field (string) to list to version(s) affected by a bug.
Doing that you are able to perform quick-search on specific version.
I need to upgrade my current version of DNN this week. I am currently using 2.1.1. I don't want to do everything twice, so, I have several questions.
Is there an upgrade tool or some scripts somewhere that will help me to do an upgrade.
Am I better off installing 4.9 or 5.0. It is production.
If I go with 4.9, will I be able to upgrade to 5.0 when it releases?
I personally strongly disagree with ALassek, you can upgrade DotNetNuke, you just have to follow the steps listed and as long as you do that it isn't a big deal at all, but there are a few key things to keep in mind as you set down the road to do your migration.
DO NOT USE 5.0 in production at this time. 5.0 is only in RC2 stage at this time and using it in production is NOT recommended and an upgrade path from RC2 -> Final might not be possible!
If you plan on trying to upgrade from 2.1.1 go from it to the most current version of 2, then go to 3, then go to 3.3.7, then go to 4.4.1, then to 4.6.2, then to 4.9.0. Typically you are able to make it, but some sites are not.
Some modules though will need to be updated to work with DNN 4.x, depending on the numbers and vendors this can be an easy process or can involve needing to find other providers for the specific functionality at hand.
As for the potential to upgrade to 5.0 from 4.9, yes, that will be 100% supported once 5.0 is in a production ready state.
It's been my experience that DotNetNuke has a tendancy to release breaking changes without documenting them (or documenting much of anything, for that matter). Without knowing exactly what you have installed in it, it's impossible to say exactly how screwed you are. But I can guarantee you the transition will likely not be easy, especially if you have a lot of modules installed.
Between 2.1.1 => 4.9, so much has changed that I can't imagine there is any automated way to upgrade. You're better off starting from scratch and seeing what still works. Most likely you will need to find newer versions of any modules you're using, or replacements for those that aren't being kept current.
To be honest, I don't know. But I see that the DNN download page very strongly states that the 5.0 release-candidates are "NOT RECOMMENDED FOR PRODUCTION USE".
There was a huge amount of breaking changes between 2x and 3x which will cause pretty much any custom modules you have to have to be upgraded or replaced. Other than that Mitchel is the DNN man and I would defer to him.