DNN ability to ‘Publish Web Site’

3 years ago I’ve posted a workaround regarding DNN

BUG App_GlobalResources and ‘Publish Web Site’ in VS2005

The issue 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)

Advertisements

Do not pass data between static methods using static data members.

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)

{

_dataToPass =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.

The issue is well known(e.g. see Statics & Thread Safety: Part I   and Part 2 ), but I decided to write about it again.

Helper String function to TrimLength

            /// <summary>
            /// If lenght of the string is greater than max allowed, remove the end
            /// </summary>
            /// <param name=”str”></param>
            /// <param name=”maxLength”></param>
            /// <returns></returns>
            public static string TrimLength(string str, int maxLength)
            {
                if (str.Length > maxLength)
                {
                    str = str.Remove(maxLength);
                }
                return str;
            }

Possible errors when using Web Setup project to upgrade version, that was XCopied

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…

DotNetnuke 4.4 RewriterUtils.RewriteUrl breaking change in adding QueryString.

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.

DotNetNuke changes in Web.Config from 4.0.3 to 4.4

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.Services.Upgrade.ExecuteScripts method

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? “