Not directly.
You see, the problem is that when you have a .NET-Core application, it runs in Kestrell and not in IIS (for .NET Core <2.2).
Now, to host your .NET-Core application in IIS, AspNetCoreModule launches your .NET-Core application with Kestrell on port X 127.0.0.1, and then redirects traffic from your iis-domain + virtual directory to port X on 127.0.0.1 ( it can use something else besides TCP).
Problem 1 is that Kestrell has rather limited functionality, that is, it does not have virtual directories.
Problem 2 is that IIS, unlike nginx, does not actually perform reverse proxying properly, or we should say “completely”.
IIS can forward domainxy: 80 to 127.0.0.1:random in order. But what he is not doing properly is rewriting domainxy: 80 / foo to 127.0.0.1:random (images, header, json-ajax-results, urls, return-url, cookies, etc. And vice versa). Instead, it rewrites the domain: 80 / foo to 127.0.0.1:random/foo, which is a problem if the server 127.0.0.1:random (Kestrell) does not support virtual directories.
Therefore, if you want to run your application in your virtual directory, you have two options (both include changing your application — if you can)
1) Put all your stuff in the "foo" directory (including the MVC controller route) if your application will be deployed only once.
2) As suggested in https://github.com/aspnet/Hosting/issues/416#issuecomment-149046552, you can configure the application framework to simulate this folder, as in RoR:
public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory) { string virtual_directory = "/Virt_DIR"; // virtual_directory = "/"; if (virtual_directory.EndsWith("/")) virtual_directory = virtual_directory.Substring(0, virtual_directory.Length - 1); if (string.IsNullOrWhiteSpace(virtual_directory)) Configure1(app, env, loggerFactory); // Don't map if you don't have to // (wonder what the framework does or does not do for that case) else app.Map(virtual_directory, delegate(IApplicationBuilder mappedApp) { Configure1(mappedApp, env, loggerFactory); } ); } // Configure is called after ConfigureServices is called. public void Configure1(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory) { [...] (here comes what used to be in your old Configure method)
You will need to configure the name of the virtual directory somewhere. Caution, when you have / return URLs in JavaScript / ajax requests, they will not be automatically displayed. You have to do it yourself, but it was the same with the old ASP.NET.
Indeed, like RoR:
Rails.application.config.relative_url_root map || "/" do
run RedmineApp :: Application
end
As for the virtual directory in the application: no, it's not that simple.
IIS is a full-fledged web server that will serve the contents of this mapped directory as it was there (if it can read the contents).
If you redirect the entire parent directory to Kestrell, IIS will not be able to serve the subdirectory, and your application will need to do this. This means that you need to configure a static file server for this particular directory and tell it where the files are located, as you did.
What you could do is tell IIS not to use a proxy for this particular virtual subdirectory (just like you can determine the location of a static file in nginx - except that IIS probably does not support this function).
However, you can create a symbolic link (or mount / junction) in the directory of your application, which goes to a network folder if Windows is capable of it (mklink). Then .NET Core will be able to serve it statically. But actually, it sounds like a hack.
If you cannot configure IIS, you really should use app.UseFileServer () and locate the document in the database. This way you can simply remove and re-insert the application later.