Hi all, I'm trying to help some people over in the Map Module forum with an error they're seeing when using the module on DNN 5.0.1. I'm not sure whether everyone with 5.0.1 is experiencing this, but there have certainly been 3 people this week with the same problem and symptoms. I can confirm this doesn't happen on my 4.9.2 installation and no-one else with 4.x.x has reported this either.

Basically, when trying to add a Map Point, an error is generated: "Conversion from string "0500-01" to type 'Integer' is not valid."

I've looked at the Stack trace and the offending line is: If CInt(Me.ControlPanelModule.PortalSettings.Version.Replace(".", "")) > 451 Then and that line is located in the DotNetNuke.Modules.Map.Components.ControlPanelBase.setUrlControl(UrlControl& Control TextBox& TextControl String value) procedure.

 ControlPanelBase inherits from DotNetNuke.Entities.Modules.PortalModuleBase and it's from here that the PortalSettings.Version property is derived.

What appears to be happening is that instead of the Version property having a value of "5.0.1", it has a value of "0500-01" and the CInt function call above throws the error as you would expect.

Unfortunately I don't have a runnable dev environment to try and figure out why this property is set incorrectly and I failed in my attempts last night to track back through reams of core code to work out where and how it is set.

Is there anyone who has a better knowledge of the Core Code who would be able to help me help these guys by figuring out how and why this property is being set incorrectly?

Please do shout if you need any more information. The Map Forum thread can be found here, but I warn you, the formatting is messed up due to a very large post with log dump data in it!

Right, after doing the install of a dev version of DNN 5.0.1 myself I've found the bug.

In 4.9.3 (and I assume previous versions to this also), a global variable glbAppVersion of type String was populated with "04.09.03". This was then converted to the version number used throughout the framework via the following code in PortalSettings.vb:

' get application version
Dim arrVersion As Array = glbAppVersion.Split(CType(".", Char))
Dim intMajor As Integer = CType(arrVersion.GetValue((0)), Integer)
Dim intMinor As Integer = CType(arrVersion.GetValue((1)), Integer)
Dim intBuild As Integer = CType(arrVersion.GetValue((2)), Integer)
Me.Version = intMajor.ToString + "." + intMinor.ToString + "." + intBuild.ToString

This resulted in a Version property that returned "4.9.3".

The new core framework does things differently as follows:

The string "05.00.01" is assigned to public variable glbAppVerion which is turn assigned to a private variable _ApplicationVersion of type System.Version. This was then converted to the version number used throughout the framework via the following code in PortalSettings.vb:

'get application version
'Me.Version = ApplicationVersion.Major.ToString("00") + "." + ApplicationVersion.Minor.ToString("00").ToString + "." +  ApplicationVersion.Revision.ToString("00")

This results in a Version property that returns "05.00.-01"

There are two problems here:

1. Firstly, notice that in the 4.9.4 code, the third part of the string used is the Build property and not the Revision property as used in 5.0.1. The overloaded string constructor for System.Version expects a string in the format "Major.Minor.Build.Revision". In this case it's receiving only "Major.Minor.Build" so it assigns "-1" to the Revision property. The returned string therefore has "-01" at the end because there was no Revision value assigned. If the Revision property is the value needed, then the string value glbAppVersion set up initially in Assembly.vb should be "05.00.00.01". If however, the core should be using the build number, then glbAppVersion should remain as "05.00.01" and the assignment above should be changed from ApplicationVersion.Revision.ToString("00") to ApplicationVersion.Build.ToString("00").
2. The second problem is that there is a discrepancy in the format of the Core's PortalSettings.Version property. In 4.9.3, the format returned is "4.9.3" and in 5.0.1 the format returned is "05.00.01". Is this intentional? The result for the Map Module I mentioned in my first post is that despite resolving the correct number now ("05.00.01"), this will result in unintentional functionality in the Map Module as it is expecting "5.0.1" and manipulates that string according to strip out the decimal points. This results in an INTEGER value of 501 which it uses to compare against "451" to make sure that the framework is up to date enough to support the Map. The new format of "05.00.01" will result in an integer value of 5001 which although achieving the same result when it checks against "451", this is obviously not desirable as it's luck more than intention. So, is this new, different format correct? If it is here to stay then a bug will need to be entered against the Map Module as well as the Core.

If anyone from the Core Team can answer question number 2 I'd be grateful so that I know whether to enter a bug against the Map Module. In the meantime, I'll be entering a bug entry for the Core.

Personally, I'm thinking this problem may have other, more serious implications for other modules!

Right, I'm going to update the guys in the Map Module forum, then I'm off for a lie down - my head hurts

Thanks for the clarification Charles, i'll see if I can help the guys in the Map forum by building them a temporary fix of the DLL on the proviso that it'll break at some point in the future.

I should just state the obvious though and say that there's still a current problem with the core returning the wrong value for the last part of the version number (currently "-01"). Any module or component trying to use this version number right now to do proper version comparisons as you say, is getting the wrong value. It just seems that right now all we've caught is the Map Module.

However, I notice that Alex Shirley has updated the bug I raised already so I'll leave it in your capable hands!