Virtual directory inside of ASP.NET Core app in IIS

Question

We have an application using ASP.NET Core 1.0 RC1 and hosted on IIS. It works fine. Now we have static content, that is available on a file share and should be accessible fr

Answer 1

My solution was using path="/" instead of path="*" on web.config file

Answer 2

I know its a question with 1,8 year, but if someone needs to resolve the same problem, try to use this:

public void Configure(IApplicationBuilder app)
{
    app.UseStaticFiles(); // For the wwwroot folder

    app.UseStaticFiles(new StaticFileOptions()
    {
        FileProvider = new PhysicalFileProvider(
            Path.Combine(Directory.GetCurrentDirectory(), @"wwwroot", "images")),
        RequestPath = new PathString("/MyImages")
    });
}

Is perfectly possible to change parameters of PhysicalFileProvider to any local or shared folder, and with this serve a file.

Doing that in this way is not SECURITY recommended. But, for study propose, its acceptable.

The static file module provides no authorization checks. Any files served by it, including those under wwwroot are publicly available. To serve files based on authorization: Store them outside of wwwroot and any directory accessible to the static file middleware and Serve them through a controller action, returning a FileResult where authorization is applied.

In Microsoft's Asp.Net documentations we can find more complete information to help with this issue.

Check this link: https://docs.microsoft.com/en-us/aspnet/core/fundamentals/static-files

Answer 3

I have found a blog which I think must have been written by the OP.

The upshot is not to use a virtual directory in IIS at all but rather map your path in Startup.cs to the physical server directory. I hope the OP does not mind that I have pasted the blog below, but it helped me when I first encountered this problem today.

Source: https://www.jauernig-it.de/asp-net-coreiis-serving-content-from-a-file-share/

There are situations, when you want to serve static content with your application, that is not part of it, e.g. because it exists on a common file share. Website content, that is managed by a business division, could be such a use case. In ASP.NET before Core, this was no problem in IIS: just create a virtual directory within your IIS website and point it to the file share.

Unfortunately, with ASP.NET Core, this approach isn’t working any longer. If you add a virtual directory to your ASP.NET Core application in IIS, it isn’t recognized and a 404 is returned. It’s because of DNX/Kestrel, which is running beneath IIS (using the HttpPlatformHandler module) and to which IIS only brokers the requests. Kestrel doesn’t know anything of virtual directories from IIS. And because ASP.NET Core applications are independent from IIS and could also be run without it (e.g. running Kestrel standalone), that should be considered as a good thing.

But now we need another solution for our problem… fortunately, ASP.NET Core gives us a programmatic interface to serve files from anywhere. Just add the following code to your Startup.cs Configure() method:

app.UseFileServer(new FileServerOptions
{
    FileProvider = new PhysicalFileProvider(@"\\server\path"),
    RequestPath = new PathString("/MyPath"),
    EnableDirectoryBrowsing = false
});

What this essentially does, is adding a file server to a physical server path, that is then available on a certain request path, in this case with directory browsing disabled. You are also able to serve from a path relative to your application, using new PhysicalFileProvider(env.WebRootPath + "\path") (given env is of type IHostingEnvironment as parameter of Configure()). Voila, that’s it. There is no need to add a „virtual directory“ in IIS, this stuff is deprecated and a thing of the past. For me, this is a good thing, because we get more independent of the whole IIS…

Answer 4

Not directly.

You see, the problem is, when you have a .NET-Core application, the application is run in Kestrell, not IIS (for .NET Core < 2.2).

Now, to host your .NET-Core application in IIS, the AspNetCoreModule starts your .NET-Core application with Kestrell on Port X of 127.0.0.1, and then reverse-proxies the traffic from your iis-domain+virtual directory to Port X on 127.0.0.1 (it might use something else than TCP).

Problem 1 is, Kestrell has pretty limited functionality, meaning no virtual directories.
Problem 2 is, unlike nginx, IIS does not really do the reverse-proxying properly, or should we say "completely".

IIS can forward domainxy:80 to 127.0.0.1:random alright. But what it doesn't do properly is rewrite domainxy:80/foo to 127.0.0.1:random (images, header, json-ajax-results, urls, return-urls, cookies, etc. and vice-versa). Instead it rewrites domain:80/foo to 127.0.0.1:random/foo, which is a problem if the server on 127.0.0.1:random (Kestrell) doesn't support virtual directories.

So if you want to run your application in your virtual-directory, you have two options (both involve modifying "your" application - if you can do that):

1. Put all your stuff into directory "foo" (including the MVC controller route), if your application is going to be deployed only once.

2. As suggested in https://github.com/aspnet/Hosting/issues/416#issuecomment-149046552 you can have the application-framework simulate that folder for you, kindof like 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 have to configure the name of the virtual-directory somewhere. Careful when you have/return URLs in JavaScript/ajax-requests, they won't be automagically mapped. You have to do this yourselfs, but that used to be this way with old ASP.NET, too.

Really, like RoR:

map Rails.application.config.relative_url_root || "/" do
    run RedmineApp::Application
end

As for a virtual directory within the application: No, this is not that simple.
IIS is a full webserver, which will serve the content of that mapped directory like it was there (if it can read the contents).

If you forward the entire parent directory to Kestrell, then IIS can't serve the subdirectory, and you're application would have to do that. That means you'll have to setup a static file server for that specific directory, and tell it where the files are, as you have done.

What you might be able to do, is tell IIS to not proxy that specific virtual sub-directory (just as you can define a static-file location in nginx - except that IIS probably does not support that feature).

However, you could create a symlink (or mount/junction) within your application directory that goes to the networked folder, if Windows is capable of that (mklink). Then .NET Core should be able to serve it statically. But really, that sounds like a hack.

If you can't configure IIS, you really should use app.UseFileServer() and define the document's location in the database. That way you can just delete&re-insert the application later.

Answer 5

I encountered this problem today, and finally managed to fix it. The trick (for me, probably not for everyone) is making sure the aspNetCore handler is disabled in the sub-application and enabled in the main (ASP.NET Core) application.

My ASP.NET Core app has a basic Web.config

<configuration>
  <system.webServer>
    <handlers>
        <add name="aspNetCore" path="*" verb="*" type="" modules="AspNetCoreModule" scriptProcessor="" resourceType="Unspecified" requireAccess="Script" allowPathInfo="false" preCondition="" responseBufferLimit="4194304" />
    </handlers>
    <aspNetCore processPath="dotnet" arguments=".\bin\Debug\netcoreapp2.0\myapp.dll" stdoutLogEnabled="true" stdoutLogFile=".\logs\stdout" />
  </system.webServer>
</configuration>

and the application added as a sub-application in IIS has

<configuration>
  <!-- removed -->
  <system.webServer>
      <handlers>
          <remove name="aspNetCore" />
       </handlers>
  </system.webServer>
</configuration>