We have installed and upgraded quite a few sites to the latest DNN version, 4.5.3, that came out last week and most went seamlessly. However, we have found one issue that has raised it's ugly head quite a few times. After upgrading, if you clicked on "Register" you would be redirected to an admin skinned page with no account fields/content. Looking at the url you can see "/ctl/returnurl". Since the site(s) uses a custom page using a 3rd party module for registration for the account info, it is specified in Admin > Site Settings > Advanced Settings > Page Management > User Page.
Here is the error message:
System.Web.HttpException: Could not load type ''. ---> System.ArgumentException: String cannot have zero length. at System.Reflection.Assembly.GetType(String name, Boolean throwOnError, Boolean ignoreCase) at System.Web.Compilation.BuildManager.GetType(String typeName, Boolean throwOnError, Boolean ignoreCase) --- End of inner exception stack trace --- at System.Web.Compilation.BuildManager.GetType(String typeName, Boolean throwOnError, Boolean ignoreCase) at DotNetNuke.Framework.Reflection.CreateType(String TypeName, String CacheKey, Boolean UseCache, Boolean IgnoreErrors)
Luckily we found a post on the DNN Forums concerning the quick fix...
4.5.3 New user registration not working if specific page defined
In the above post someone else was having a similar issue. It looks like there was a bug reported as well:
http://support.dotnetnuke.com/issue/ViewIssue.aspx?id=5746
While there could definitely been a longer or better description of the problem, it was quickly closed with "unable to reproduce in 4.5.3" the next day without any followup. Luckily the thread on the forums gained the interest of other having the issue and vitkoz was kind enough to run it through debugging to find the issue and hence the issue has been reopened in the DNN issue tracker.
Here is his fix:
"In the file admin/skins/user.ascx.vb, line 142 needs to be changed:
FROM THIS:
Response.Redirect(NavigateURL(PortalSettings.UserTabId,"returnurl=" & ReturnUrl), True)
TO THIS:
Response.Redirect(NavigateURL(PortalSettings.UserTabId, "Register", "returnurl=" & ReturnUrl), True)
You can simply go to that file, make that change, and IIS will recompile it on the next run." - vitkoz
We had a DNN 4.4.1 to 4.5.1 upgrade that threw a few SQLDataProvider errors during the installer that were caused by duplicate files in DNN Files table. Not sure how they got there, but here is a SQL statement to check if they exist:
SELECT PortalID, Filename, Folder, COUNT(Filename) AS NumOccurrences
FROM files
GROUP BY Filename, PortalID, Folder
HAVING ( COUNT(Filename) > 1 AND Count(PortalID) > 1 AND Count(Folder) > 1)
Here is the SQL that was provided in the log file from the installer:
/* add unique constraint to Files table */
IF NOT EXISTS (select * from dbo.sysobjects where id = object_id(N'dbo.[IX_FileName]') and OBJECTPROPERTY(id, N'IsConstraint') = 1)
BEGIN
declare @FolderID int
declare @FileName nvarchar(100)
declare @FileID int
declare @MinFileID int
select @FolderID = min(FolderID)
from Folders
while @FolderID is not null
begin
/* check for duplicate Filenames */
select @FileName = null
select @FileName = FileName
from Files
where FolderID = @FolderID
group by FileName
having COUNT(*) > 1
/* if duplicates exist */
if @FileName is not null
begin
/* iterate through the duplicates */
select @FileID = min(FileID)
from Files
where FolderID = @FolderID
and FileName = @FileName
/* save min FileID */
select @MinFileID = @FileID
while @FileID is not null
begin
if @FileID <> @MinFileID
begin
/* remove duplicate file */
delete
from Files
where FileID = @FileID
end
select @FileID = min(FileID)
from Files
where FolderID = @FolderID
and FileName = @FileName
and FileID > @FileID
end
end
select @FolderID = min(FolderID)
from Folders
where FolderID > @FolderID
end
ALTER TABLE dbo.Files ADD CONSTRAINT
IX_FileName UNIQUE NONCLUSTERED
(
FolderID,
FileName
) ON [PRIMARY]
END
Continuous integration is a software development term describing the process that completely rebuilds and tests applications frequently. We recently implemented a continuous integration environment to “publish” our DotNetNuke modules to our development/staging DotNetNuke sites.
The main advantages of a continuous integration environment are:
- Issues are detected and fixed continuously!
- Enhancements and new features are published continuously!
- You are warned about problematic code before it is published.
- Immediate unit testing of all changes.
- Constant availability of a "current" build for testing, demos, or releases.
- Bragging rights for developers who have the least number of broken builds.
- Huge conservation of time when considering the normal administrative process of Build > Package > install in DNN > Test.
- Did I mention this is continuous?
How Our CI and DNN Environment Works
Below is a picture to show you the basics of how our continuous integration environment works.
Disclaimer:
- If you are running Visual Studio 2005 Web Developer Express, our setup will not work for you. You can stop reading here, or upgrade, unless you are just curious, then read on…
- There have been long discussion on Web Site Projects (WSP) versus Web Application Projects (WAP) and this post is not one to argue about which is better, rather than to say this is what we do, and the basics of how it works.
- You are free to comment and collaborate with others on this post. Feel free to even argue about WAP versus WEP, or that you may know of a way to integrate CI with DNN and WSP, we really do not care. However, we do not have time to walk you through setting any of this up, so please do not ask…unless you are interested in one of our DNN support packages, then by all means we can help
Basics of the process:
- A developer “commits” the DNN module code to Subversion.
- The commit triggers CruiseControl.Net to “build” the DNN module using a “Trigger” for the project.
- CruiseControl.Net can be configured to unit test the module before publishing.
- An “ExecutableTask” is used with our custom assembly publisher application to send the .DLL file to the DNN website.
- A “BuildPublisher” sends the code from the source directory to the DNN site (D:\DNNSites\ClientDevSite\DesktopModules\CustomDNNModule as example).
- Results of “build” are visible in the CruiseControl.Net Web Dashboard.
Implementing CI for DNN Development
Development:
We started DotNetnuke 4 development using the WSP methodology for all of our DNN projects. This has been successful for us for quite a while, especially when using EntitySpaces for the Persistence Layer and Business Objects (it's so easy using ES to generate the DAL. You must check this out if you are not using it). However, we found that to make this work we have to use WAP projects. I have a very fast laptop, but using WSP and doing a build of all of DNN to compile a module can be quite time consuming, taking several minutes sometimes. But, building a WAP project is FAST, saving some development time when debugging and testing builds, especially when doing those final little tweaks. One could argue that WSP is better, but for our setup with one to many developers working on a single module, WAP is the best decision. So, it did not take much to twist our arm to changing our methodology. It is unfortunate that in order to use this for our existing clients and projects, we will need to convert our WSP modules to WAP. But, we have started developing all new modules as WAPs and converting WSP modules to WAP is not a difficult task.
To read about the great WSP versus WAP debate, see the following links:
Shaun Walker’s post on WAP
http://www.dotnetnuke.com/Community/Blogs/tabid/825/EntryID/434/Default.aspx
An interesting debate between Michael Washington and Vladan Strigo
http://www.dotnetnuke.com/Projects/ModuleNews/Forums/tabid/953/forumid/111/threadid/91268/threadpage/6/scope/posts/Default.aspx
WAP Methodology
“Web Application Projects provide a companion web project model that can be used as an alternative to the built-in Web Site Project in Visual Studio 2005. This new model is ideal for web site developers who are converting a Visual Studio .Net 2003 web project to Visual Studio 2005. (Released May 8, 2006)” - http://msdn2.microsoft.com/en-us/asp.net/aa336618.aspx
Michael Washington has a great post on creating a DNN WAP Module:
http://www.adefwebserver.com/DotNetNukeHELP/DNN4_WAP/
Once the module is ready for testing on our client development site, we use TortoiseSVN to “commit” code to Subversion (http://tortoisesvn.tigris.org/).
Source Code Version Control:
We use Subversion for our source code repository and version control system (http://subversion.tigris.org/). We have tried Visual SourceSafe and CVS, but have been using Subversion with success for quite some time now. CruiseControl.Net integrates with Subversion easily. It is also nice that there is a plugin for Subversion that allows us to send our comments directly to Gemini (project management/tracking application) when we commit new code.
Continuous Integration Software:
We use CruiseControl.Net, a .Net port of the Java based CruiseControl
Continuous Integration Server using CruiseControl.Net
The CruiseControl.Net Server automates the integration process by monitoring the team's source control repository directly. Every time a developer commits a new set of modifications for the DNN module, the server will automatically launch an integration build to validate the changes. When the build is complete, the server notifies the developer whether the changes that they committed integrated successfully or not.
CruiseControl.Net allows for several different types of “Tasks”, such as:
- EmailPublisher (for emailing of build details)
- ExecutableTask (for kicking off executables, such as our custom assembly publisher)
- NAntTask (for unit testing)
- NUnitTask (for unit testing)
- RSSBuildsPublisher (for generating a RSS feed with details)
- VisualStudioTask (for running something in VS)
- Etc.
Here is an example ccnet.config:
<!--<ccnetconfig><configurationVersion>1.2.1</configurationVersion></ccnetconfig>-->
<cruisecontrol>
<project name="BPLWantList">
<workingDirectory>D:\cibuilds\ProjectName\ModuleName</workingDirectory>
<webURL>http://ourCIdomain.com/server/local/project/ModuleName/ViewProjectReport.aspx</webURL>
<sourcecontrol type="svn">
<trunkUrl>svn://localhost/ProjectName/ModuleName</trunkUrl>
</sourcecontrol>
<triggers>
<intervalTrigger name="Quarter Hour Build" seconds="900" />
</triggers>
<tasks>
<exec>
<executable>VenexusAssemblyPublisher.exe</executable>
<baseDirectory>D:\</baseDirectory>
<buildArgs>"d:\Source\ProjectName\DesktopModules\ModuleName\obj\Debug" "d:\DevSites\ProjectName\bin"</buildArgs>
</exec>
</tasks>
<publishers>
<buildpublisher>
<sourceDir>D:\cibuilds\ProjectName\ModuleName</sourceDir>
<publishDir>D:\DevSites\ProjectName\DesktopModules\ModuleName</publishDir>
<useLabelSubDirectory>false</useLabelSubDirectory>
</buildpublisher>
<xmllogger />
<statistics />
</publishers>
</project>
</cruisecontrol>
CruiseControl.Net Web Dashboard
The CruiseControl.Net Web Dashboard Application is used for reporting a wide range of information about the builds. At one end of the scale it reports summary details of all projects in your organisation and at the other it can give specific metric output for any specific build.
Here is an example of a simple DNN Module being used in our CI environment:
Notice the failed build notification. While we have not setup unit testing, you can see in the left menu in the image, there are quite a few different options.
Conclusion
For long term DotNetNuke module projects, setting up a continuous integration environment will save a tremendous amount of time in the long run. All of the tools to implement CI are free, lowering the total cost of DNN module development. With a little bit of time setting up your environment, you can provide continuous updates to your clients, all while forcing good coding practices among your developers.
There is nothing better to start off the day than having a client running into a 100% CPU utilization issue on their production SQL Server. Every few minutes, the server would spike up and hang there for a variable amount of time (15 seconds to several minutes). You can only imagine the flakiness of a website with SQL Server choking to death. There was nothing of value to point any fingers as to the culprit of this issue in the event logs for DNN (Admin > LogViewer)...none that we saw through a brief spot checking and filtering of event types (this was incredibly slow and seeing timeouts so we abandoned all hope of using DNN Admin/Host tools to find the problem). And, there was not an alarming number of events actually logged in EventLog table. However, we have seen issues with performance that are usually resolved by clearing the Log Viewer. We have seen cases where clients who have high traffic/usage sites, or a broken/problematic module on all pages, have 5 and 6 figure rows of data for EventLog table, especially if all the default settings are used for the DNN Log Viewer settings. We have seen timeout issues just trying to clear the event log when they get that large ("Delete EventLog" as the sql statement does the trick quickly from SSMS). So, we went ahead and cleared it, but the issue persisted.
For those who have not explored much in SQL Server Management Studio (not in SSMS Express), there is now a Database Engine Tuning Advisor and SQL Server Profiler (under Tools > SQL Server Profiler). Running the SSP, we performed a trace and caught the offending SQL causing all of the havoc. Just a note...we have run DETA to find recommendations from trace files for several large DNN databases and apply the recommendations (it usually creates new indexes for tables that have 6 and 7 figure rows, helping greatly with performance on databases). But in this case, we just started and stopped the trace in SSP before and after a huge and hanging spike. Going through the rows looking for CPU hits, we found the following 2 villians of resources:
GetSchedule @Server ='SERVERNAME'
GetScheduleNextTask @Server ='SERVERNAME'
Running these statements showed the huge spike on command, pegging the server hard. Looking in the stored proc it hits Schedule and ScheduleHistory.
ALTER PROCEDURE [dbo].[GetSchedule]
@Server varchar(150)
AS
SELECT S.ScheduleID, S.TypeFullName, S.TimeLapse, S.TimeLapseMeasurement, S.RetryTimeLapse, S.RetryTimeLapseMeasurement, S.ObjectDependencies, S.AttachToEvent, S.RetainHistoryNum, S.CatchUpEnabled, S.Enabled, SH.NextStart, S.Servers
FROM Schedule S
LEFT JOIN ScheduleHistory SH
ON S.ScheduleID = SH.ScheduleID
WHERE (SH.ScheduleHistoryID = (SELECT TOP 1 S1.ScheduleHistoryID FROM ScheduleHistory S1 WHERE S1.ScheduleID = S.ScheduleID ORDER BY S1.NextStart DESC)
OR SH.ScheduleHistoryID IS NULL)
AND (@Server IS NULL or S.Servers LIKE ',%' + @Server + '%,' or S.Servers IS NULL)
GROUP BY S.ScheduleID, S.TypeFullName, S.TimeLapse, S.TimeLapseMeasurement, S.RetryTimeLapse, S.RetryTimeLapseMeasurement, S.ObjectDependencies, S.AttachToEvent, S.RetainHistoryNum, S.CatchUpEnabled, S.Enabled, SH.NextStart, S.Servers
In ScheduleHistory we found a little over 6 thousand rows. You can use the following to check your db:
select count(*) from schedulehistory
6000+ does not seem like that many rows to be causing that much of a peak, but regardless we deleted them all getting desperate at this point:
delete schedulehistory
Executing the 2 sprocs again for the schedule, and cpu barely gets over 3% utilization. The site is again fast and responsive and I was able to get in and check settings without getting timeouts. So, as an interim fix I lowered the defaults in DotNetNuke.Services.Scheduling.PurgeScheduleHistory under Host > Schedule.
I am concerned about why 6000 rows of data would be taking such a hit on cpu resources. However, that it more records than I believe should be there, so lowering the defaults will help. Nothing in the DNN stored procedure for GetSchedule really stands out at me as being problematic, nor at first glance do I see anything that could be changed that may help, but I will ponder on this some more in my copious spare time.
So, if you are having trouble with SQL Server performance and DNN, check and make sure you keep your EventLog and ScheduleHistory purged.
If you need help, be sure to checkout our DNN Support Packages.
We had a backup domain controller running on our dev machine. After moving it to a different server, we got the following error on our development DNN websites:
Server Error in '/' Application.
The
current identity (NT AUTHORITY\NETWORK SERVICE) does not have write
access to 'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary
ASP.NET Files'.
Description: An
unhandled exception occurred during the execution of the current web
request. Please review the stack trace for more information about the
error and where it originated in the code.
Exception Details: System.Web.HttpException:
The current identity (NT AUTHORITY\NETWORK SERVICE) does not have write
access to 'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary
ASP.NET Files'.
Source Error:
An unhandled exception was generated during the execution of the
current web request. Information regarding the origin and location of
the exception can be identified using the exception stack trace below.
|
Stack Trace:
[HttpException (0x80004005): The current identity (NT AUTHORITY\NETWORK SERVICE) does not have write access to 'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files'.]
System.Web.HttpRuntime.SetUpCodegenDirectory(CompilationSection compilationSection) +3482363
System.Web.HttpRuntime.HostingInit(HostingEnvironmentFlags hostingFlags) +226
[HttpException (0x80004005): The current identity (NT AUTHORITY\NETWORK SERVICE) does not have write access to 'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files'.]
System.Web.HttpRuntime.FirstRequestInit(HttpContext context) +3434991
System.Web.HttpRuntime.EnsureFirstRequestInit(HttpContext context) +88
System.Web.HttpRuntime.ProcessRequestInternal(HttpWorkerRequest wr) +252
|
I checked all the security permissions and ensured network service had full permission for the folder. I even reset permissions to make sure. No dice. I found the following trick to fix it quickly...despite my time looking for it. In a command prompt, navigate to the following: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727 Then run the following command: aspnet_regiis -ga "NT AUTHORITY\NETWORK SERVICE" Everything worked fine after running that. Since I am bound to forget this, I am posting it here for me and others, hopefully saving me or someone time.
Wow, we can't even keep up with all of the new releases of DotNetNuke lately... Download DNN 4.3.4
Digging a little deeper I see the reason for this quick build is due to a couple of security issues, one being a "Critical Issue".
I also found a page on DotNetNuke that I have not seen before:
http://dotnetnuke.com/SecurityPolicy/tabid/940/Default.aspx
At the bottom are a couple of documents:
Can't we go back to complaining about when the next release will be? Just kidding. It is good to see that the core team is proactive about keeping DNN patched and up-to-date. As a community, we need to do the same and update our systems as quickly as possible to keep DNN from getting a bad name.
We are still experiencing the caching issue on Installation C I mentioned in a previous post. This is the first item we tested with the new release and it is still broken :-(
AssemblyVersion: 04.03.01
Method: System.Web.UI.Control.LoadViewStateRecursive
FileName:
FileLineNumber: 0
FileColumnNumber: 0
PortalID: 0
PortalName: Client Portal A
UserID: 1
UserName: host
ActiveTabID: 87
ActiveTabName: For Testing
AbsoluteURL: /Default.aspx
AbsoluteURLReferrer:
ExceptionGUID: c774691d-427e-41e1-abc0-714f3a1b7a4f
DefaultDataProvider: DotNetNuke.Data.SqlDataProvider, DotNetNuke.SqlDataProvider
InnerException: Failed to load viewstate. The control tree into which viewstate is being loaded must match the control tree that was used to save viewstate during the previous request. For example, when adding controls dynamically, the controls added during a post-back must match the type and position of the controls added during the initial request.
Message: DotNetNuke.Services.Exceptions.PageLoadException: Failed to load viewstate. The control tree into which viewstate is being loaded must match the control tree that was used to save viewstate during the previous request. For example, when adding controls dynamically, the controls added during a post-back must match the type and position of the controls added during the initial request. ---> System.Web.HttpException: Failed to load viewstate. The control tree into which viewstate is being loaded must match the control tree that was used to save viewstate during the previous request. For example, when adding controls dynamically, the controls added during a post-back must match the type and position of the controls added during the initial request. at System.Web.UI.Control.LoadViewStateRecursive(Object savedState) at System.Web.UI.Control.LoadChildViewStateByIndex(ArrayList childState) at System.Web.UI.Control.LoadViewStateRecursive(Object savedState) at System.Web.UI.Control.LoadChildViewStateByIndex(ArrayList childState) at System.Web.UI.Control.LoadViewStateRecursive(Object savedState) at System.Web.UI.Control.LoadChildViewStateByIndex(ArrayList childState) at System.Web.UI.Control.LoadViewStateRecursive(Object savedState) at System.Web.UI.Control.LoadChildViewStateByIndex(ArrayList childState) at System.Web.UI.Control.LoadViewStateRecursive(Object savedState) at System.Web.UI.Control.LoadChildViewStateByIndex(ArrayList childState) at System.Web.UI.Control.LoadViewStateRecursive(Object savedState) at System.Web.UI.Control.LoadChildViewStateByIndex(ArrayList childState) at System.Web.UI.Control.LoadViewStateRecursive(Object savedState) at System.Web.UI.Control.LoadChildViewStateByIndex(ArrayList childState) at System.Web.UI.Control.LoadViewStateRecursive(Object savedState) at System.Web.UI.Control.LoadChildViewStateByIndex(ArrayList childState) at System.Web.UI.Control.LoadViewStateRecursive(Object savedState) at System.Web.UI.Control.LoadChildViewStateByIndex(ArrayList childState) at System.Web.UI.Control.LoadViewStateRecursive(Object savedState) at System.Web.UI.Page.LoadAllState() at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) --- End of inner exception stack trace ---
StackTrace:
Source:
Server Name: BARNEY
So far, this issue only appears on a DNN installation that uses a subdomain. Maybe this is related to using a subdomain somehow? I made sure I had logged out of the main domain site, and the subdomain site, cleared browser cache and cookies, logged in again, and experieced the same issue.
UPDATE:
This issue does NOT occur if caching is turned off.
Update 6/28/2006:
Issue logged in DNN Butracker ID#: 3348
Just when we were about to abandon ship on the 4.3 release and roll back to 4.0.3, a new "point release" is issued...
"A "point" release has been posted for DotNetNuke 3.3/4.3 today. This point release contains fixes for a number of issues which were identified in the original Release Candidate packages." - Download from DNN
With weird caching issues and missing UserController methods,...which I will rant about later...we were prepared to roll back our development stack to the 4.0.3 release. Instead we will be testing the new version with our fingers crossed that it fixes many of the issues we have found. Check back later for the results!
We are seeing some weird errors on a few DNN 4.3 installations we are testing. Specifically, there seems to be a caching issue when adding new pages. So far, we have experieced the error in the following environments:
Installation A:
My local development machine (Dell Latitude D810) running XP with all of the latest patches, local SQL Server 2005 Standard, fresh DNN 4.3 Source, using localhost.
Installation B:
Development server (Dell 1550) running Windows 2003 with all of the latest patches, remote SQL Server 2005 Enterprise, DNN 4.3 Upgrade (upgrade from DNN 4.0.3), using www.dnnmoddev.org domain
Installation C:
Development server (Dell 1550) running Windows 2003 with all of the latest patches, local SQL Server 2005 Standard, DNN 4.3 Install (non source version), using a subdomain of Venexus.com (someclient.venexus.com)
But NOT in Installation D:
Production server (Dell 2850) running Windows 2003 with all of the latest patches, remote SQL Server 2005 Enterprise, DNN 4.3 Upgrade (upgrade from DNN 4.0.3), using www.someclient.com.
On Installation A, when creating a new page, after clicking update, I am redirected to the home page and the newly created page is not in the SolPartMenu. I can refresh the page and it is sometimes suddenly visible, and other times, still not visible. If I go to Admin > Pages, I can see it in the list.
On Installation B, when creating a new page, we experience similar issues as Installation A, but also see weird behavior in some modules where the contents are not displayed.
On Installation C, all is the same as Installation A, but we see viewstate errors:
AssemblyVersion: 04.03.00
Method: System.Web.UI.Control.LoadViewStateRecursive
FileName:
FileLineNumber: 0
FileColumnNumber: 0
PortalID: 0
PortalName: Client Development Portal
UserID: 1
UserName: host
ActiveTabID: 82
ActiveTabName: Downloads
AbsoluteURL: /Default.aspx
AbsoluteURLReferrer:
ExceptionGUID: 2848db05-e95f-48c2-875a-7c4cb7c525df
DefaultDataProvider: DotNetNuke.Data.SqlDataProvider, DotNetNuke.SqlDataProvider
InnerException: Failed to load viewstate. The control tree into which viewstate is being loaded must match the control tree that was used to save viewstate during the previous request. For example, when adding controls dynamically, the controls added during a post-back must match the type and position of the controls added during the initial request.
Message: DotNetNuke.Services.Exceptions.PageLoadException: Failed to load viewstate. The control tree into which viewstate is being loaded must match the control tree that was used to save viewstate during the previous request. For example, when adding controls dynamically, the controls added during a post-back must match the type and position of the controls added during the initial request. ---> System.Web.HttpException: Failed to load viewstate. The control tree into which viewstate is being loaded must match the control tree that was used to save viewstate during the previous request. For example, when adding controls dynamically, the controls added during a post-back must match the type and position of the controls added during the initial request. at System.Web.UI.Control.LoadViewStateRecursive(Object savedState) at System.Web.UI.Control.LoadChildViewStateByIndex(ArrayList childState) at System.Web.UI.Control.LoadViewStateRecursive(Object savedState) at System.Web.UI.Control.LoadChildViewStateByIndex(ArrayList childState) at System.Web.UI.Control.LoadViewStateRecursive(Object savedState) at System.Web.UI.Control.LoadChildViewStateByIndex(ArrayList childState) at System.Web.UI.Control.LoadViewStateRecursive(Object savedState) at System.Web.UI.Control.LoadChildViewStateByIndex(ArrayList childState) at System.Web.UI.Control.LoadViewStateRecursive(Object savedState) at System.Web.UI.Control.LoadChildViewStateByIndex(ArrayList childState) at System.Web.UI.Control.LoadViewStateRecursive(Object savedState) at System.Web.UI.Control.LoadChildViewStateByIndex(ArrayList childState) at System.Web.UI.Control.LoadViewStateRecursive(Object savedState) at System.Web.UI.Control.LoadChildViewStateByIndex(ArrayList childState) at System.Web.UI.Control.LoadViewStateRecursive(Object savedState) at System.Web.UI.Control.LoadChildViewStateByIndex(ArrayList childState) at System.Web.UI.Control.LoadViewStateRecursive(Object savedState) at System.Web.UI.Control.LoadChildViewStateByIndex(ArrayList childState) at System.Web.UI.Control.LoadViewStateRecursive(Object savedState) at System.Web.UI.Page.LoadAllState() at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) --- End of inner exception stack trace ---
StackTrace:
Source:
Server Name: BARNEY
This error occurs after creating a new page, then being redirected to the home page instead of the new page, and then clicking Add Page again. This is reproducible until I turn caching off from within Host > Host Settings > Other > Caching
In Installation D, everything works as expected.
On Installation A - C, if caching is turned down to LOW, it is still reproducible. Only turning caching off does the issue go away. Even more interesting is the viewstate issue on Installation C goes away when caching is turned off. My initial thought was that the viewstate error was somehow caused by using the subdomain. We have seen viewstate errors with authentication when jumping from venexus.com to subdomain.venexus.com and back. The only other viewstate errors we have seen is when a session timeout occurs in the middle of a form...which is kinda expected, but should be handled cleanly.
If anyone has seen this issue and knows of the cause, please let us know. We will update this post when we figure out the issue.
Nothing To Install At This Time
Current Assembly Version: 04.00.02
Current Database Version: 04.00.02
If you get the "Nothing to Install At This Time" message when accessing your DotNetNuke 4 portal, you can add the following line to the appSettings in the web.config file:
<add key="InstallationDate" value="3/9/2005" />
I ran into an issue with a DNN site we are developing in DotNetNuke 4 and the ability to install modules from Host > Module Definitions > Add New Module. After selecting the module and clicking Upload, I was immediately redirected to the Module List page, without installing the module. The weird part was that it did not cause an issue with all of the modules I was uploading, only a few of them. Without turning debugging on, and finding the true root of the problem, I simply did the following:
- Dropped the modules I wanted to install into the \Install\Module directory.
- In a browser, navigate to http://www.domain.com/install/install.aspx?mode=installresources
DotNetNuke will then install the module and you are able to continue with your development. Yay!
Most likely you are reading this because you are frantically trying to figure out how to login into your DotNetNuke portal because you have found yourself locked out. You may have even received a password reminder with a blank password. Having fun yet??? When we were first testing DotNetNuke in the DNN 3 beta days, we had a problem with not being able to login into the host account. I fixed the issue by overwritting the host Password and PasswordSalt fields in aspnet_Membership table. Recently, the same issue arose and I had to do this again. So, I decided to jot down a few notes that I hpe will help you in solving your issue. Read on.... Before I explain, lets check to make sure it is not one of the other issues related to not being able to login.
- Clear your cache and cookies and retry to login
- Did you recently upgrade your DotNetNuke site or change the web.config? If so, the passwords are encrypted and stored in the membership provider tables using the machine validation and decryption key strings. They are located in the web.config below the server connection string. You can now thank <insert favorite God> you backed up the DNN installation before upgrading, because you can go back to the old web.config and use the machine keys to upgrade your new web.config file. Look for something like this:
<add key="MachineValidationKey" value="extremelylongrandomlookingstringofcharacterswouldgoinhere" />
<add key="MachineDecryptionKey" value="anothersetofextremelylongrandomlookingstringofcharacterswouldgoinhere" />
- Did you accidentally change the Login page in Admin > Site Settings > Advanced Settings? You can do the following: **NOTE** Make sure you change your PortalID appropriately.
From SQL Server Management Studio or Enterprise Manager, run the following statement:
SELECT TabID, TabName FROM Tabs WHERE (TabName LIKE '%Login%') AND (PortalID = '0')
Find the Tab?
If you get a result, and are sure it is the Login page, run the following SQL Statement to update your settings:
**NOTE** Make sure you have the correct TabID and PortalID!
Update Portals Set LoginTabID = '123' WHERE (PortalID = '0')
You should now be directed to the login page of your portal....
Didn't Find the Tab?
If you did not get a result to the first query and deleted the Login page, you are screwed...just kidding. John Mitchell's Blog provides the solution.
None of those work for you? Join the club!
The solution:
Assuming you have more than one account for your portal (some lowly user account will do), run the following SQL:
SELECT aspnet_Users.UserName, aspnet_Membership.Password, aspnet_Membership.PasswordSalt
FROM aspnet_Membership INNER JOIN aspnet_Users ON aspnet_Membership.UserId = aspnet_Users.UserId
WHERE (aspnet_Users.UserName = 'host') OR (aspnet_Users.UserName = 'someusername')
You should now be able to see the Password and PasswordSalt row you need to use to replace your host account Password and PasswordSalt.
UPDATE aspnet_Membership
SET Password = 'someusernameencryptedpasswordstring', PasswordSalt = 'someusernameencryptedpasswordsaltstring'
WHERE UserID = 'youraspnetuseridforhost'
Now, go to the login page and request your password reminder. You should now have the information you need to login into your portal.
Hope that helps!
UPDATE 3/12/2006:
It may be neccessary to change the ApplicationID to match the portal in use.
The GetSchedule() timeout error:
Error: Schedule is currently unavailable.
DotNetNuke.Services.Exceptions.ModuleLoadException: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding. ---> System.Data.SqlClient.SqlException: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding. at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection) at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection) at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj) at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj) at System.Data.SqlClient.SqlDataReader.ConsumeMetaData() at System.Data.SqlClient.SqlDataReader.get_MetaData() at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString) at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async) at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, DbAsyncResult result) at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method) at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior, String method) at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior) at Microsoft.ApplicationBlocks.Data.SqlHelper.ExecuteReader(SqlConnection connection, SqlTransaction transaction, CommandType commandType, String commandText, SqlParameter[] commandParameters, SqlConnectionOwnership connectionOwnership) at Microsoft.ApplicationBlocks.Data.SqlHelper.ExecuteReader(String connectionString, CommandType commandType, String commandText, SqlParameter[] commandParameters) at Microsoft.ApplicationBlocks.Data.SqlHelper.ExecuteReader(String connectionString, String spName, Object[] parameterValues) at DotNetNuke.Services.Scheduling.DNNScheduling.SqlDataProvider.GetSchedule() at DotNetNuke.Services.Scheduling.DNNScheduling.SchedulingController.GetSchedule() at DotNetNuke.Services.Scheduling.DNNScheduling.DNNScheduler.GetSchedule() at DotNetNuke.Modules.Admin.Scheduling.ViewSchedule.Page_Load(Object sender, EventArgs e) --- End of inner exception stack trace ---
The temporary fix:
Cleaning out the ScheduleHistory table fixes the problem until it gets too full again...
Delete From ScheduleHistory where ScheduleHistoryID > 1
Make sure you backup your database before executing this SQL statement.
I need to investigate more on how the code for GetSchedule() works and how to cleanup the ScheduleHistory more often. Also, we are working with Microsoft on a different issue, they have voiced concern on the performance of the stored proc GetSchedule. I will post any suggestion here when they surface.
While working with Microsoft concerning the DNN SQLDataProvider and 64-Bit SQL Server 2005 Issue, it was suggested that there was a performance issue with GetTab. While this does not help the issue we are having, it did help with performance...
"There are some implicit converts happening even though you have explicit converts in the statements"
Current GetTab SQL:
select TabID,
TabOrder,
Tabs.PortalID,
TabName,
IsVisible,
ParentId,
[Level],
DisableLink,
Title,
Description,
KeyWords,
IsDeleted,
'Url'= case when F2.FileName is null then Tabs.Url else F2.Folder + F2.FileName end,
SkinSrc,
ContainerSrc,
TabPath,
StartDate,
EndDate,
'IconFile' = case when Files.FileName is null then Tabs.IconFile else Files.Folder + Files.FileName end,
'HasChildren' = case when exists (select 1 from Tabs T2 where T2.ParentId = Tabs.TabId) then 'true' else 'false' end,
RefreshInterval,
PageHeadText
from Tabs
left outer join Files on Tabs.IconFile = 'fileid=' + convert(varchar,Files.FileID)
left outer join Files F2 on Tabs.Url = 'fileid=' + convert(varchar,F2.FileID)
where TabId = @TabId
The FIX:
select TabID,
TabOrder,
Tabs.PortalID,
TabName,
IsVisible,
ParentId,
[Level],
DisableLink,
Title,
Description,
KeyWords,
IsDeleted,
'Url'= case when Files.FileName is null then Tabs.Url else files.Folder + Files.FileName end,
SkinSrc,
ContainerSrc,
TabPath,
StartDate,
EndDate,
'IconFile' = case when Files.FileName is null then Tabs.IconFile else Files.Folder + Files.FileName end,
'HasChildren' = case when exists (select 1 from Tabs T2 where T2.ParentId = Tabs.TabId) then 'true' else 'false' end,
RefreshInterval,
PageHeadText
from Tabs
left outer join Files on Tabs.IconFile = 'fileid=' + convert(nvarchar,Files.FileID)
and Tabs.Url = 'fileid=' + convert(nvarchar,Files.FileID)
where TabId = @TabId
Running SQLDiag.exe confirmed the modification helped improve performance. More details later...
I'll post this to the DNN Bug Tracker shortly...
Update 1/25/2006:
Now in Bug Tracker: 2404
I made the following post on the DNN Forums, and decided to post it here in case someone reads it here first...
This is all related to: Upgrading DNN from local SQL Server 2000 to Remote SQL Server 2005
We are experiencing an issue with DNN and a 64-Bit SQL Server 2005 database server that seems to be related to the SQLDataProvider. We are currently running a production web server (Server A) that has an instance of SQL Server 2000 running locally. We have a mixture of DNN3 and NON-DNN sites running on Server A. All DNN sites are fast and run smoothly, only experiencing a few issues during peak traffic times regarding the local SQL Server 2000. Previously we had a separate server for our production SQL Server 2000 databases. However, we recently acquired a very fast 64-Bit server that came from Overture.com (Server C) and had to make room in our rack by decommissioning the old database server after moving all databases to Server A. Now, we are in the process of moving all Server A databases to Server C , so we can go back to using Server A as web server only. We have been testing and planning our database move utilizing our development server (Server B). Our goal is to move ALL Server A databases to Server C.
Server A:
Dell 2850
Dual 3 Ghz Xeons
2 Gb RAM
32-Bit
Windows 2003 Standard Edition
SQL Server 2000
Server B:
Dell 1550
Dual 1 Ghz Pentiums
2 Gb RAM
32-Bit
Windows 2003 Enterprise Edition
SQL Server 2000 Standard Instance
SQL Server 2005 Enterprise Instance
Server C:
Dell 7150
Quad Itanium Processors
12 Gb RAM
64-Bit Windows 2003 Enterprise Edition
64-Bit SQL Server 2005 Enterprise Edition
We began testing the NON-DNN site and DNN site databases against Server B, all with success. We also setup DNN instances on Server B that used Server C as database server. Testing was successful, but all DNN databases tested were less than 100 Mb. We noticed that the DNN sites on Server B that talked to Server C DNN databases were slower, but dismissed it as being on the slower Server B when compared to Server A.
So, after much testing for NON-DNN sites, we moved all NON-DNN databases to Server C. All NON-DNN sites use the SQLOLEDB Provider. Our largest NON-DNN database is over 3.5 Gb. After the move, the site with the largest database experienced great performance/speed improvements. Some larger data transactions were executed in almost half of the time. We were very pleased with the results.
After successful NON-DNN databases move from Server A to Server C, we began moving the DNN databases to Server C. The first 3 were very small databases. However, the largest of the 3, we noticed a difference in speed. Concerned, but determined to move on, we moved a 2.5 Gb DNN database to Server C and gave it a try... The speed was horrible taking as much as 15-45 seconds to deliver a page. We quickly backed out of the upgrade and began our investigation…
Doing a little research, I dug into the DNN documentation for Data Access and looked at the code to see DNN uses System.Data.SQLClient as the provider. Why would SQLOLEDB be fast and the DNN SQLDataProvider be so dreadfully slow and only when on a 64-Bit server? I really have no desire to change any of the core DNN code to use the System.Data.OleDb as the provider to test and see if there is a difference, so any recommedations and/or suggestions are appreciated.
I know there are a few issues with 64-Bit SQL Server 2005 tools running slow: You may experience slow performance when you run 32-bit SQL Server tools on 64-bit operating systems. But, this should not be related to the issue since this concerns just the tools, or does it?
I plan on burning a support call to Microsoft, but would like to gain any insight others might have before I make the call.
Server Error in '/' Application.
Object reference not set to an instance of an object.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.NullReferenceException: Object reference not set to an instance of an object.
Source Error:
An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below. |
Stack Trace:
[NullReferenceException: Object reference not set to an instance of an object.]
DotNetNuke.HttpModules.UrlRewriteModule.OnBeginRequest(Object s, EventArgs e) +702
System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +92
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +64
|
Version Information: Microsoft .NET Framework Version:2.0.50727.42; ASP.NET Version:2.0.50727.42
I have DNN 4.0.2 running on my laptop and frequently get this error. I started getting this error with the first version of DNN 4 and have hoped with each release that it would go away without any luck. I know of another person who is experiencing this error as well. Until I find the solution, this is a placeholder...
We were experiencing the following error 4 times per minute.
Scheduler Exception :
AssemblyVersion: -1
Method:
FileName:
FileLineNumber: -1
FileColumnNumber: -1
PortalID: -1
PortalName:
UserID: -1
UserName:
ActiveTabID: -1
ActiveTabName:
AbsoluteURL:
AbsoluteURLReferrer:
ExceptionGUID:
DefaultDataProvider:
InnerException: Add failed. Duplicate key value supplied.
Message: System.ArgumentException: Add failed. Duplicate key value supplied. at Microsoft.VisualBasic.Collection.Add(Object Item, String Key, Object Before, Object After) at DotNetNuke.Services.Scheduling.DNNScheduling.CoreScheduler.AddToScheduleInProgress(ScheduleHistoryItem objScheduleHistoryItem) at DotNetNuke.Services.Scheduling.DNNScheduling.CoreScheduler.WorkStarted(SchedulerClient& objSchedulerClient)
StackTrace:
Source:
Environment:
DotNetNuke Version: 3.1.1
Data Provider: SqlDataProvider
.NET Framework: 1.1.4322.2032
So, I went into Host > Schedule and started disabling each Scheduled Task until I found the culprit. This was pretty easy to figure out because the only non-core scheduled tasks that was new was the following:
UserPaymentTools.BuyNow.PurgeShoppingCart, UserPaymentTools.BuyNow
AND
UserPaymentTools.BuyNow.ServicePayments, UserPaymentTools.BuyNow
I tried every combination and each task created 2 scheduler exceptions per minute, despite having a frequency of 1 and 3 hours. I have disabled both task and no longer experience the error. I plan on following up with the developer of this module and will post my comments in a separate entry as this is the second major issue I have experienced from 2 modules I have purchased from this individual and did not receive a response from the first one...
If you try to run DNN 3.X using .Net 1.1 AND DNN 4.x using .Net 2.0, make sure you put the sites into separate application pools if they are running on the same server. Not doing so will result in the following error in the event log:
It is not possible to run two different versions of ASP.NET in the same IIS process. Please use the IIS Administration Tool to reconfigure your server to run the application in a separate process.
In versions of IIS before 6.0, each application runs in a seperate process during run time. IIS 6 brings the ability to run spearate application pools and applications that are assigned to different application pools never run in the same process. So this was all new to me
So, to change it is quite simple...
To create a pool designation in IIS 6.0
- Open the IIS management console and expand the local computer by clicking the plus sign.
- Right-click the Application Pools folder, point to New, and then click Application Pool. The Add New Application Pool dialog box appears.
- Enter the new pool designation in the Application pool text box, and then click OK.
To assign a pool designation to an ASP.NET application in IIS 6.0
- Open the IIS management console, expand the local computer by clicking the plus sign, and navigate to the folder that contains the ASP.NET application.
- Right-click the application and then click Properties. The application's properties dialog box appears.
- On the Directory tab, select the desired pool designation from the Application Pool list.
Configuring an ASP.NET Application for an ASP.NET Version
InnerException: The incoming tabular data stream (TDS) remote procedure call (RPC) protocol stream is incorrect. Parameter 1 ("@rawQuery"): Data type 0xE7 has an invalid data length or metadata length.
This is here as a placeholder because I have a feeling this is going to come up agaqin soon...We experieced this issue with a DNN module that called a stored proc on a database that was not located on the same server as where the DNN installation lived and a different database than the DNN database.
0xE7 = 231, which is correct for nvarchar. Running SQL Profiler, no trace of the stored proc being run was found.
**NOTE** The stored procedure that is being called is NOT in the DotNetNuke database.
We tried the following cases with interesting results:
Error Case:
Server A (Windows 2003 Standard running IIS), connecting to Server B (remote SQL Server 2005 database). ERROR = TRUE
Test Case 1:
Server A (Windows 2003 Enterprise running IIS), connecting to local SQL Server 2000 database. ERROR = FALSE
Test Case 2:
Server C (Windows 2003 Standard running IIS), connecting to local SQL Server 2000 database. ERROR = FALSE
Test Case 3:
Server A (Windows 2003 Enterprise running IIS), connecting to Server C (remote SQL Server 2000 database). ERROR = FALSE
Test Case 4:
Server C (Windows 2003 Standard running IIS), connecting to Server B (remote SQL Server 2005 database). ERROR = TRUE
Test Case 5:
Server D (Windows 2003 Standard running IIS), connecting to local SQL Server 2005 database. ERROR = TRUE
See the pattern? So, this definitely points to an SQL Server 2005 issue. This lead us down the route of changing the provider to see if the module would work. And guess what? It did. The error goes away. WTF? No time to run a packet sniffer. I am logging this here as a great mystery to solve some other time.
Update 1/9/2005:
During validation of a byte-ordered user-defined type passed through RPC, user-defined type validation performs de-serialization/re-serialization of the user-defined type and requires that the resulting bytes be exactly the same as the original. If the validation fails, you will see the error:
"System.Data.SqlClient.SqlException, Incoming TDS RPC protocol stream is incorrect. Parameter 1 ("<ParameterName>"): The supplied value is not a valid instance of data type <TypeName>. Check the source data for invalid values." - Reference: http://support.microsoft.com/default.aspx?scid=kb;en-us;910228 in section 4.1.4
I am getting the following error randomly on a localhost install of DNN on my laptop. Restarting IIS fixes the problem until it randomly occurs again.
Server Error in '/' Application.
Object reference not set to an instance of an object.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.NullReferenceException: Object reference not set to an instance of an object.
Source Error:
An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below. |
Stack Trace:
[NullReferenceException: Object reference not set to an instance of an object.]
DotNetNuke.HttpModules.UrlRewriteModule.OnBeginRequest(Object s, EventArgs e) +1123
System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +92
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +64
|
This is a placeholder until I find the solution....
Not to self: Is this a session timeout issue? Seems like it happens after a long duration has passed before returning to localhost. Dig through the logs and look
Lee Sykes of DNN Creative informed me this morning that there is an issue with modules that dynamically change the title.
Line 50 in CDefault.vb is commented out:
'Public Title As String = ""
This will cause many modules that use this property of CDefault to dynamically set the page title to break.
Source
I know this will cause some errors. I have several modules that alter the page title based on content for search engine optimization. This will definitley delay any upgrade we do from DNN 3 to DNN 4 in our production environment if it takes longer than 1 month for the next patch/release. I will post any updates here.
I successfully updated our development environment with DNN 4.0.1.
See below:
Current Assembly Version: 04.00.01
Current Database Version: 04.00.00
Upgrade Status Report
00:00:00.031 - Upgrading to Version: 4.0.1
00:00:00.750 - Performing General Upgrades
00:00:01.140 - Installing Module File D:\DNN4.0\Install\Module\Announcements.zip:
00:00:01.531 - Installing Module File D:\DNN4.0\Install\Module\Announcements_3.1_Install.zip:
00:00:01.968 - Installing Module File D:\DNN4.0\Install\Module\Contacts_3.1_Install.zip:
00:00:02.203 - Installing Module File D:\DNN4.0\Install\Module\Discussions_3.1_Install.zip:
00:00:02.500 - Installing Module File D:\DNN4.0\Install\Module\Documents_3.1_Install.zip:
00:00:02.750 - Installing Module File D:\DNN4.0\Install\Module\Events_3.1_Install.zip:
00:00:03.140 - Installing Module File D:\DNN4.0\Install\Module\FAQs_3.1_Install.zip:
00:00:03.375 - Installing Module File D:\DNN4.0\Install\Module\Feedback_3.1_Install.zip:
00:00:03.546 - Installing Module File D:\DNN4.0\Install\Module\HTML_3.1_Install.zip:
00:00:03.765 - Installing Module File D:\DNN4.0\Install\Module\IFrame_3.1_Install.zip:
00:00:03.968 - Installing Module File D:\DNN4.0\Install\Module\Image_3.1_Install.zip:
00:00:04.125 - Installing Module File D:\DNN4.0\Install\Module\Links_3.1_Install.zip:
00:00:04.453 - Installing Module File D:\DNN4.0\Install\Module\NewsFeeds_3.1_Install.zip:
00:00:04.625 - Installing Module File D:\DNN4.0\Install\Module\Survey_3.1_Install.zip:
00:00:06.875 - Installing Module File D:\DNN4.0\Install\Module\UserDefinedTable_3.1_Install.zip:
00:00:08.406 - Installing Module File D:\DNN4.0\Install\Module\UsersOnline_3.1_Install.zip:
00:00:08.797 - Installing Module File D:\DNN4.0\Install\Module\XML_3.1_Install.zip:
Upgrade Complete
Our Development Environment
Web Server:
Dell 1550 Dual 1 Ghz processors with 2 Gb RAM
Windows 2003 Stadard Edition with Service Pack 1
Database Server:
Dell 7150 Quad Itanium processors with 12 Gb RAM
Windows 2003 Enterprise Edition with Service Pack 1 (64 bit)
Microsoft SQL Server 2005 Enterprise Edition (64 bit)
DotNetNuke:
DotNetNuke Version: 4.0.1
Data Provider: SqlDataProvider
.NET Framework: 2.0.50727.42
ASP.NET Identity: NT AUTHORITY\NETWORK SERVICE
I have confirmed that the DNN Search module errors I had experieced in DNN 4.0.0 have been fixed. As commented on the DNN 4.0 and Search Module Errors post by
Out of the box, DNN 4.0 Search is broken. A search test showed the following:
In the Log Viewer I see the following errors:
ModuleId: -1
ModuleDefId: -1
FriendlyName:
ModuleControlSource:
AssemblyVersion: 04.00.00
Method: System.Web.UI.Util.CheckVirtualFileExists
FileName:
FileLineNumber: 0
FileColumnNumber: 0
PortalID: 0
PortalName: My Website
UserID: 1
UserName: host
ActiveTabID: 37
ActiveTabName: Search Results
AbsoluteURL: /Default.aspx
AbsoluteURLReferrer:
ExceptionGUID: d7404334-fde9-4910-adea-52b19d7d8278
DefaultDataProvider: DotNetNuke.Data.SqlDataProvider, DotNetNuke.SqlDataProvider
InnerException: The file '/DesktopModules/SearchResults/SearchResults.ascx' does not exist.
Message: DotNetNuke.Services.Exceptions.ModuleLoadException: The file '/DesktopModules/SearchResults/SearchResults.ascx' does not exist. ---> System.Web.HttpException: The file '/DesktopModules/SearchResults/SearchResults.ascx' 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) at System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert(HttpContext context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile) at System.Web.UI.TemplateControl.LoadControl(VirtualPath virtualPath) at System.Web.UI.TemplateControl.LoadControl(String virtualPath) at DotNetNuke.UI.Skins.Skin.InjectModule(Control objPane, ModuleInfo objModule, PortalSettings PortalSettings) --- End of inner exception stack trace ---
StackTrace:
Source:
Server Name: BARNEY
I have confirmed that '/DesktopModules/SearchResults/SearchResults.ascx does not exist and have yet to find where it's real location is.
ModuleId: -1
ModuleDefId: -1
FriendlyName:
ModuleControlSource:
AssemblyVersion: 04.00.00
Method: System.Web.UI.UserControl.get_Request
FileName:
FileLineNumber: 0
FileColumnNumber: 0
PortalID: 0
PortalName: My Website
UserID: 1
UserName: host
ActiveTabID: 37
ActiveTabName: Search Results
AbsoluteURL: /Default.aspx
AbsoluteURLReferrer:
ExceptionGUID: 761ae1d9-b426-4dee-af03-f371eb81af25
DefaultDataProvider: DotNetNuke.Data.SqlDataProvider, DotNetNuke.SqlDataProvider
InnerException: Object reference not set to an instance of an object.
Message: DotNetNuke.Services.Exceptions.ModuleLoadException: Object reference not set to an instance of an object. ---> System.NullReferenceException: Object reference not set to an instance of an object. at System.Web.UI.UserControl.get_Request() at DotNetNuke.Entities.Modules.PortalModuleBase.get_IsEditable() at DotNetNuke.UI.Containers.Title.CanEditModule() in D:\Venexus\DNN4.0\Admin\Containers\Title.ascx.vb:line 52 at DotNetNuke.UI.Containers.Title.Page_Load(Object sender, EventArgs e) in D:\Venexus\DNN4.0\Admin\Containers\Title.ascx.vb:line 82 --- End of inner exception stack trace ---
StackTrace:
Source:
Server Name: BARNEY
ModuleId: -1
ModuleDefId: -1
FriendlyName:
ModuleControlSource:
AssemblyVersion: 04.00.00
Method: DotNetNuke.UI.Utilities.DNNClientAPI.EnableMinMax
FileName:
FileLineNumber: 0
FileColumnNumber: 0
PortalID: 0
PortalName: My Website
UserID: 1
UserName: host
ActiveTabID: 37
ActiveTabName: Search Results
AbsoluteURL: /Default.aspx
AbsoluteURLReferrer:
ExceptionGUID: c9460ab3-3704-4c8b-a55d-d0d63a4a1bea
DefaultDataProvider: DotNetNuke.Data.SqlDataProvider, DotNetNuke.SqlDataProvider
InnerException: MinMax persistance type of cookie requires a ModuleId
Message: DotNetNuke.Services.Exceptions.ModuleLoadException: MinMax persistance type of cookie requires a ModuleId ---> System.Exception: MinMax persistance type of cookie requires a ModuleId at DotNetNuke.UI.Utilities.DNNClientAPI.EnableMinMax(Control objButton, Control objContent, Int32 intModuleId, Boolean blnDefaultMin, String strMinIconLoc, String strMaxIconLoc, MinMaxPersistanceType ePersistanceType, Int32 intAnimationFrames) at DotNetNuke.UI.Containers.Visibility.Page_Load(Object sender, EventArgs e) in D:\Venexus\DNN4.0\Admin\Containers\Visibility.ascx.vb:line 216 --- End of inner exception stack trace ---
StackTrace:
Source:
Server Name: BARNEY
After further research I found a fix on ecktwo's website: DNN Search for 4.0.0
UPDATE: This issue was fixed in DNN 4.0.1 release
The first thing I noticed when I selected the dropdown for modules was that many were missing.
Where are the other core modules??? They appear in the correct folder:
I am not sure why this happened, but to fix it, I simply unzipped DotNetNuke_4.0.0_Install.zip to a new folder and using Host > Module Definitions > Upload New Module, uploaded each module found in \Install\Module
After uploading the modules and installing them, all seems well and I successfully added a new Text/HTML module into the Home page and edited it without incident.
UPDATE: Read Cathal's Comments
I had installed DotNetNuke 4.0 on a Windows 2003 Standard box using a remote SQL Server 2005 Enterprise database on a development box earlier tonight. I had navigated around doing a few things and paused in the middle of updating the host account. I might have reached the session expiration time before I returned, but I decided to update the host password and clicked update. This is the error that was returned:
Unhandled Error
Error Details
| File |
|
| Error |
An error has occurred while establishing a connection to the server. When connecting to SQL Server 2005, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server) |
I believe this means I need to allow named pipes because by default SQL Server 2005 does not allow this type connection. I was not aware that DNN used Named Pipes and I did not see anything concerning this in the Installation help. So, this is how you change it....
- Start > All Programs > Microsoft SQL Server 2005 > Configuration Tools > SQL Server Surface Are Configuration
- Once opened, use Surface Area Configuration for Services and Connections
- Select Using both TCP/IP and named pipes
- A notification that the Database Engine must be restarted before it takes effect will be displayed. You can restart the engine from Admin Tools > Services and restart SQL Server (MSSQLSERVER)
I am assuming this is all that is required. I will post a comment here if I encounter this error again.
At the end of the DNN 4.0 install on Dev, I encountered the following error:
Installation Complete
Unhandled Error
Error Details
| File |
|
| Error |
Unable to generate a temporary class (result=1). error CS2001: Source file 'C:\WINDOWS\TEMP\vsl59tus.0.cs' could not be found error CS2008: No inputs specified |
System:
Windows 2003 with Service Pack 1
DNN 4.0
SQL Server 2000 on local machine.
The answer is to give Network Services full permissions for C:\WINDOWS\TEMP and C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727
I might have missed this in the Installation instructions, but I sure did not see it in there that it was required to give permissions to the Temp folder. Anyway, it's working now. I will be testing against a remote SQL Server 2005 shortly...
A DotNetNuke site I have been working on that has some decent traffic, was experiencing an occasional Out of Memory Error. During peak traffic times, IIS would crap out and throw the error. IISReset was neccessary sometimes to alleviate the issue...very frustrating.
Here is the error:
InnerException: Exception of type System.OutOfMemoryException was thrown.
Message: DotNetNuke.Services.Exceptions.PageLoadException: Exception of type System.OutOfMemoryException was thrown. ---> System.OutOfMemoryException: Exception of type System.OutOfMemoryException was thrown. --- End of inner exception stack trace ---
Environment:
- DotNetNuke 3.1
- Windows 2003 Server
- All of the latest patches/service packs
- MS SQL Server 2000
- 1.6 Gb Database size
- Dual 3 Ghz Xeons with 2 Gb RAM Dell 2850
After digging into logs and looking around Host > Schedule, I noticed that the errors coincided with the DNN Search Indexer schedule, so I stopped it. This helped for a bit, but as the site continued to grow (over 500,000 pages), the error began reappearing.
I had tried a few other things to get rid of the issue without success. For example, under Host > Schedule I enabled DotNetNuke.Services.Cache.PurgeCache, DOTNETNUKE and was purging every 30 minutes. I thought surely this would be the answer, kicking myself for not enabling it earlier. However, to my disappointment, the error persisted. ARRRRRRRR!
I feel strongly that SQL Server should be on it's own server, but due to a server shuffle in our rack and decommisioning an older server to make room for 3 other servers, we have been using a single server for both IIS and SQL Server for this site. We are working through a few Remote Procedure Call errors with DNN 3.x and 4.0 and SQL Server 2005 (will discuss in later post) and were forced to use this setup. This error would surely go away when we move our production database to our Quad Itanium Processor server with 12 Gb RAM, but unfortunately this was not an option. So, I started digging through MSDN and found the Server Memory Options.
"Use max server memory to prevent SQL Server from using more than the specified amount of memory, thus leaving remaining memory available to start other applications quickly. SQL Server does not immediately allocate the memory specified in max server memory on startup. Memory usage is increased as needed by SQL Server until reaching the value specified in max server memory. SQL Server cannot exceed this memory usage unless the value of max server memory is raised." - MSDN
So, I decided to give it a try...This is what I did:
- Opened Enterprise Manager
- Expanded the server group
- Right-clicked the server
- Clicked Properties
- Clicked the Memory tab
- Under Dynamically configure SQL Server memory, lower the Maximum
This seems to have worked. MS SQL Server is such a pig. By putting it on a diet and setting max server memory, the error has disappeared. I decided to do some testing and was beating up the server pretty bad with several crawlers/spiders I have built and was hitting the site hard. The only error I experienced during my testing was an occasional deadlock victim error, which is expected with the number of transactions taking place on this database. I will live with a temporary error over an IIS crash anyday. Moving everything back to seperate servers for IIS and SQL Server should help greatly for a DNN site of this size. Let's just hope the DNN team can knock out a few crtitical issues with RPC and SQL Direct provider.
|
Copyright © 2009 Venexus, Inc.. All rights reserved.
|
|