Migrating DotNetNuke From Development to Remote Production 

Recently I have been answering a large number of questions regarding the processes to deploy an existing development site from localhost to a remote hosting provider.  Typically this has been something that I was not willing to publish a tutorial on due to the complex nature of the matter and the major differences between hosting providers.  However, due to popular demand this article will be my first documentation of the end to end process to move a localhost DotNetNuke installation to a production environment on shared hosting.  I will be basing this article on the proceses that are needed to deploy to 3Essentials which is my hosting provider of choice, the process is similar for other hosts, but there may be charges or other complications introduced. 

Assumptions/Preface

Prior to starting the step-by-step process of migration I want to lay out the assumptions that are being made PRIOR to starting this process.  First and foremost you have a local installation of DotNetNuke installed on you machine.  This article assumes that you followed the process I set forth in my "Installing DotNetNuke 4.8.2 Locally" which used a SQL Server specific database and did not utilize the dynamic attachment feature.  If you used dynamic attachment or are using SQL Server 2000 your process will be different for the database preparation steps below.  Additionally prior to starting this deployment it is expected that you have a hosting account established with a hosting provider that supports ASP.NET 2.0, SQL Server 2005, and already have a domain name pointing to the account.  These setup/prerequisites are required to ensure a smooth transition from development to production.

This tutorial will be divided into multiple sections starting with DotNetNuke Preparation, Hosting Provider Preparation, DotNetNuke Migration, and wrapping up with Testing.  This will take you step by step through the process and will complete the tasks in an order to minimize the time to deploy and to minimize complication/confusion for those new to this process.

DotNetNuke Preparation

This step is one of the most commonly overlooked portions of the development to production process.  DotNetNuke uses portal aliases to determine which portal is associated with each respective incoming URL.  If a DNN site is moved to a new URL and a portal alias doesn't exist for the URL problems will be encountered.  Although possible to configure later, it is strongly advised to complete the portal alias addition prior to deployment as it makes the process that much smoother.  To add a portal alias you must login as the host user and then navigate to "Admin" -> "Site Settings".  On this page scroll to the bottom until you see this section.

Http Alias Listing

You will then click on the 'Add HTTP Alias' link to add an alias. Simply input the production URL in the textbox and click 'Add New Alias'

Add HTTP Alias

  be sure to enter just the domain name and no trailing forward slash as that will cause issues after the site is moved.  So for a site hosted on mysite.com the alias is simply mysite.com. Once yoou have completed this step you are now ready to prepare the hosting environment to accept DotNetNuke.

Preparing the Hosting Environment

As I mentioned before this tutorial is based on deploying to 3Essentials other providers might require different steps, or might have different processes for deployment.  The only host that I know that can cause a very large problem is GoDaddy as they do not support root installations.  If you have any questions about this section and your hosting provider please post to the forums on this site and I will do what I can to point you in the right direction.

Preparing the hosting environment is a step that is very important as it ensures that you will have a properly configured site going foward and minimizes the chances of errors appearing later on in the process.  I have divided this section into 2 separate steps as you have two distinct operations that you must validate

Validate ASP.NET Permissions

When you completed your local installation you went through the process to ensure that the ASP.NET worker process had proper permissions to your DNN installation, well the same thing is needed when moving the site to a hosting provider.  In the case of 3Essentials to fully validate the permissions you will need to submit a support request to have them modify the root file permissions.  Other hosting providers might provide permission tools, however, if using one of those be sure that you can modify the root permissions as well.  With 3Essentials You can simply submit the following request to support, obviously replacing mysite.com with your domain name.

Support,
Please modify the root file permissions for mysite.com to ensure that the ASP.NET
Worker process has full permissions to all files/folders for my DNN Installation.

I have worked with their support team enough to know that this is more than enough for them to get things up and going.

Validate ASP.NET Version

Another item that you must validate when depoying to a remote hosting provider is that the proper ASP.NET version is enabled for your installation.  For DotNetNuke 4.x you will need version 2.0.50727, for prior versions you will need 1.1.  Most hosting providers including 3Essentials allow you to validate this setting in your site settings.  With 3Essentials 2.0.50727 is the default version.

Configure Blank Database

In the next step of the process we will migrate your existing database to the hosting provider, however, before we can do this a new clean database must be created.  You can do this via the Plesk control panel provided by 3Essentials.  Simply go in an create a database (It does not have to have the same name) and then additionally create a new database user.  When creating the database user please be sure to use a DIFFERENT username than the one that was used on your local installation, this helps to avoid issues with orphaned user accounts.  Once complete be sure to remember the database name, username, and password of the items you created we will need these in later steps.

If you have problems with this step of the instructions please refer to your hosting providers support process.

Migrating DotNetNuke

Now that all preparation steps are out of the way we can actuall perform the migration of DotNetNuke.  I recommend doing this this in a 3 phase process which will be outlined below as this will help you ensure that all processes have been handled successfully.  Before continuing please ensure that ALL above listed steps have been completed as if any are not complete you can encounter errors.

Backup and Migrate Database

The first step in moving your DotNetNuke site is to move the database from your local system to the hosting provider.  The easiest method to complete this is to simply complete a SQL Server backup and then FTP this to your provider for restoring.  I will now walk you though this process using SQL Server Management Studio (Express).  If you are working with SQL Server 2005 this process will be slightly different.

With SQL Server Management Studio (SSMS) open right click on your DotNetNuke Database, in our case it is TestDNN, from the menu that appears select "Backup.." from the "Tasks" menu item.

SSMS Backup Option

Now you will be presented with a backup window. In this window take note of the backup location listed in the "Destination" section, then click "Ok" to complete the backup procedure.

SSMS Backup Window

Once this has been completed you will want to take the .bak file that was created and FTP it to your hosting provider.  With 3Essentials I like to place files such as this inside the /private folder in the FTP area as these files are NOT available any other way than FTP.  Once you have FTP'ed the file to the hosting provider you can then submit the following request to them for support.  Please replace [BACKUPFILE], [NEWDATABASE], and [DOMAIN] with the proper values for your installation.

Support,

I have just uploaded a SQL Server database backup file to the /Private/[BACKUPFILE] folder on my
FTP location.  Can you please take this SQL Server backup file and overwrite the [NEWDATABASE] 
that currently exists for my domain [DOMAIN].  This will allow me to migrate my DNN site
to your server.  Please delete the .bak file upon successful restore

This completes the first portion of the migration. You may proceed to the next step while your hosting provider performs the database restore.  I have found that I typically receive response from my provider within a few hours.

Migrate DotNetNuke Files

This step is the most simple of all DNN migration steps.  Simply FTP all files from your local DNN installation to your hosting providers site..  With 3Essentials the /httpdocs/ folder is your webroot, just be sure when uploading files that you are placing them in the proper location.  If you have your local installation in a sub folder (localhost/dnn) or something similar you do NOT have to keep that setup, however, until you look at my "notes" section at the end of the article you might have a few issues if removing a sub folder.

When loading the files to your remote host, be 100% sure that all files transfer successfully.  FTP programs commonly will encounter copy errors with such large file copies as a DNN installation and will not notify you of errors.  Therefore I highly recommend copying files one folder at a time to ensure that you get all files up successfully.

Modify Web.config Settings

This is the final step of your DotNetNuke migration, validating/modifying your web.config settings to point to the new database.   You cannot complete this step until all above steps have been completed, as completing this prior to the restoring of the database will cause issues when you go to test the site out in the next step.

Using the information that you obtained when preparing the hosting environment you will want to update your web.config file to point to your hosting provider's database.  I personally recommend doing this in the following manner.  Download a copy of the web.config from your FTP location.  Then open this file in Visual Studio and modify the connection information.  Remember you have 2 connection strings to modify and you want to make sure that both are now pointing to the proper database server and database.  Once you have the file updated, simply re-upload the modified file.

Following this process you are able to keep your local installation intact and still migrate to production.  Please note that if you have any questions on the proper formatting of the connection strings or the items to modify, please refer to my installation guides as they provide detailed information regarding the the connection strings.

Testing the Migration

If you have made it this far you have now completed the migration of your site.  You will now want to validate that everything is still functioning properly.  If you moved from a location with a sub folder to a root installation please see the "Missing Images?" section below for information on how to quickly resolve issues with missing images inside Text/HTML module instances. Below I will walk through a few common "breaking" points when migrating, this isn't an all inclusive listing but should cover most of the key items that are common.

Images Not Appearing

If you find that you have images that are not appearing that have been linked inside Text/HTML module instances and you migrated from an installation inside of a sub directory to a root installation you will need to modify the image links.  If for example you had your development site at http://localhost/dnn and your production site at http://www.mysite.com your image links inside the Text/HTML module would have a path of /dnn/portals...  you need them to be /portals to work successfully inside your production system.

Luckily I have an easy solution to resolve this issue.  My Text/HTML Replacement Tool that is available on this site will give you exactly what you need to fix the links.  Using this tool you can match on the following (without quotes) "/dnn/" and replace it with (again without quotes) "/".  This will resolve all borken links for instances of the sub-folder dnn being prefixed to image paths.  After using this tool you must remember that you must flush the application cache by clicking "Restart application" to see the changes.

Repository Files Not Downloading

If you receive file not found errors, or simply do not get files on repository module instances you will need to update the file path to the physical file store which is stored inside the settings for each respository listing.  If you are unsure of the proper file path, you can build the path using the base path information available via the "Host Settings" section of your site.

Conclusion

In conclusion I hope that this article has helped you migrate your development site to a production environment with a remote hosting provider.  This is a first revision of this tutorial so please share any feedback or comments that you have on this process and I will continue to upgrade this document as I do with my other tutorials.  If you have technical questions with an migration that you have performed please make a post in my forum for assistance.

Posted by Mitchel on Monday, May 19, 2008
 

Comments

This is a great article.
See http://www.mitchelsellers.com/Forums/tabid/123/forumid/2/tpage/1/view/topic/postid/1001/Default.aspx for some possibly helpful info on SQL security, roles, permissions etc. for the database ID used for your DNN database...
Thank you, Tom

By tlyczko on Monday, May 19, 2008 at 12:29 PM

I appreciate the step by step. I found your tutorial easy to follow and do. The error I received has me very confused though. It seems to be something that is in the dnn app_code global.asax.vb code that is misfiring at the start of the app. Can you suggest a possible fix?


Compiler Error Message: BC30451: Name 'Config' is not declared.

Source Error:



Line 66: ''' -----------------------------------------------------------------------------
Line 67: Private Sub Application_Start(ByVal sender As Object, ByVal e As EventArgs)
Line 68: If Config.GetSetting("ServerName") = "" Then
Line 69: ServerName = Server.MachineName
Line 70: Else


Source File: E:\web\heartoftexa\htdocs\DotNetNuke\App_Code\Global.asax.vb Line: 68

By Darnell on Thursday, May 22, 2008 at 11:26 PM

I would validate that ALL files copied successfully.

Once you have done that if you still have errors, please make a post in my forum and we will help get you fixed up!

By mitchel.sellers@gmail.com on Friday, May 23, 2008 at 10:33 AM

Hey.
I just migrated my DNN 4.8.3 from one server to another using your tutorial, but when I enter the new server's address, I get redirected to http://.../Install/UnderConstruction.htm and a message appears: "This site is currently Unavailable".

By Jay on Wednesday, July 16, 2008 at 4:57 AM

Jay,

Typically that will be due to an improper connection string to the new database.

I would start by validating the information supplied there.

By mitchel.sellers@gmail.com on Wednesday, July 16, 2008 at 8:58 AM

Mitchel,

Thank you for your generosity - sharing all this information. I really appreciate. I had the same error where my migrated site was coming up with the "Under Construction" message. It was indeed the database connection string.

Thanks!

By Will M. on Sunday, August 17, 2008 at 10:12 PM

Hi Mitchell,

Thanks for the information. I am going through this for the first time. I really want to set up the development and production installation in a way that one could go back and forth as desired. So, then, this method would entail changing the image paths in HTML everytime you copy installation from one side to the other. That would be a lot of work if you really stick to testing ALL your changes in the dev area and then wanted to uodate Production several times a day perhaps.

It seems to me the better solution would be to find a way to have both installs at the website root or both in folders under the web root. Since the problem is caused by having one install under the root and the other in a subfolder. No?

This desire of establishing Development and PRoduction areas is kind of a lot of work to manage. Particularly if your Production install is on a remote hosting server where one doesn't have all the admin permissions, one can't directly connect to SQL or restore SQL backups from other systems.

Well, we'll keep looking for better ways. I think maybe the DNN team can come up with a modification to handle this if enough peope need it.

Thanks for the help.

By Ivan Torres on Wednesday, September 17, 2008 at 9:21 AM

Ivan,

Yes, the simple solution is to have both installations on the root in IIS, if you do that, you will be fine.

By mitchel.sellers@gmail.com on Wednesday, September 17, 2008 at 9:54 AM

Hi,

I'm new to DotNetNuke and perhaps i'm a little biaised by my use to php portal where the migration is easier.

I have been trying to migrate a portal from one server to another one which should be easier than from a local server to a host.

I have backup and restore the database from on server to the other. I copied the dotnetnuke folder named "Intranet" from one server to the other.

I have had permissions issues taht i created on the folder and the new database.

I have had the corrected the connection string and the portal first page is displayed.

But every link I clicked, i get a "The page cannot be found" message.

I don't know what can be wrong. I seem to be a link tabid issue because the link is displayed but no page.

e.g. "http://applsvr/Intranet/LinkClick.aspx?link=55&tabid=36&mid=371"

By Terrence BELONY on Friday, October 03, 2008 at 6:58 AM

I meant "I have had permissions issues that i cleared on the folder and the new database."

and thanks for your help.

By Terrence BELONY on Friday, October 03, 2008 at 7:01 AM

Thanks Mitchel, your post was very helpful. I have two comments that I'd like to contribute back.

1. The first regards setting the portal alias as you directed. Where there are multiple portals in a site, or even if there is just one, I found it faster to edit the database directly AFTER it was loaded at the new site. I used a SQL script and saved it so that it could be reused. The script consists of a series of update statements as follows:

UPDATE PortalAlias SET HTTPAlias = 'new alias' WHERE HTTPAlias = 'old alias'

2. My second comment is actually something that I think needs to always be done: the site's Host URL needs to be updated, either with the DotNetNuke Host Settings Module or by updating the HostURL column in the HostSettings table. I was having a problem with login to a portal other than the default until I changed the Host URL.

One caveat for all regarding updating the database directly, you'll be taking a chance that a future DotNetNuke change will break this approach. But, for now they worked for me.

By Steve Stallings on Friday, December 26, 2008 at 3:05 AM

Steve,

The downside to updating the aliases afterwards is that you MUST remember to re-cycle the application. If you can do it before you go, it makes the process a bit easier, especially for those not comfortable with SQL. However, 99% of the time I do it the way you listed.

That is a VERY valid point about the host URL, and something that I have not encountered, or dealt with as an "issue" yet.

By mitchel.sellers@gmail.com on Friday, December 26, 2008 at 3:12 AM

Hello Mitchell,
We would like to maintian dnn on development and production server and move back and forth as required. How can we achieve this? are there an already developed tools which we can use. Your help would be appreciated. Thanks in advance.
Siddharth

By Siddharth on Friday, January 02, 2009 at 9:12 AM

Siddharth,

That is not an easy task to accomplish, and it takes a lot of knowlege to get it done in a safe manner. If you want to discuss, please use the forum.

By mitchel.sellers@gmail.com on Friday, January 02, 2009 at 9:36 AM

Mitch,

I have DNN installed on a live webserver and would like to copy it to another webserver so I can rebuild the exisiting server.

I have copied all files, exported the DB and imported successfully onto the new server. I setup a dummy portal before I exported the DB.

All seems ok but when I go to the URL of the dummy portal [on the new webserver] it automatically re-directs to a domain on the old server.

For example if you go to: www.gohel.co.uk [old server] it redirects to www.bhalsod.co.uk [new server]

IIS is set up correctly i believe.

Im totally stuck!! Any ideas?

By Chitt on Friday, January 30, 2009 at 12:02 PM

Hi Mitch

I hope you can help me.

By Chitt Bhardwa on Friday, January 30, 2009 at 12:04 PM

Chitt,

Ensure that you have a portal alias entry in the PortalAlias table for the new domain. Please post the forums if you need more assistance.

By mitchel.sellers@gmail.com on Friday, January 30, 2009 at 12:15 PM


Currently we develop site on local machine and then take it to production with site packaging and deployment feature.

This process does not work as flowlessly as directly moving site with database due to many modules and DNN frameworks limitations. for e.g.

Many modules do not perform this import / export correctly.

Tabid get changed with this process for all the tab. so custom links do not work.

I am hoping to find any tool which can help with this process.

By nitin on Tuesday, March 24, 2009 at 12:24 PM

I have a very similiar issue but I think mine might be related to SSL. I did create an alias for my new domain but my new site (and new domain) redirects to the old domain/site and if I try and remove the references to SSL (read below), I get the dreaded .NET error.

If anyone would provide assistance I would be eternally grateful. I'm attempting to migrate from one domain to another. The "from domain" currently is a .COM domain with SSL and DotNetNuke is configured for SSL for the entire site. The "to domain" is a .NET domain without SSL.

I should also mention that I create a portal alias in the current product .COM site to the .NET site.

I've restored the SQL database without issue. I've migrated file content without issue.

I have several problem that I thought I could overcome with simple changes in records in SQL for the configuration on the DASP side.

1) without any changes the .NET site will immediate redirect to an SSL version of the .NET site (which does not exist).

2) If I change the TABS table record column for the home page called IsSecure to "False" (from True) it get the dreaded "object reference not set to an instance of an object..." error.

I've tried changing the HOST url in HostSettings to the .NET site vs the .COM site, same issue.

I should also add that in some iteration of trying to get this working I had a perpetual redirection issue which would present itself in different ways depending on what browser and version you had... I fixed this by restoring the DB again.

Anyone have a clue???

Thanks in advance to the genius that can figure this one out.

Joe

By delymarnet0 on Saturday, May 23, 2009 at 10:07 AM

I've discovered my problem. I'm embarrassed to admit that, even after triple checking this, I failed to migrate the /portal directory but very pleased to report that the steps to migrate were 95% accurate. If you are migrating from an SSL enabled site to a non SSL enabled site, you will have to open the Tabs table and set the IsSecure column to False before the site will load. This apparently only needs to be done on the home page for the site to work but it looks as if you need to do this manually for each home page of individual portals. You can use the following SQL query to update the db table:

update Tabs set IsSecure=False where TabID=insertyourtabidnumberofthehomepagehere

By delymarnet0 on Tuesday, May 26, 2009 at 11:44 AM

Here is another tip...it may have nothing to do with versions, DBOs, etc.

If you are migrating a database from one SQL server to another SQL server, the User IDs in your databases could end up with conflict SIDs. Here is how you verify and resolve the problem:

http://blog.strictly-software.com/2009/09/database-owner-sid-recorded-in-master.html

It only took me a full evening to figure this out!

By Jon Morrissette on Monday, October 26, 2009 at 12:44 AM

can you provide Text/HTML Replacement tool that works with DNN 5.1.4, that will be very helpful for me, thanks

By Kiran on Friday, January 08, 2010 at 11:36 AM

I'm finding that there are many gotchas you didn't mention. One is that some modules store file path (including drive letters) in the database! Skins for example!

So once you have moved your files, you may have one helluva time getting things to work because things aren't where they are expected.

By Zach Baker on Thursday, January 14, 2010 at 1:46 PM

This is a great article! Very concise and thorough! I got this post from the DNN site forum and was very pleased at how clear it was... One question, though:

I know this was written some time ago, and is written (tutorial) for the older version of SQL server, but how do I go about doing this for SQL 2008 Express?

So far I know that you have to run 2008's Migration tool (SQL Server Import and Export Wizard) But the finer points are kind of... uhm... yeah.

By APetersen on Thursday, February 18, 2010 at 4:11 PM

Hi Mitchel,

I moved my dnn web site and dababase, i configured my iis everything is rigth but when i try to login i can't do it. send me this error " Login Failed. Please remember that passwords are case sensitive"

By Jonathan Valle on Thursday, May 20, 2010 at 1:44 PM

I just upgraded my site from ASP.NET 2.0 to ASP.NET 4.0 In this process the server was changed. On the new server all my LinkClicks result in error 404 :-(
My Site is running 4.9.4. I upgraded to 5.4.2, but no change. Then I went back to 4.9.4. Error logs telling me

AssemblyVersion: 04.09.04
PortalID: 0
PortalName: XX
UserID: 179
UserName: lsb
ActiveTabID: 89
ActiveTabName: RMA
RawURL: /LinkClick.aspx?fileticket=XnMSB%2ffJRLw%3d&tabid=89&mid=497
AbsoluteURL: /LinkClick.aspx
AbsoluteURLReferrer: http://web.XXXX.XXX/Default.aspx?tabid=89
UserAgent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
DefaultDataProvider: DotNetNuke.Data.SqlDataProvider, DotNetNuke.SqlDataProvider
ExceptionGUID: 120ef6f4-7803-4e9a-b580-7408a40e34fb
InnerException: Unhandled Error:
FileName:
FileLineNumber: 0
FileColumnNumber: 0
Method: System.Web.UI.Util.CheckVirtualFileExists
StackTrace:
Message: System.Exception: Unhandled Error: ---> System.Web.HttpException: The file '/LinkClick.aspx' does not exist. at System.Web.UI.Util.CheckVirtualFileExists(VirtualPath virtualPath) at System.Web.Compilation.BuildManager.GetVPathBuildResultInternal(VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile, Boolean throwIfNotFound, Boolean ensureIsUpToDate) at System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert(HttpContext context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile, Boolean throwIfNotFound, Boolean ensureIsUpToDate) at System.Web.Compilation.BuildManager.GetVirtualPathObjectFactory(VirtualPath virtualPath, HttpContext context, Boolean allowCrossApp, Boolean throwIfNotFound) at System.Web.Compilation.BuildManager.CreateInstanceFromVirtualPath(VirtualPath virtualPath, Type requiredBaseType, HttpContext context, Boolean allowCrossApp) at System.Web.UI.PageHandlerFactory.GetHandlerHelper(HttpContext context, String requestType, VirtualPath virtualPath, String physicalPath) at System.Web.UI.PageHandlerFactory.GetHandler(HttpContext context, String requestType, String virtualPath, String path) at System.Web.HttpApplication.MaterializeHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) --- End of inner exception stack trace ---
Source:
Server Name: WEB33

Any ideas of what to try now?

By SL.amin on Monday, June 14, 2010 at 8:51 AM

Hi Friends,
I had deployed my site and its working properly but the problem is when i login in to site, it does not show me the text of dotnetnuke functionility buttons like host or admin it only shows the buttons.Does anyone tell me what is the actual problem and how to solve it ?

Thanks

By Nilesh on Tuesday, August 24, 2010 at 10:28 AM

I have moved community edition sites using this blog's steps and they reproduce fine. What I need is some further instruction on how to preserve licenses when refreshing a dev server from prod using professional edition or deploying the entire content from a dev site to prod after installing and activating licenses.

By Michael Barnett on Tuesday, September 07, 2010 at 12:02 PM

@Michael - This is really going to depend on how developers are licensing the modules, and it will vary from module to module.

By mitchel.sellers@gmail.com on Tuesday, September 07, 2010 at 2:42 PM

I see I was unclear in my original post.

Module licenses are not my issue. In my dev/prod environment I purchased DNN Professional from DNNCorp which requires license activation. DNN Community does not and so there is no issue migrating from dev to prod in the community edition and there is no license activation to worry about in Community Edition. Professional Edition is a different animal.

Can you discuss preserving DNN Pro licenses when migrating a site from a development licensed DNN Pro site to a prod licensed DNN pro site? Assume I have no third party licensed modules and am just trying to cope with preserving the licens for DNN Pro.

Michael >> I have moved community edition sites using this blog's steps and they reproduce fine. What I need is some further instruction on how to preserve licenses when refreshing a dev server from prod using professional edition or deploying the entire content from a dev site to prod after installing and activating licenses.

Mitchel >> @Michael - This is really going to depend on how developers are licensing the modules, and it will vary from module to module.

By Michael Barnett on Monday, September 27, 2010 at 7:30 AM

Hello Mitchell, I followed all the steps in your tutorial but got the following error when I changed the web.config connection to the correct database.

Unhandled Error
Error Details
File
Error Cannot insert the value NULL into column 'LogEventID', table 'rarotraini1.dbo.CMS_EventLog'; column does not allow nulls. INSERT fails. The statement has been terminated.

Any idea?

Tks.

By Marcus on Tuesday, December 28, 2010 at 5:09 AM

BC30002: Type 'IDataReader' is not defined.

I got this error ater I migrate the DNN to remote server.

Please Help.

By ico on Sunday, February 27, 2011 at 9:17 PM

Mitch,

This article is great for the first time but what about when you have a production site and need to test in a QA environment before you push changes to Production? Do you have any suggestions? The thing I can't get past is that you have to configure QA and then do it all gain in PROD.

The thing is, we have data going to PROD on a daily basis so we can't just over write the database.

Any pointers would be greatly appreciated!

thanks,
Craig

By Craig on Saturday, August 20, 2011 at 9:52 PM

Hi Mitchel,
When I precompile the Website the admin tool bar is not showing up. It only displays "Critical Updates Available" at the top. This is appearing in my localhost as well in the live website. In the edit mode the "Manage" words does not show up for the content. Could you please help to fix this issue?

thanks,
Sara

By Sara on Thursday, March 15, 2012 at 10:32 AM

Sara,

Precompilation of DotNetNuke is not supported.

By mitchel.sellers@gmail.com on Thursday, March 15, 2012 at 12:43 PM

Name (required)

Email (required)

Website

CAPTCHA image
Enter the code shown above:

Content provided in this blog is provided "AS-IS" and the information should be used at your own discretion.  The thoughts and opinions expressed are the personal thoughts of Mitchel Sellers and do not reflect the opinions of his employer.

Friend of RedGate

www.datasprings.com - DotNetNuke Modules ICG Hosting

Click here for advertising information.

Content in this blog is copyright protected.  Re-publishing on other websites is allowed as long as proper credit and backlink to the article is provided.  Any other re-publishing or distribution of this content is prohibited without written permission from Mitchel Sellers.