dnnsoftware
[Bug]: CDF - Rendering Issue with Type Attribute on DnnXxIncludes -- v10.02.00 RC2
Is there an existing issue for this?
- [x] I have searched the existing issues
What happened?
See code below for details and to reproduce using Aperture default.aspx
Test 4
- Issue 4A: See
relon Issue #6850, same fortypeattribute, we specifiedtype="module"but DNN addstype="text/javascript" - VERY nice to see the leading // (protocol relative url) is preserved in the src attribute! (was not the case previously)
Steps to reproduce?
In a new deploy or DNN v10.02.00 RC2, Insert everything below into ~/Portals/_default/Skins/Aperture/default.aspx at line 4.
<%-- copy+paste this into Aperture default.ascx at line 4 to test --%>
<%-- Test 4
- Issue 4A: See `rel` on Issue #6850, same for `type` attribute, we specified `type="module"` but DNN adds `type="text/javascript"`
- VERY nice to see the leading // (protocol relative url) is preserved in the src attribute! (was not the case previously)
--%>
<dnn:DnnJsInclude
FilePath="//cdn.jsdelivr.net/npm/@dnncommunity/[email protected]/dist/esm/dnn.js"
ForceProvider="DnnPageHeaderProvider"
HtmlAttributesAsString="rel:modulepreload,as:script,type:module,crossorigin:anonymous"
Priority="50"
runat="server"
/>
<%--
Results in DNN v10.02.00 RC2:
<script src="//cdn.jsdelivr.net/npm/@dnncommunity/[email protected]/dist/esm/dnn.js?cdv=250"
type="text/javascript" rel="modulepreload" as="script" type="module" crossorigin="anonymous"></script>
Results in DNN v10.01.02:
<script src="https://cdn.jsdelivr.net/npm/@dnncommunity/[email protected]/dist/esm/dnn.js?cdv=223"
rel="modulepreload" as="script" type="module" crossorigin="anonymous"></script>
--%>
<%-- end of CDF tests, Aperture Skin below --%>
Current Behavior
Covered aboved.
Expected Behavior
Described above.
Relevant log output
n/a
Anything else?
No response
Affected Versions
10.02.00 RC2 or current development branch (unreleased)
What browsers are you seeing the problem on?
Chrome
Code of Conduct
- [x] I agree to follow this project's Code of Conduct
@bdukes - if you prefer this is a new/sep issue, let me know and I will take care of it.
In this comment yesterday, were you suggesting that those new ones (Async, Defer, and CrossOrigin) would make it into RC2?
<dnn:DnnJsInclude FilePath="https://kit.fontawesome.com/a4444c967e.js" ForceProvider="DnnFormBottomProvider" Async="true" Defer="true" CrossOrigin="anonymous" Priority="42" runat="server" />
Because when I try them, DNN fails hard with an application error (old grey screen o' death). Note that its only on when CrossOrigin is included, Async and Defer work fine.
And then this is what is in the Admin Logs:
InnerMessage:Object reference not set to an instance of an object.
InnerStackTrace:
at DotNetNuke.UI.Skins.Skin.GetSkin(IHostSettings hostSettings, PageBase page)
at DotNetNuke.Framework.DefaultPage.OnInit(EventArgs e)
at System.Web.UI.Control.<InitRecursiveAsync>d__225.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Web.Util.WithinCancellableCallbackTaskAwaitable.WithinCancellableCallbackTaskAwaiter.GetResult()
at System.Web.UI.Page.<ProcessRequestMainAsync>d__523.MoveNext()
My guess is that we may need to update the web.config to reference DotNetNuke.Abstractions, where that CrossOrigin enum type lives. But I'd need to do some more playing around with it to be sure. Thanks for testing and letting us know it's not as straightforward as I expected.
Looking in the logs, there's a more detailed error before the one that you posted, which has similar info:
DotNetNuke.Services.Exceptions.Exceptions - DotNetNuke.Services.Exceptions.PageLoadException: Unhandled error loading page. ---> System.Web.HttpCompileException: D:\wwwroot\dnn.local\Website\Portals\_default\Skins\Aperture\partials\_registers.ascx(7): error CS0012: The type 'Enum' is defined in an assembly that is not referenced. You must add a reference to assembly 'netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'.
at System.Web.Compilation.BuildManager.PostProcessFoundBuildResult(BuildResult result, Boolean keyFromVPP, VirtualPath virtualPath)
at System.Web.Compilation.BuildManager.GetBuildResultFromCacheInternal(String cacheKey, Boolean keyFromVPP, VirtualPath virtualPath, Int64 hashCode, Boolean ensureIsUpToDate)
at System.Web.Compilation.BuildManager.GetVPathBuildResultFromCacheInternal(VirtualPath virtualPath, Boolean ensureIsUpToDate)
at System.Web.Compilation.BuildManager.GetVPathBuildResultInternal(VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile, Boolean throwIfNotFound, Boolean ensureIsUpToDate)
at System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert(HttpContext context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile, Boolean throwIfNotFound, Boolean ensureIsUpToDate)
at System.Web.Compilation.BuildManager.GetVPathBuildResult(HttpContext context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile, Boolean ensureIsUpToDate)
at System.Web.UI.TemplateControl.LoadControl(VirtualPath virtualPath)
at DotNetNuke.UI.ControlUtilities.LoadControl[T](TemplateControl containerControl, String controlSrc)
at DotNetNuke.UI.Skins.Skin.LoadSkin(PageBase page, String skinPath)
--- End of inner exception stack trace ---
After adding <add assembly="netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51" /> to the web.config it works successfully.
From my point of view its hard to understand why that didn't make it into DNN's web.config a long while ago.
We add that as well as System.Net.Http and System.Runtime to all our DNN sites at deploy. Saves us hours and hours of unexpected debugging efforts every year. But that is prolly because we do a lot of stuff that compiles at run time. :)