I am trying to configure ImageResizer to run as an Azure virtual application so that it will run in the same web role as our main MVC application but a separate worker process. It appears that AzureReader2 isn't flexible enough to accomodate this.
An Azure virtual application adds an additional subfolder to the url and so does ImageResizer.
The following url results when using the Azure emulator is used and the Azure virtual application name is set to "ir" and the default subfolder of "azure" is used for the AzureReader2 plug-in:
http://127.0.0.2:81/ir/azure/datstat-resources-17/94fdf833-d457-4ed5-bce1-abf403381460.jpg?width=400
This example works just fine. The problem comes when NO query string is specified and the request is redirected to use blob storage. When I remove the query string the following url is produced:
http://127.0.0.1:10000/devstoreaccount1/re/datstat-resources-17/94fdf833-d457-4ed5-bce1-abf403381460.jpg
I'm very confused as to how this url is formed. What I want is for the "/re" subfolder portion to be removed from the url.
Here are my AzureReader2 web.config settings:
<add name="AzureReader2" connectionString="UseDevelopmentStorage=true" endpoint="http://127.0.0.1:10000/devstoreaccount1/" />
Is there any way to fix or control the way this url is formed?
This bug has been fixed in the latest development version, and will be included in the next release.
The blob redirect path is incorrect for any application not mounted at the domain root.
E-mail support#imageresizing.net to get a hotfix and claim your bug report reward.
Related
I have an ASP.NET Core 6 Web API that has a simple endpoint
/resources/{id} where id is a string. Everything worked as expected in local development. We then deployed it to a standard Azure App Service.
We got a bug report when this particular URL was requested /resources/d.dd. The response was
The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.
I have tried with these variations
resources/d.dd/
resources/d.vn (and other top-level domain name)
resources/hello.dd
resources/d.ddd
resources/d.txt
All worked except for d.dd without the last / in the URL.
I ran it locally. It worked. The d.dd was parsed and seen as the id.
It seems that .dd is routed as a file extension by the webserver on Azure. I spent hours looking around and checking Azure settings. I found nothing.
I am looking for a hint or suggestion. Thank you for your time and help.
UPDATE
We can create a web.config manually, and copy the content from azure and paste it.
Every time when you deploy it, it will include this web.config file.
Likeļ¼
Test Result
I am having troubles hosting the blazor wasm asp.net core hosted application.. The solution has 3 projects: Client, Shared, and Server.
when I run the command dotnet publish --configuration Release it publishes the libraries to their respective folders in solution like this:
WebWorkbench3\Client\bin\Release\net5.0\publish
WebWorkbench3\Server\bin\Release\net5.0\publish
...
I would assume that since the server project is referencing a client - then my steps to host the application are following:
Open WebWorkbench3\Server\bin\Release\net5.0\publish in powershell
Run command dotnet .\WebWorkbench3.Server.dll
Navigate to: https://localhost:5001/
Result:
Expected: client page opened
Actual: page is stuck at "Loading.." string. In the console we see that there was an error about _framework/blazor.webassembly.js not being loaded.
If we were to check the wwwroot folder contents in the server app we will see the following:
So this explains why the error is shown. However my question at this point - should the publishing process/configuration in project take care of copying client's wwwroot contents into the the server's app output directory? If we start a debugging session in the VisualStudio, then we use the server as the startup point, so the project should have some idea where to look up the blazor.webassembly.js file at..
So why doesn't the same process occurs during the publishing?
Note: I was able to fix the issue by manually copying the client's wwwroot directory and by placing the contents into the server's wwwroot directory... But I don't think that is is how serving is supposed to work?
EDIT: I have just tried to set-up the client blazor application in IIS. And it works. Kind of. The page is opened. But then when it tries to make a REST GET request to the server - it uses the same hostname:port combination. So if my app is hosted on mysite.local:50001 then the request to API will look like mysite.local:50001/data/loadall where data is the controller name and loadall is the action name.. So basically the client uses the same base address as the server.. The problem, is that I cannot start the server on the same port as the client! In attempt in doing so - you will see following output:
So basically I have the same question as before - how to host the wasm application that is split between client and the server? I am pretty sure that I can make it work by forcing the client to use the non-standard server port and serving the server part on that port.. However, I believe there should be a reason why current configuration (default configuration in the blazor wasm template) is configured in this way so it should be possible to run the project somehow without any additional changes at all..
Well this will be a self-answer.. Instead of publishing (dotnet publish --configuration Release) the application on solution level - do the publishing on project level..
before ..\repos\WebWorkbench3\WebWorkbench3
after ..\repos\WebWorkbench3\WebWorkbench3\Server
In 1 case the compiler does not copy the _framework folder (and possibly some other files) into the wwwroot.. Once you have published the Server correctly you can access the app by serving it with dotnet .\WebWorkbench3.Server.dll command.
Having the samie issue as explained above:
Before:
The solution file
had the same name
was in the same folder
as the server project
Resolved
I moved the solution to the project root (one level up).
Now, dotnet publish within the server project produced the __framework folder + content as expected.
I know that is located in HttpContext.Request.PathBase, however I need it to configure my cookie before I have any HttpContext (in Startup.cs).
My problem:
When devops configure application they have to set path twice. Once in IIS application (so hosting knows what should be served) and in my appsettings.json (so application knows where to set cookies - multiple instances can work on server). I would like to configure it once in IIS, and have config passed to my application.
There is a little confustion here that should be clarified.
You want to know application virtual path at application startup. However application virtual path is a concept of the hosting and specific request rather than underlying application. Hosting service uses this virtual path to map incoming url to application root. In IIS you can map multiple virtual paths to the same physical directory, e.g. /myApp1 and /myApp2 will point to the same application. Which of these paths do you want to get at application startup?
That's actually the reason why IHostingEnvironment interface does not provide any property for getting application virtual path. Another thing when application processes the request. In this case specific URL is requested and ASP.NET could provide requested virtual path in HttpContext.Request.PathBase.
You should reconsider your use case and check whether you actually need application virtual path for cookie configuration. It could be the XY problem. If you still have doubts regarding cookie configuration, please formulate it as a new question with specific details for your scenario.
You can check the environment variable ASPNETCORE_APPL_PATH. This is the variable AspNetCoreModule provides so that PathBase can be set correctly. See https://github.com/aspnet/IISIntegration/blob/df88e322cc5e52db3dbce4060d5bc7db88edb8e4/src/Microsoft.AspNetCore.Server.IISIntegration/WebHostBuilderIISExtensions.cs#L19
Just to add you can use #Url.Content("") in Javascript to get virtual directory base path.
<script src="#Url.Content("~/app/myapp.js")" type="text/javascript"></script>
I have deployed an ASP.NET MVC 4 application to a new site I have created in IIS 7.5, which I have bound to port 8080. I can reach it by navigating to http://localhost:8080, but I want to reach it via http://localhost/MyWebsite.
I have added a Virtual Directory under my website, which points to "C:\inetput\wwwroot\MyWebsite\". However, when I navigate to http://localhost/MyWebsite, I am presented with a configuration error:
"It is an error to use a section registered as
allowDefinition='MachineToApplication' beyond application level. This
error can be caused by a virtual directory not being configured as an
application in IIS."
Here is what my IIS hierarchy looks like (this is a demo since I have no internet access on the server I am working on).
I have two questions:
Why am I getting this error?
Is this the best way to go about achieving what I want? It seems messy to have the list of files and folders underneath the website and then again underneath the Virtual Directory. If there is better practice then please tell!
Virtual Directories cannot execute scripts, reason why you are getting that error. You need to make your MyWebsite folder an Application. Also, you don't necessarily have to create a separate website for your website, you can use the Default Web Site and create an application MyWebsite in there (it might be less confusing maybe?).
Just installed Windows Server 2008 SP2
Installed IIS, ASP.NET and other necessary roles.
For my site folder I edit the permission to include
users: Network Service and a bunch of other IIS user names
a long with that Internet guest one. Fiddled around with the
application pool (Load user profile:True , Identity Network Service etc.
Also only change I made from the default fresh install settings
was installing the .Net 4 framework.
I can view regular html files etc. But should I want to make use of ASP.NET and access an aspx page, I get the following:
403 - Forbidden: Access is denied.
You do not have permission to view this directory or page using the credentials that you supplied.
When running a settings test I get:
The server is configured to use pass-through authentication with a built-in account to access the specified physical path. However, IIS Manager cannot verify whether the built-in account has access. Make sure that the application pool identity has Read access to the physical path. If this server is joined to a domain, and the application pool identity is NetworkService or LocalSystem, verify that \$ has Read access to the physical path. Then test these settings again.
Any ideas?
THanks..
I don't have an answer I know is the solution, but here are my suggestions:
First, have you mapped the IIS default web site to the folder containing your site?
Second, check your basic apppool settings, and make sure it's set to use .Net 2.0. It'll be 2.0 even if you're using a later version, like 4.0.
Barring that, make a new folder in wwwroot and map the default web site to that. Do not mess with the permissions. Then, make a new apppool, don't fiddle with it's settings, and assign that to the default web site. Point here is that you shouldn't have to mess with any of those settings: IIS will take care of that and the permissions.
Final thought, if that doesn't help: check your isapi filter mappings to make sure it knows what to do with .aspx. That should have been set up by default as well, but it's worth a look at that point.