Upgrade to V10.0.1 breaks custom modules with consistent error "Parameter name: CacheKey"

[bdimolfe-winmill]

Is there an existing issue for this?

• I have searched the existing issues

What happened?

Hello everyone,

After upgrading 2 separate DNN sites to V10.0.1 we are getting runtime errors for all of our custom modules that follow the same pattern below where the name of the module appears in the error message:

[ERROR] DotNetNuke.Services.Exceptions.Exceptions - System.Exception: Error Creating BusinessControllerClass '' of module() id=(484) in tab(40) and portal(0) ---> System.ArgumentException: Argument cannot be null or an empty string
Parameter name: CacheKey
at DotNetNuke.Services.Cache.CachingProvider.GetCacheKey(String cacheKey)
at DotNetNuke.Common.Utilities.DataCache.GetCache(String cacheKey)
at DotNetNuke.Framework.Reflection.CreateType(String typeName, String cacheKey, Boolean useCache, Boolean ignoreErrors)
at DotNetNuke.Services.Search.ModuleIndexer.GetModulesForIndex(Int32 portalId)

Any hints as to what might be the cause and how to solve?

Thank you!
Ben DiMolfetta

Steps to reproduce?

Upgrade to V10.0.1 -- upgrade wizard completes without errors
Try to run site and it doesn't load

Current Behavior

No response

Expected Behavior

No response

Relevant log output

Anything else?

No response

Affected Versions

10.0.1 (latest v10 release)

What browsers are you seeing the problem on?

Chrome

Code of Conduct

• I agree to follow this project's Code of Conduct

[michael-lorenz]

check the table DesktopModules and make sure your module does not have -1 as the value for SupportedFeatures, if it does, try changing the value to 0.

[bdimolfe-winmill]

Thank you michael-lorenz that worked!

Now seeing a long list of these errors:

The Controls collection cannot be modified because the control contains code blocks (i.e. <% ... %>).
at System.Web.UI.ControlCollection.Add(Control child)

Any thoughts here as well? Appreciate the guidance!

[bdimolfe-winmill]

thank you @bdukes for helping to keep track of this.

Should I open a new ticket for the error that I shared in the last post?

Add(Control child)?

[valadas]

This would be more general help about webforms than something DNN specific.

Usually a control has code blocks that need to run and then are added to another control programmatically after some lifecycle events have already happened so the controls collection is locked.

A best practice in WebForms is either:

• Use inline <% ... %> only (no dynamic control additions),
• Or use server controls and code-behind only (no inline blocks).
  Mixing both often causes lifecycle headaches like this one.

If the code block only renders a string or something very simple the usual quick fix is to replace it with an asp:label or an asp:literal or some control that makes more sense for the use case.

[bdimolfe-winmill]

Thank you @valadas for the reply. This DNN application with our custom users controls has been running in Production for several years under V9.11.2 and we executed the upgrade to V10.0.1 and the site doesn't run and we see the below error repeatedly in the log without making any code changes, so we assume this is something related to the upgrade. Looking to see if anyone else has experienced this and what was done to resolve. Thank you!

[FATAL] DotNetNuke.Services.Exceptions.Exceptions - System.Web.HttpException (0x80004005): The Controls collection cannot be modified because the control contains code blocks (i.e. <% ... %>).
at System.Web.UI.ControlCollection.Add(Control child)
at DotNetNuke.Services.Exceptions.Exceptions.ProcessModuleLoadException(String friendlyMessage, Control ctrl, Exception exc, Boolean displayErrorMessage)
2025-08-22 11:07:59.015-04:00 [DESKTOP-6MDUJR5][D:2][T:9][ERROR] DotNetNuke.Services.Exceptions.Exceptions - ~/Default.aspx?tabid=42&def=ErrorMessage
System.Web.HttpException (0x80004005): The Controls collection cannot be modified because the control contains code blocks (i.e. <% ... %>).
at System.Web.UI.ControlCollection.Add(Control child)
at DotNetNuke.Services.Exceptions.Exceptions.ProcessModuleLoadException(String friendlyMessage, Control ctrl, Exception exc, Boolean displayErrorMessage)

[valadas]

Well, it may be in combination with DNN changes. Mixing code blocks and control collection changes is brittle and another change in DNN combined with this may have just made it crop up now and not before. The best practice is to do only one or the other for that reason.

[bdimolfe-winmill]

Thank you @valadas! There are other third party breaking changes we need to get past.

[bdukes]

This error stems from ProcessModuleLoadException, so there's a different error that is causing an error when attempting to display the original error. There should be other errors in the logs that are the cause of these errors.

[bdimolfe-winmill]

Thank you @bdukes! Yes we are also having compatibility problems with DNNGo third party modules that we are looking further into. We are aware of the breaking changes related to this. For example,

[ERROR] DotNetNuke.Framework.Reflection - DNNGo.Modules.ThemePluginPro.baseController,DNNGo.Modules.ThemePluginPro
System.TypeLoadException: Could not load type 'DotNetNuke.Entities.Modules.ISearchable' from assembly 'DotNetNuke, Version=10.0.1.0, Culture=neutral, PublicKeyToken=null'.

[valadas]

Yes, ISearchable has been marked obsolete since v7.1.0 so you probably need to get some updates on 3rd party modules before upgrading DNN.