LIeber Sebastian,
I wish I were more in practice with my German. Thank you for replying. This is a bit detailed, bear with me.
We're on Windows Server 2003. I checked and made sure the Network Service account on a known working site has the same access on the site in question. I don't know how to check that files are unblocked but I'll google that. This has not been an issue before so I don't believe any sort of file blocking is in play.
Note, the Library file is not in the Website/ path. The upgrade instructions I have only state to take a Version-Upgrade.zip and extract it over the /website folder. From what I can see this is all hierarchically happening. But the ContainingFolder/Library/ is never updating. Te keep terms consistent, "ContainingFolder" would be the one IIS has as its top level folder. In this case, doa.ovionx.com/. Within this folder we have ~/library, ~/website. The upgrade.zip(rar) files only have the content to overwrite ~/website. It is ~/library where the Upgrade.vb file is still the old version even after upgrading to 5.4.1
In ~/website/admin, the path expected is never created per the error I'm getting. However, it should not be being created if I'm reading other posts correctly. Read on.
The .../moduledefinitions/ folder is for the moduledefinitions.ascx and moduledefvalidator.ascx files. Per the error text below, these are supposed to be in ~website/admin/.../moduledefinitions/. The only version that has such a path is 4.9.5 and then only in the 4.9.5 Source.rar. This path does not appear in any Source vesion in 5.x
Per a post by Alex Shirley, the .../moduledefinitions/ folder and content was moved to ~/website/desktopmodules/admin in later versions. In our case, it isn't showing up there either.
So, if Alex' post is right -- .../moduledefinitions/Content should be showing up in ~website/desktopmodules/admin/ but it isn't. Per the error I'm getting, Hosts | Module Definitions after my upgrade to 5.2.2 and subsequently to 5.4.1 is trying to find this content but it's been removed. If Alex' post is interpreted right, that content should not even be there.
Und So! ... was gibt? Let's look at the error text again! I think an important clue was right in front of me:
Error: Module Definitions is currently unavailable.
DotNetNuke.Services.Exceptions.ModuleLoadException: The file '/Admin/ModuleDefinitions/ModuleDefinitions.ascx' does not exist. ---> System.Web.HttpException: The file '/Admin/ModuleDefinitions/ModuleDefinitions.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.Compilation.BuildManager.GetVPathBuildResult(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.ControlUtilities.LoadControl[T](TemplateControl containerControl, String ControlSrc) at DotNetNuke.UI.Modules.ModuleHost.LoadModuleControl() --- End of inner exception stack trace ---
I was all worried about this: DotNetNuke.Services.Exceptions.ModuleLoadException: The file '/Admin/ModuleDefinitions/ModuleDefinitions.ascx' does not exist. ---> All my effort was pointed to finding why this was missing, believing it should be there. But NO! :)
I needed to be paying attention to this, the very last line: at DotNetNuke.UI.ControlUtilities.LoadControl[T](TemplateControl containerControl, String ControlSrc) at DotNetNuke.UI.Modules.ModuleHost.LoadModuleControl()
IN the upgraded DNN solution, looking with VS 2008, this dll/method can't be found in Object Explorer in the DNN solution at all. My crude guess is an incorrect DotNetNuke.dll compilation, somehow, some way. I think the correct question is "Why is DNN trying to run an old method to look for files that are no longer used in a path that no longer is SUPPOSED to exist?"
The Module Definitions Page that SHOULD be showing up, per LIsa Gillespie and she's quite correct is the new Install Extensions, etc. one. the 5.2.2 and 5.4.1 upgrades in my case, once I browse to the site, are trying to find the OLD Module Definitions Page that existed prior to 5.x.
One thing I already checked was WHAT DotNetNuke. ... . dll files got installed and were they correct? They are. I compared the /bin folder in the 5.2.2 Upgrade.rar file right next to the ~/website/bin folder in the site. Yep, they're all copied over with the correct dates.
So, how can the old method be looking for old files in a non-existent path when the new DLL should have the new methods finding the right file?
All else works on the site except that the Module Definitions link in Hosts insists on trying to find the old style page.
Does this make sense?
Mike