Issue Detail

Lot of logs in Event Viewer related with "Scheduler Exception -Sequence contains more than one matching element". This occurs when there is a duplicate entry in the WebServers table.

Solution

To verify if this is the issue, go to Host > SQL and run the following SQL query:

SELECT ServerName FROM {databaseOwner}[{objectQualifier}WebServers]

If you see the same entry more than once, you need to run the following SQL query:

DELETE FROM {databaseOwner}[{objectQualifier}WebServers]

Once that has been completed, hover over Tools->Recycle Application Domain to make it work with re-indexing.

Referrence

Scheduler Issues in DNN 7.3.x

Scheduler exception after Upgrade to 7.3.0

DNN 7.3.1 SCHEDULER EXCEPTION

Well, let us get started to fight DNN Bugs again. This is the forth post we discussed about DNN bugs and share workarounds with you. The last posts as follows below:

1. Fighting DNN Bugs: All Handlers Not Work
2. Fighting DNN Bugs Ⅱ: Why Can't Remove Google Analytics
3. Fighting DNN Bugs Ⅲ: Why Non-Administration Users Logged Out

which you also are interested in reading.

Today we would like to share the bug is about spammer, mainly about spammer registrations/login attempts. When looking/monitoring Admin -> Event Viewer, there are a ton of event log recorded off type "Login failure" or "New user", then your website should have been hit by an old robot-script written specifically to target DNN website.

What is Highlight.js?

Highlight.js is a syntax highlighter written in JavaScript. It works in the browser as well as on the server. It works with pretty much any markup, doesn’t depend on any framework and has automatic language detection.

Project on Github

Next we would like to show you how to integrate DNN Blog with Javascript syntax highlighter - Highlight.js with some simple steps. Enjoying it soon :)

If you are developing a slightly complex DNN module, how to pack it in the installation package with DNN module manifest should be one important task. It will make your module looks elegant and better flexibility - reasonable folder structure, clean installation points, easy maintenance. We recommend that you should follow up the top 5 tips Bruce Chapman mentioned in this article below:

Top 5 DotNetNuke Manifest file Module Packaging Tips

1. Use Html in the File for better layout in the install pages
2. Use a resources.zip file for all your files
3. Use a html file for your Licence Agreement
4. Make your module DNN 4.x and DNN5.x compatible by using two separate manifest files.
5. Use the ‘sourceFileName’ attribute for your assembly files.

And refer to official wiki and guideline of DNN manifest schema:

Types of Manifests

The DNN Manifest Schema

Right now we found out that the node of releasenotes only can be used like that：

<releaseNotes src="Installation\ReleaseNotes\Release.07.03.00.txt"></releaseNotes>

Wrong usage： (Who know why?)

<releaseNotes> 
   <releaseNote src="Installation\ReleaseNotes\Release.07.03.00.txt"/> 
</releaseNotes>

Today I just got a very annoying error with one DNN7 fresh installation in Windows 7 x64 machine. Which is;

Compiler Error Message: CS0016: Could not write to output file 'c:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\DNN7\62d43c41\27d749ca\xx_xxx.dll' – 'Access denied.'

Here is solution which I have found. What you have to do is just assign the following folders with IIS_IUSRS and NETWORK SERVICE users with the full control permission:

1) C:\Windows\temp

2) c:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files

Once you applied those setting, restart your IIS and try to run your application again. The error should be gone by now.

Hope that this post will help you to fix the problem as I did and if you have found any other fix's please leave feedback and I will post them up.

----------------------------------------------------------

Resources links:

Local IIS 7.0 - CS0016: Could not write to output file / Microsoft.Net > Framework > v4.0.30319 > Temporary ASP.NET Files

“CS0016: Could not write to output file” error when starting an app in IIS 7

As you know, the simple method GetTab(int tabid) was obsolete and has been replaced by GetTab(ByVal TabId As Integer, ByVal PortalId As Integer, ByVal ignoreCache As Boolean). If you want to call the new method, we have to pass the additional parameter “PortalId”.

In common,  the object PortalSettings can be easy to get with DNN context, such as special dnn module & page; however, it may be inaccessible in some sceneries, such as separate aspx page or handler. Then is there any way to get the correct tab info with this new method? Now there is a simple trick to do it with passing into Null.NullInteger as the parameter PortalId. So the coding looks like that:

var tabController = new TabController();
var blogPage = tabController.GetTab(tabID, Null.NullInteger, false);

Deeping into the source code, you will find out that it always tries to get the correct PortalId for this tab/page object:

//if we do not know the PortalId then try to find it in the Portals Dictionary using the TabId
portalId = GetPortalId(tabId, portalId);

//if we have the PortalId then try to get the TabInfo object
tab = GetTabsByPortal(portalId).WithTabId(tabId) ??
        GetTabsByPortal(GetPortalId(tabId, Null.NullInteger)).WithTabId(tabId);

Hope this trick & tip helps if someone has the same issue.

Currently we are fixing a really weird issue that only happens with non-administration users.

When the user logs in and accesses one page, they are logged out of the system. The page finishes loading as if they were logged in, but once they try any other actions, such as clicking any module section menu (including refreshing the browser page) they are considered not logged in and presented with a login prompt.

After looking it into for a while, we found that this always seems to happen when this module requests my custom ashx web call, which was killing dnn authentication cookies and logging out non-administrator users. Later we made some search about reasonable solution – fortunately we found the helpful post exactly with the same issue -  Why is DNN killing my authentication cookies when I access an ashx from a child portal?

As the answer mentioned below:

This occurs because the user is only defined in the child portal, but the request to the ASHX occurs (from DNN's perspective) in the parent portal. When DNN receives the request, it sees that you've "switched portals," no longer have a valid identity, and removes your authentication information. This doesn't occur for super users because they do have a valid identity across both portals.

To fix this issue, you need to add a querystring parameter to your request with the portal ID. This let's DNN disambiguate the request and keep your authentication intact.

For example, the coding of our case will be modified as follow:

var path = PortalSettings.HomeDirectory + objFile.Folder + objFile.FileName;
var resizedUrl = string.Format("~/desktopmodules/my_module_name/imagehandler.ashx?portalid={0}&path={1}", 
                                PortalSettings.PortalId, path);

return ResolveUrl(resizedUrl);

As our popular blogging module #SunBlogNuke applied in more and more websites, it may fit most user sceneries for clients but actually some awesome features also hidden in the background. Today we would like to share you 5 killer features you should be interested in. Let us get started the investigation now.

Well, let us get started to fight DNN Bugs again. This is the second post we discussed about DNN bugs and share workarounds with you. The first post is Fighting DNN Bugs: All Handlers Not Work, which you also are interested in reading.

It is so tired and uninteresting process but we we have to deal with them for our websites or clients if they requested. DotNetNuke is indeed the most excellent/great CMS at the first look but when going ahead, there are lots of issues/bugs to challenge your ability and patience. One of our client ever complained that there were lots of error filled in the event logs of their websites, and mainly indicated that "Object reference not set to an instance of an object". You look, so little information is not enough to investigate those issues and identify the problem that we can do nothing excerpt clearing the event logs to make us feel happy for a while. Yes, the community version is free however that is the big price when issues occurred. Some times we can look for helps in the silent forum but most times we have to fix them ourselves.

More frustrating things are that some bugs exists cross two major versions,  such as DNN6-DNN7 and still not fixed now even though they are created into issue tracker.  Well, if they are ignored with the official guys, let us check them out and address some workaround to fix them forever or temporarily.

Today we would like to share the bug is about Google Analytics Tracking. From DNN v6.0, the core package included the built-in module for Google Analytics Tracking. It looks indeed an awesome thing for us because we don’t have to trick these coding in the skin from the scratch. However, sarcastically one day we would like to disable the Google Analytics with some reasons, DNN only said NO WAY :(

How to reproduce this bug:

1. Go to Admin/Google Analytics page.
2. Fill in any value into the tracking ID field
3. Click to update and make it active. Everything looks nice :)
4. Again when I filled the empty value for tracking ID and hope that it should be inactive, the simple form just said that the field is required and can’t be empty. 
5. Try to update, failure, update, failure… Nothing can’t be done any more and Google Analytics tracking coding always showed in every page.

How to fix it

Currently there seem to be some workarounds as follows:

1) Go to your site's root folder and find the siteanalytics.config file, COMMENT OUT or DELETE everything inside the CDATA tag.

2) Analytics settings are stored in file GoogleAnalytics.config, residing in portal root directory, such as portals/x/subdir(x is the portal id). Deleting the file will erase your settings.

3) Go to the folder $ROOT/DesktopModules/Admin/Analytics and find the GoogleAnalyticsSettings.ascx file. COMMENT OUT or DELETE the RequiredFieldValidator.

The 3) way is the one what I recommend and will fix all the issues – you don’t have to check out all the portals but the disadvantage is to be overwritten in the next upgrade. As the point of DNN module developer, it is meaningless to make this tracking id mandatory.

If you have any question or thoughts about this topic, please feel free share it in the comment. Thanks.

Resources links discussed the same issue above:

Can't Remove Google Analytics Tracking

Removing Google Analytics from your DNN site

Other issues addressed about DNN7 you may interested in:

After upgrading to DNN 7.1.2 Site Settings doesn't work

After upgrading to DNN 7.1 OpenSearch and DNN Preview Search doesn't work

Change the Space character in Advanced URLs with DNN 7.1

After integration SunBlogNuke with Window Live Writer, you may wonder where to find or what to replace the excerpt field in the built-in edit post panel. There is one elegant workaround – using the <!--more--> tag to mark the end of the excerpt. Fortunately, there is a setting property called "supportsExtendedEntries" in the wlwmanifest.xml depending on the feature. Please note that setting this value to true will allow the <!--more--> tag in your Window Live Writer. 

What you need to accomplish is placing your cursor where you want the “Read More” tag and selecting “Split Post” from the “Format” menu. Then the collection page and simple entry partial will be modified to have a "Read More" link whenever there is extended content. Have  a look at the screenshot as follows:

Also you can see the more features integrated with WLW, for example, keyword, category and slug etc. :)