Upgrade DotNetNuke from DNN 3.x to 4.x
With the advancing technology and more and more developers switching to ASP.NET 2.0, the technology using ASP.NET 1.0 with DotNetNuke 3.1 is rapidly getting old. So upgrading is the right decision for today.
Moreover a lot of functionality is added to DotNetNuke 4 version. To take advantage of these features one must upgrade to 4x version.
The latest version 4 of DotNetNuke comes with the following functionality:
- Provider Abstraction - create our own provider to abstract ourselves from the Microsoft provider
- HttpContext- eliminate dependence on HttpContext
- ApplicationName - manage our multi-portal capabilities within DNN rather than trying to hack the Microsoft provider
- Question and Answer - the ability for a user to enter and store a private question and answer, which can be used for a password reminder.
- Hashed Passwords - hashed passwords are supported through the Microsoft Membership Provider. We should provide a mechanism to support hashed password in DNN as they are much more secure then encrypted passwords and do not rely on Machine Keys. (It would be advantageous to make this the default but the side effect would be that we would no longer have a password retrieval mechanism)
- CAPTCHA - add the ability to display a small image with embedded text, which bots cannot read. Prevents brute force dictionary login attacks.
- Public Registration - the system should send an email to the user on public registration (to prevent cases where another user registers with their email address).
- Profile Change Notification - when any profile attribute is changed, the owner of the account should be notified (using the original email address). This is to alert people in the event that an unauthorized user has gained access to their account and made changes to their profile (password, email).
- Login Redirect - after login there should b a way to send a user to a specific page. This could be implemented at the portal or user level.
- Password Generation - the ability for an admin to automatically generate a secure password for a user on account creation
- User Account Creation Notification - when an admin creates a user account they should have an option to send the account details to the user
- Force Profile Update - ability to force a user to update their user profile (implemented at a granular level based on required Profile fields)
- Force Password Change - ability to force a user to change their password
- Password Complexity - add the ability to define some password complexity requirements (i.e. mixed upper/lower case, numeric and alpha-numeric, etc.. )
- Password Length - increase the default minimum password length from 4 characters (will require a more secure host password on initial install)
- Password Expiry - a mechanism for expiring a password, which would force a user to enter a new password. This could be done through password aging parameters defined at the portal level (i.e. every 2 months).
- Display Name Field - the membership schema should store the DisplayName of the user for demographic purposes - this item is critical for international users where their name is not represented as "FirstName LastName". Modules should link to the DisplayName for audit purposes rather than using FirstName and LastName.
- Preserve Login Parameters - when a user is directed to the login screen, the system needs to retain the original url (with parameters) so that it can redirect back after successful login (especially useful in nested module UIs like Forum)
- Logout Behavior - after logging out, the user should be able to remain on the same page rather than being redirected to the home page
- Login Redirect - after login there should b a way to send a user to a specific page. This could be implemented at the portal or user level.
- Password Generation - the ability for an admin to automatically generate a secure password for a user on account creation
- User Account Creation Notification - when an admin creates a user account they should have an option to send the account details to the user
- Force Profile Update - ability to force a user to update their user profile (implemented at a (the only reason they are being redirected now is because they may no longer have access to the page because of roles - but this is largely unnecessary and can be handled other ways).
- Automated Verified Registration URL - the email sent to user when using he Verified Registration process now contain a URL which a user can click to very quickly validate their account
There are various ways to move from 3x to 4x depending upon your database, site requirements etc. For example:
Suppose you have to transfer sites from one
hosting provider to another and upgrading at the same time to DNN4 from DNN3.
All you have to do is:
- Back up your database and content
- Set your site to run under ASP.NET 2.0
- Unzip DNN4 on top of your current site
Suppose you have a large DNN installation and you are moving
everything from DNN 3x to 4x. First of all you need to get DNN database from the local SQL Server 2000 to remote SQL Server 2005 then...
- Go to DNS and create a new sub domain called dev.somedomainname.com and pointed it to the development server IP address.
- Copy the entire DNN directory on the production server to the development server.
- Reset permissions on the dev server for the DNN folder. You can copy from production to allow Network Service full permission
- Create a new website on Dev in IIS and setup a host header for the new sub domain and for localhost, pointing it to the DNN folder copied from Production.
- Detach the production DNN database form the SQL Server 2000 instance.
- Copy the MDF and LDF files for the DNN database from \mssql\MSSQL\Data on Prod and moved them to \Microsoft SQL Server\MSSQL.1\MSSQL\Data on Dev.
- Attach the database copied from Production using SQL Server Management Studio. Part of this process automatically upgrades database to from 2000 to 2005.
- Open web.config and changed the server name, username, and password for the remote SQL Server
- Open up a browser on the Dev server and went to http://dev.somedomainname.com and confirmed site was assessable.
A foolproof and efficient way to migrate from DotNetNuke version 3 to DotNetNuke version 4 has following steps:- Create a new application pool and call it DNN4.
- Create a new site in IIS and call it DNN4. Set the site to use ASP.Net 2.0 and make sure it runs the application pool you just created. This is very important because you cannot run .Net 1.1 and .Net 2.0 in the same application pool.
- Download the install package for DNN 4.0
- Unzip the package into the folder where you want your site should be (same folder as you set in IIS when you created the DDN4 site)
- Create a new database and call it DNN4.
- Assign the same admin as database owner as you use in the production site.
- Rename the release.config to web.config and edit the connection strings so that they point to your SQL server and database. Do not point the connection strings to your production database.
- If you have done this locally browse to your site at http://localhost/.
- If everything is OK the install routine will start and a blank new DNN 4.0 site is created.
- Install all modules you use on your production site and be sure to check the version. Also check if the module is made to run for DNN 4.0. In the case of Active Forums you need to install the DNN 4.0 version. You can create a little Excel sheet with all the modules on the production site and check all versions.
- Now we have a blank DNN 4.0 site that should run without any errors.
The next steps are for copying data from your production database to another new database in SQL. Here we go:- In SQL create a database with the name DNN4Beta.
- Assign the same admin as db owner as you use in the production site.
- And now something VERY important comes. You must match the machineKey validationKey and the decryptionKey to the values from the production site web.config. If you fail to do this you will not be able to logon to your site anymore. If you make this mistake on your production site you will need to restore your database.
- Change the connection strings so that they point to your SQL server and database. In this case the database name will be DDN4Beta.
- Now we need to import data from the production database into DDN4Beta. Use SQL Server Manager for this.
- Copy all data from the production Portals folder to the DNN4 Portals folder.
- Browse to http://localhost/ . You will see that DNN will upgrade your database to version 4.x
原文地址：
http://www.datasprings.com/Resources/ArticlesInformation/UpgradeDotNetNuke3xto4x/tabid/738/Default.aspx
