https://discord.umbraco.com logo
Join Discord
Powered by
IIS Exception at start-up when running Umbraco v15...
# help-with-umbraco
o
I should be using Kestrel so I'm not even sure how to deal with this. As the exception indicates it was built on Windows, but it should be cross-platform.
Copy code
bash
Unhandled exception. System.TypeLoadException: Could not load type 'Microsoft.AspNetCore.Builder.IISServerOptions' from assembly 'Microsoft.AspNetCore.Server.IIS, Version=9.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'.
   at Umbraco.Extensions.UmbracoBuilderExtensions.AddWebServer(IUmbracoBuilder builder)
   at Umbraco.Extensions.UmbracoBuilderExtensions.AddBackOffice(IUmbracoBuilder builder, Action`1 configureMvc)
   at Program.<Main>$(String[] args) in C:\Users\Ora\source\repos\MMVUmbraco\Program.cs:line 11
   at Program.<Main>(String[] args)
The same code runs fine on Windows but that's using IIS.
s
Same error on Ubuntu: https://discord.com/channels/869656431308189746/1308102704861675631/1308114371657863269 It seems that you'd need to install .NET 9 manually, something is off about the packages Microsoft provides.
s
I encountered this when converting a large app to .NET 9, running on Rocky 9.x. It’s not a problem with the apt or rpm packages, it’s Umbraco attempting to configure IISServerOptions, even though it is deployed to Linux. IISServerOptions can no longer be accessed on Linux in the .NET 9 version of the assembly. The solution is to have Umbraco appropriately detect the OS and conditionally set KestrelServerOptions on Linux as opposed to IISServerOptions. I have confirmed this to work on Rocky 9.x with the standard dnf packages. Hope this helps.
s
THANK YOU @slamj1 ! I had a feeling it wasn't anything with .NET but hadn't had time to investigate. Any chance you can send a PR with your findings?
s
@Sebastiaan , unfortunately, I don't work on Umbraco, but since the Umbraco community was one of first to report this, I thought I would share this tidbit of info. It should be fairly simple to fix however.
s
Thanks that's quite alright! I just wondered since you were able to fix the problem, can you point us where to look please?
s
I had a quick look at the source and it will be in this file -> src/Umbraco.Web.Common/DependencyInjection/UmbracoBuilderExtensions.cs, line 338:
builder.Services.Configure(options => { options.AllowSynchronousIO = true; });
If you are targeting non-Windows OS's, you shouldn't be configuring IISServerOptions. A simple macro #if conditional compile check of your configuratin can handle this.
s
For sure, we'll have a look at it and get it sorted for the next release, thanks for digging in, love it!
j
Would be interested to know what Umbraco is doing that requires this to be set to true...
Since the docs say that this is a bad idea.
Ha, even already has a TODO.
Something to consider when this gets looked at @Sebastiaan is that there's a recommended workaround from the netcore team that can be applied per request context (i.e. it doesn't have to be enabled/disabled for the whole application) and isn't tied to either the kestrel or IIS concrete configuration classes...
Copy code
csharp
var syncIOFeature = HttpContext.Features.Get<IHttpBodyControlFeature>();
if (syncIOFeature != null)
{
    syncIOFeature.AllowSynchronousIO = true;
}
https://github.com/dotnet/aspnetcore/issues/7644 https://stackoverflow.com/a/67632199
s
Thanks @Jason - not sure what the request path is that we should ignore though.. 🤔 but I guess that's where we'll need to do some debugging to see if it's only in a very specific scenario or an application-wide problem.
They say what exactly is a bad idea?
Ah I see, looking into it, we're globally changing that synchronous operations should be allowed for all server types, that does sound like a bad idea to do this globally in general. However, I am sure we have plenty of legacy code that doesn't do async, so we would need to apply this for specific routes a lot.. 😅
j
Yeah, the question is whether we're talking about truly legacy code or just code that wasn't refactored for netcore when it should have been.
s
At the very least it's not an easy 
#if WINDOWS
since then we'd need to compile and publish specific versions for windows and not-windows 😬
I updated the whole method to be
Copy code
csharp
    public static IUmbracoBuilder AddWebServer(this IUmbracoBuilder builder)
    {
        return builder;
    }
And from a quick clicking around on most things in the backoffice, it "just" seems to work. I'll see if the Playwright tests still run, but it seems like we don't need to do a blanket allow rule. Seeing as though the whole new management API is async I am guessing this was never really necessary for v14+.
The tests all succeeded (before I pushed an extra commit) so I think this global config can just be removed and everything should work as expected https://github.com/umbraco/Umbraco-CMS/pull/17886
Feedback from Ronald: > Looks like this was added as work-around because Newtonsoft.Json wasn't writing the serialized data to the response body asynchronously: https://github.com/dotnet/aspnetcore/issues/8302 And I joked: oh then it will probably affect uSync, like with any change we do.. turns out, @Kevin Jump is actually still using Newtonsoft.Json 😱 Not sure how feasible it is for you Kevin to find the routes still using it and use what Jason found: https://discord.com/channels/869656431308189746/1314006673542877184/1322150433346818069 to cover the routes necessary. Of course you can also re-add the blanket rule to 
AllowSynchronousIO
but that would make uSync not work on Linux I guess.
k
Not in uSync I should all be system.text.json (translation manager still has newtonsoft bits)
s
But also, it's a much newer version of newtonsoft. So the problem might be long fixed (original problem was in 2020!)
k
yes - assets is pre v14 library, its not used (or installed on v14+ , that uses the .client package for the front end)
s
ah cool! will have to run a few tests next week
101 Views
PreviousNext
Powered by