Hello! I’ve found a couple of annoying bugs as I think with a common origin:
FIRST BUG:
Although Wisej runtime for .NET Framework 4.8 loads mixins from project’s default “Themes” subdirectory as expected, runtime for modern .NET Core (tested on .NET 6.0) does not loads mixins from project’s default “Themes” subdirectory (in “web context root”). Modern .NET Wisej runtime only sees mixins (and probably any custom themes!) in “Themes” subdirectory placed in build output “bin” directory.
I’ve made some investigations inside Wisej runtime code with ILSpy and think that I’ve found a root of problem:
internal static string ThemesPath => Path.Combine(ProjectPath ?? AppDomain.CurrentDomain.BaseDirectory, “Themes”); (from Wisej.Core.ClientTheme)
As we can see, it will try to use “Themes” subdirectory placed in “AppDomain.CurrentDomain.BaseDirectory” which resolves as project dir/web context root in .NET Framework 4.8, but in .NET Core it resolves to directory where main project assembly resides (in most cases it is output “bin” directory).
I think this issue can be fixed by replacing “AppDomain.CurrentDomain.BaseDirectory” with something that resolves valid web context root (f.e. like it is done in Wisej.Core.WisejContext.GetRootPath()). At first sight it looks like Wisej.Core.WisejConfiguration.GetRootPath() is a good candidate, but as I can also see, ThemesPath can be read slightly earlier than WisejContext.RootPath is initialized with valid web context path in instantiation of Wisej.Core.WisejContext.WisejContext(HttpContext) later in ProccessRequest chain.
So, here comes the other thing with same origin of earlier initialization of RootPath:
SECOND BUG:
When using modern .NET Core Wisej runtime SOMETIMES a default theme from Web.config “Wisej.DefaultTheme” is not loaded and default Blue fallback theme is used. In my environment it happens 2-3 times from 10 trials. It looks like runtime sometimes can’t read Wisej.DefaultTheme from Web.config, because Wisej.Core.WisejConfiguration.GetRootPath() is still not ready and not holding a valid web context root path, so Web.config can’t be read and Wisej.Core.WisejConfiguration.GetValue() can’t return a valid value for Wisej.DefaultTheme.
Placing Web.config file copy in output “bin” directory (yes, in AppDomain.CurrentDomain.BaseDirectory) also fixes this erroneous behavior.
I think that these bugs can be fixed by initializing RootPath somewhere VERY early in Wisej middleware and use it to resolve all these things.
Thank you.
Hi, Levie! Yes, thank you, proposed workarounds are fixed erroneous behavior. But don’t you think it needs at least some harmonization in these things? For NF 4.8 a project root and web root is the same place, but for modern .net core it is different as we can see. May be some logic in Wisej internals needs to be changed to allow loading Themes, Web.config (and may be some other things) from the same place (web root) to eliminate additional copy steps?
Hi Alexander, For issue #1, using the themes and mixins with .NET 6: The issue is that the Themes folder is not copied to the project root (for .NET 6 this is the same level as the assemblies). You can add the following lines to your .csproj file to copy it automatically:
<ItemGroup Condition="'$(TargetFramework.TrimEnd(`0123456789`))'!='net'"> <None Update="Themes\**\*.*"> <CopyToOutputDirectory>Always</CopyToOutputDirectory> </None> </ItemGroup>
For issue #2, If you’re using .NET 6 the web.config file needs to be located at the project root (the same level as the assemblies). You can copy it into the csproj file:
<ItemGroup Condition="'$(TargetFramework.TrimEnd(`0123456789`))'!='net'"> <Content Update="Web.config"> <CopyToOutputDirectory>Always</CopyToOutputDirectory> </Content> </ItemGroup>
HTH,
Levie
I’ve tested your attached project and have exactly same issues (on two different machines). Please see attached screenshots. On net framework 4.8 it works ok all the time, but running it on net 6.0 will result in not loading mixins everytime and sometimes not loading default theme (bootstrap) correctly, falling back to blue.
hi Alexander
We have done various checks for the two issues that you comment us, but both issues isn’t occurs.
Here I let you the sample that I used with mixin theme
I use the latest versions of browsers Edge, Chrome and FF and wisej.net 3.0.11
We appreciate if can compare with your test and comment us
Regards
Paul
Hi.
According first issue: You can simply create Wisej Desktop Application from template, add new Mixin Theme item to project, uncomment mixin statements (red button background). Then you need to remove:
<ItemGroup>
<EmbeddedResource Include=”Themes\YOUR_NAME.mixin.theme” />
</ItemGroup>
from csproj file (for some reason you do not want to embed your custom mixin or theme into assembly resources). Then build and start your app for modern .NET profile (using standalone built Kesterl exe loader or using VS debugger). You can see that it is not loading mixin from “Themes” subdir. If you will then start it using NF 4.8 and IIS Express (using VS debugger f.e.), it will successfully load mixin as file from “Themes” directory and show red background on buttons.
According second issue: You can start your app for modern .NET profile (using standalone Kesterl or using VS debugger) and then, when application starts, do not wait and QUICKLY switch to browser window where your tab with “http://localhost:5000” is opened, try to refresh it, etc… ~2 of 10 trials you will get default Blue-1 theme fallback loaded instead of f.e. Bootstrap one. The worst thing is that when you trigger this bug, fallback theme will be loaded for every new session (user) in running app, until you completely reload app and it will load correctly for first time.
Alexander,
please provide a compilable test case that helps us to reproduce the issues you have found.
Best regards
Frank
Please login first to submit.