My ASP.NET contains an IIS virtual folder that points to static images (so that the HTTP requests serving up these images do not even touch my app).
To web clients consuming my site at http://<server>/myAppRoot:
Page1.aspx
Page2.aspx
images/MyAppLogo.png
static/file1.png <-- IIS virtual folder "static" points to D:\someOtherPath
static/file2.png
On the server filesystem at C:\somePath\myAppRoot:
Global.asax
Page1.aspx
Page2.aspx
Web.config
bin\MyAppAssembly.dll
bin\ImageResizer.dll
images\MyAppLogo.png
And elsewhere on the server live all the static images at D:\someOtherPath:
file1.png
file2.png
I can add ImageResizer to the ASP.NET bin folder, along side my own assemblies, and add the <resizer> tag to Web.config, ImageResizer will run and process any request from my actual app folder. I can use all the ImageResizer stunts to make MyAppLogo.png dance.
But ImageResizer won't recognize intercept any requests for the /static/ virtual folder (which is the folder containing tons of uploaded images that I want small thumbnails for on the fly).
How do I configure ImageResizer to process the /static/ virtual folder?
I should add that /static/ is added by our installer, completely outside of our app, and is not a <location> tag inside my app's Web.config.
Any suggestions on how to configure ImageResizer to process the /static/ IIS virtual folder?
The way I understand it, ImageResizer should work with IIS virtual path providers.
However, there is the VirtualFolder plugin, which is available for free. See http://imageresizing.net/plugins/virtualfolder . Note the caveat:
IIS Virtual Folders perform better, however, so this plugin should only be used for testing, development, or as a last resort.
I have no personal experience on the plugin but the configuration seems easy; you'll just need to map virtual paths to physical paths like this:
<add name="VirtualFolder" virtualPath="~/static/" physicalPath="D:\someOtherPath" vpp="false "/>
Well, testing the access attempts to the myAppRoot/static/* paths directly on the webserver revealed a much more detailed IIS error (403.1 Forbidden).
The /static/ folder had been previously configured with "Read" access, when it needed "Script" access.
Solution:
Modify the <handlers> of <system.webServer> in D:\someOtherPath\Web.config to <handlers accessPolicy="Script" />
Related
I have two separate .NET6.0 projects for back-end and front-end. Backend with C# can be published just fine. Front-end is written with Blazor. When I choose publish, it goes through the process without errors or exceptions. It also builds files in the bin>Release>net6.0 directory just fine but doesn't create any of the DLL files in my chosen directory for publish. In that directory, it just creates wwwroot, libman.json and web.config as you can see in the image.
Where can be the cause of the problem?
blazor web assembly app is a static app so it will have much static files, the logic codes you wrote in .razor will be packaged into your_project_name.dll in wwwroot\_framework.
Then when we need to host the app, we need to find a static file server to serve the app. For example, IIS. When publish the static app, we need to create a website and set the website point to the publish folder which containing wwwroot folder and web.config file. Then make sure the IIS had installed url rewrite module since it's a static website. After installing the module, we will see the default rewrite rule like this:
I have an Azure App Service which has two virtual applications (Asp.Net Core Blazor apps, if it's important) hosted within it. The virtual application URLS are something along the lines of
https://site.azurewebsites.net/site1
https://site.azurewebsites.net/site2
I have noticed that some of the internal routing seems to not be taking the virtual application path into account. For example, a link that takes the site to the "/" route navigates to https://site.azurewebsites.net instead of the appropriate "base" virtual application path. Is there some way of either handling this in my application or within the azure configuration?
Thank you for any assistance!
Adding to Hassan's suggestions, on App Service, Each app has the default root path (/) mapped to D:\home\site\wwwroot, where your code is deployed by default. If your app root is in a different folder, or if your repository has more than one application ( as in your case), you can edit or add virtual applications and directories here.
To configure virtual applications and directories, specify each virtual directory and its corresponding physical path relative to the website root (D:\home). Optionally, you can select the Application checkbox to mark a virtual directory as an application.
From Azure Portal > Navigate to your WebApp -> Settings (Configuration)-> Path Mapping> Virtual applications and directories.
if you browse via console Kudu console in your app service blade you will notice a directory, under wwwroot is the root directory which by default your application routes to. This you can change from App Settings blade option. Also in this directory you will find you can create other folders aka virtual applications which will work the way you want it to.
I have developed and published (via the "publish" feature in VS 2013) a simple WCF web service on IIS on my local machine.
The physical deploy path is the folder : c:\inetpub\wwwroot\MyWCF_Service_On_IIS\
I saw on IIS that the virtual folder has been created under "default Web site" (with the same name : MyWCF_Service_On_IIS). The default web site listens on port 80.
Why there is no way to access the service ? whatever combination of paths and urls fails.
I tried :
localhost/MyWCF_Service_On_IIS/Service1.svc (Service1.svc is the .svc file hosting the only endpoint);
localhost/Service1.svc
127.0.0.1/MyWCF_Service_On_IIS/Service1.svc
127.0.0.1/Service1.svc
localhost
127.0.0.1
Even if I don't expose metadata endpoints I expect to see a least a help page about the service and how to get the metadata themselves.
But I only get errors
Whatever attempt I do fails miserably.
I would like to know, once and for all, what is the rule IIS uses to map virtual folders to physical folders.
We are supposed to directly deploy all related files/file directories to the root folder of the website by using FileSystem mode.
C:\inetpub\wwwroot
Moreover, we need to enable windows features to handle the SVC extension for supporting WCF service.
There is no need to use a virtual folder in that case.
Here is the content of the wwwroot folder on my side.
bin folder
PrecompiledApp.config
Service.svc
Web.config
The service URL is http://localhost/service.svc
If we specify the URL by using a virtual path. We should convert the virtual path to the application.
Then the service URL is http://localhost/MyWCF/Service1.svc.
Feel free to let me know if the problem still exists.
I am using the ImageResizer successfully on other areas of my site where the images are being served from a folder within the application (both .jpg?width=100 & .jpg.ashx?width=100 work), but when I try images from a virtual directory located on the local machine, I can only get resizing to work if I specify the image page using the "jpg.ashx?width=100" method.
The site's application pool is using NetworkService identity and the virtual folder has pass-through authentication enabled. I've granted Modify permissions to NetworkService on the virtual folder too hoping that would help.
I am using IIS 7.5 in Classic Mode and the resizer diagnostics page doesn't show any issues.
Does anyone have ideas on why this may be happening? Any help would be appreciated.
Thanks!
Classic Mode requires the .ashx syntax, since ASP.NET doesn't see static file requests.
If you're seeing different behavior within the same site on the same host, then your virtual folder is probably NOT a virtual folder, it's likely a sub-application.
I am setting up a 3rd party website which makes heavy use of httpHandlers. When configured as a virtual directory under Default Site on a 2003/IIS6 machine, everything works as expected. When configured as a standalone site on the same machine, pointing to the same directory and web.config however, httpHandlers do not work (404).
I have tried various changes to the path values of the handler's tags with no results. The pages themselves, and the application's code, all seem to execute find within the standalone site.
Any obvious things I might be missing?
Found my own answer, was a very simple thing.
An installer package had installed the virtual directory version of the site, and it had taken care of adding the file extension mappings. The standalone was manually configured and as such, I missed adding the mappings.
Resolved.