3 years ago I’ve posted a workaround regarding DNN
is still not resolved and I recently received an email
I would like to thank you a lot for your post on a DNN forum which explain how to use DNN in precompiled mode.
( AppGlobalRessources…… )
T H A N K S !!!!!!!!!!
I am glad that the workaround is still useful, but DNN team should create a new version(even with breaking changes)
In one of static class in our application, I found local static members that were used to pass data between calls of static methods.
It’s wrong and can cause errors that are intermittent and very hard to reproduce.
The problem will happen if the same code executed for 2 users simultaneously. In this case value for one user could be used for the second user and result will be unpredictable.
The code was similar the following:
public static class HelperClass
private static string _dataToPass = “”;
static void Method1(string param)
static void Method2()
//logic based on _dataToPass value;
The pattern is popular for instance object, when one method saves state in the instance, and other method use it, but it is not acceptable for static class.
Consider to use singleton pattern, if you have shared for the domain object.
/// If lenght of the string is greater than max allowed, remove the end
/// <param name=”str”></param>
/// <param name=”maxLength”></param>
public static string TrimLength(string str, int maxLength)
if (str.Length > maxLength)
str = str.Remove(maxLength);
I am using Web Setup project to install Web Site Project(customized version of DotNetNuke). It installs a lot of DLL with meaningless names(like App_Web_42q_drww.dll) into BIN directory.
If user upgrades later to the new version of the project MSI installer seems smart enough to delete old DLLs and install another set of DLLs with different unfriendly names.
The problem happens if site to upgrade wasn’t installed using Web Setup MSI, but was XCopied.The sample scenario is the following:
An administrator installed web Application into virtual directory MyWebApp1. Then the administrator made a copy of application MyWebApp1Copy.
On teh time of upgrade he/she decided to apply upgrade directly to MyWebApp1Copy virtual directory. In this case old set of DLLs in BIN is not deleted, but both old and new co-exist. It causes different errors like
Compiler Error Message: BC30456: ‘InitializeCulture’ is not a member of ‘ASP.default_aspx’.
The simplest way to workaround the mess is to rename the web apllication folder and install your application as new.
Related thread : BC30456: ‘InitializeCulture’ is not a member of…
I am using modified version of DNN HttpModulesUrlRewriteUrlRewriteModule,
in particular I am calling their Friend RewriterUtils.RewriteUrl function. In 4.0.3 version it expected URL parameter without QueryString and added queryString from context.Request.QueryString inside the function.
But in 4.4. my code stopped working.
The reason was that they removed the code to add querystring information from the function and made it responsibility of a caller.
It certainly makes sense, but it will be easier for me(and other developers), if comments with description how function works and what the changes are done will be added to the source code.
It is the expected code style for open source project.
I moved from DNN 4.0.3 to DNN 4.4 and noticed that there are significant web.config changes (actually as a part of 4.3 Membership Services Provider Abstraction ).
However I didn’t find any clear documentation about Web.Config changes.
From my understanding the folowing changes happened:
1. Microsoft ASP.NET membership defaultProvider changed from “DNNSQLMembershipProvider” to standard MS AspNetSqlMembershipProvider –System.Web.Security.SqlMembershipProvider.
2.roleManager and profile providers sections were deleted from system.web section of web.config.
3. New sections “members“,“roles“,“profiles” were added to “dotnetnuke“ sectionGroup
DotNetNuke function Upgrade.ExecuteScripts(ByVal strProviderPath As String)
actually doesn’t use strProviderPath, but always uses ApplicationMapPath & “InstallScripts” folder.
It reads all files in the folder and deletes them after execution.
It is also triggered only by InstallDNN.
The behavior is different to installmodules folder, where modules are installed also during UpgradeDNN.
The issue reported here(in comments).
I’ve also asked a question in DNN Forums “Is “installscripts” folder obsolete? “