ASP.NET linux 上的核心 2.2 项目未找到卫星资源

Question

We've created an ASP.NET Core MVC project. Instead of using the new Microsoft.AspNetCore.Localization structure, we used the familiar old school embedded resources. We created a default .resx (with a designer class behind it), plus localized .resx files. So we have Resource.resx + Resource.Designer.cs , Resource.NL.resx , Resource.DE.resx , Resource.FR.resx , etc etc

Now, during development on Windows, and when hosting in IIS, all is fine. But when we are trying to host on linux (proxying in apache), the resources are not found. Only the default/invariant resource is returned.

Unfortunately, Google didn't give me any solutions:

Just to give some code... our ConfigureServices in startup.cs:

    public void ConfigureServices(IServiceCollection services)
    {
        services.Configure<RequestLocalizationOptions>(options =>
        {
            options.DefaultRequestCulture = new Microsoft.AspNetCore.Localization.RequestCulture("nl");
            options.SupportedCultures = System.Globalization.CultureInfo.GetCultures(System.Globalization.CultureTypes.AllCultures);
            options.AddSupportedUICultures("nl", "de", "fr");
        });

        services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_2);

        services.AddHttpContextAccessor();
    }

The Configure:

    public void Configure(IApplicationBuilder app, IHostingEnvironment env)
    {
        app.UseForwardedHeaders();

        if (env.IsDevelopment())
        {
            app.UseDeveloperExceptionPage();
        }
        else
        {
            // The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
            app.UseHsts();
        }

        app.UseHttpsRedirection();
        app.UseStaticFiles();
        app.UseRequestLocalization();
        app.UseMiddleware<ViewLocalizationMiddleware>();

        app.UseMvc(routes =>
        {
            routes.MapRoute(
                name: "default",
                template: "{controller=Scan}/{action=Index}/{id?}");
        });            
    }

And in case anyone is interested, here is the ViewLocalizationMiddleware:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading.Tasks;

namespace ConsumerWebsite.Business
{
    public class ViewLocalizationMiddleware
    {
        private readonly Microsoft.AspNetCore.Http.RequestDelegate _next;

        public ViewLocalizationMiddleware(Microsoft.AspNetCore.Http.RequestDelegate next)
        {
            _next = next;
        }

        public async System.Threading.Tasks.Task Invoke(Microsoft.AspNetCore.Http.HttpContext context)
        {
            var requestCulture = context.Features.Get<Microsoft.AspNetCore.Localization.IRequestCultureFeature>();

            if (requestCulture != null)
            {
                System.Globalization.CultureInfo.CurrentCulture = requestCulture.RequestCulture.Culture;
                System.Globalization.CultureInfo.CurrentUICulture = requestCulture.RequestCulture.UICulture;
            }

            await _next.Invoke(context);
        }
    }
}

So we copy to the server using ftp over ssh. We've done a chmod -R ugo+rwx on the folder with the files, just to make sure anyone could access everything, but still no luck.

Apache config for the application

<VirtualHost *:80>
        ServerName some.domain.com
        Redirect permanent / https://some.domain.com/
        RewriteEngine On
        RewriteCond %{HTTPS} off
        RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}?%{QUERY_STRING}
#        Header unset Server
#        Header add Server "TLS web server"
</VirtualHost>

<IfModule mod_ssl.c>
<VirtualHost *:443>
    ProxyPreserveHost On
    ProxyPass / http://127.0.0.1:5012/
    ProxyPassReverse / http://127.0.0.1:5012/
    ServerName some.domain.com
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/some.domain.com/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/some.domain.com/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/some.domain.com/chain.pem
</VirtualHost>
</IfModule>

Kestrel configuration:

[Unit]
Description=Our ASP.Core 2.2 application

[Service]
WorkingDirectory=/home/websitehome/
ExecStart=/usr/bin/dotnet "/home/websitehome/website.dll"
Restart=always
# Restart service after 10 seconds if dotnet service crashes
RestartSec=10
SyslogIdentifier=messages
User=apache
Environment=ASPNETCORE_ENVIRONMENT=Acceptance
Environment=ConnectionStrings__Master=SERVER=127.0.0.1;DATABASE=database;UID=uid;PWD=password;SslMode=none;

[Install]
WantedBy=multi-user.target

More info, here's the resource folder + attributes:

drwxrwxr-x   2 remco    remco       4096 Oct  2 22:14 NL

And the contents:

-rw-rw-r-- 1 remco    remco    6144 Oct  2 22:14 Base.resources.dll
-rw-rw-r-- 1 remco    remco    5120 Oct  2 22:14 Website.resources.dll
-rw-rw-r-- 1 remco    remco    6144 Oct  2 22:14 APIAccess.resources.dll

Does anyone have any suggestions to why on Linux the localized resources are not found?

Remco

Answer 1

Have a look at the file names of your resource files.

Linux is case sensitive and therefore: Resource.NL.resx, Resource.DE.resx, Resource.FR.resx are not the same as Resource.nl.resx, Resource.de.resx, Resource.fr.resx

This could be the problem so please take a look at the files. Go to your folder where you have your resource files and check the exact names. If that is the case you can change this part of the code:

options.AddSupportedUICultures("nl", "de", "fr");

Answer 2

So the issue is that the culture name is nl, so .net looks for a folder called nl.

But the resources were called resource.NL.resx... the compiler doesn't interpret this, but literally takes this part of the resource name and creates the resource folder for it, with the same casing.

So the solution was indeed renaming the files to resource.nl.resx, which results in nl (lowercase) as a folder for the localized resources.