Error 404 when deployed through AspNetCoreModule
tbprince opened this issue · 11 comments
Hello,
just tried to deploy a quick start project to IIS using AspNetCoreModule (but I have to say that HttpPlatformHandler yelds the same results).
Project has been published as a framework-independent app which means that the whole .NET Core Framework gets published to support server where .NET Core hosting bundle had not previously installed.
So basically you create an image to publish like this:
dotnet publish --self-contained -r win-x64
That has been moved to server which is actually using Windows Azure Pack which is something similar to Azure AppService (in facts, I believe they are the same technology).
web.config file has been configured like this:
`
<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath=".\Server.exe" stdoutLogEnabled="true" stdoutLogFile=".\stdout.txt" />
</system.webServer>
`
So what it seem to happen is that server.exe starts and IIS proxies request to the process but once it does that, 404 is returned for root (/) request.
It seems the process (and not IIS) is handling the requests and returning a 404 as pet AspNetCoreModule log file.
'
info: Microsoft.AspNetCore.DataProtection.KeyManagement.XmlKeyManager[0]
Azure Web Sites environment detected. Using 'C:\home\ASP.NET\DataProtection-Keys' as key repository; keys will not be encrypted at rest.
Hosting environment: Production
Content root path: C:\home\site\wwwroot
Now listening on: http://127.0.0.1:30146
Application started. Press Ctrl+C to shut down.
info: Microsoft.AspNetCore.Hosting.Diagnostics[1]
Request starting HTTP/1.1 GET http://safedemo.eu-w.cloudapps.enterprisehost.biz/
info: Microsoft.AspNetCore.Hosting.Diagnostics[2]
Request finished in 67.5888ms 404
info: Microsoft.AspNetCore.Hosting.Diagnostics[1]
Request starting HTTP/1.1 GET http://safedemo.eu-w.cloudapps.enterprisehost.biz/favicon.ico
info: Microsoft.AspNetCore.Hosting.Diagnostics[2]
Request finished in 1.7730000000000001ms 404
'
Any hint ? Onto the file system contents of the server folder has been published to wwwroot folder while Shared and Client have been placed into the appropriate parent folder to the actual file system layout is:
C:\home\site\Client <---- Client folder contents here
C:\home\site\Shared <---- Shared folder contents here
C:\home\site\wwwroot <---- Server folder contents here
Any hint ?
Thanks.
Hello,
while digging better into the quickstart sample it seems that two different servers are started when using
' fake build --target run'
The first one runs on port 8080 and that's what browser connects to while another server runs on port 8085. I do believe that in my tests I'm only starting the latter and that's why I always get a 404.
Thanks.
The standard fake script runs by using the webpack dev server. It hosts the front-end for hot module reloading etc. and proxies requests to the server automatically. Have a read here for how to transition to a "static" deployment process. In such a case, all your client & server files are emitted into a single folder and the server (saturn, giraffe etc.) hosts the client-side assets (html, compiled javascript etc.).
Also check out the IIS deployment option - this contains an extra "bundle" task which does exactly the above and should do what you're after.
Can you give that a go and let us know how you get on?
Thanks
Hello @isaacabraham ,
I was able to solve my issues, it seems. Basically the problem was related to the Client folder. When the server starts it seems that it was not able to properly locate the Client folder. Default configuration expects (correct me if I'm wrong) to access that from "../Client/public" in
let publicPath = Path.GetFullPath "../Client/public"
for whatever reason it was not able to access that. I was able to put the Client folder outside the root folder (wwwroot in my case) and the layout now looks like this:
c:\home\site\wwwroot\ <------ This is where "Server" contents reside
c:\home\site\Client\ <------ This is where "Client" folder contents reside
Now it works fine using AspNetCoreModule.
The interesting thing is that wwwroot is the public root for the website where only DLLs and config files (plus the EXEs and config JSONs) reside while - if I'm not wrong - the public folder is the public root folder for the application.
This configuration is interesting because you can basically run this app without having .NET Core dependencies installed on server. In my case, I'm using .NET Core 3.1.200-preview-014883 and that is not installed on the server where SAFE runs.
Basically this is a shared hosting configuration similar to Azure Websites v2.
Hope this helps anyone else !
Thanks for your help.
@markCompostional how far did you get with this - did it work for you in the end?
@tbprince thanks for digging into this - something has evidently changed then. I just don't know what has!
@tbprince thanks for digging into this - something has evidently changed then. I just don't know what has!
Hello @isaacabraham,
contents of the Client folder have probably not been deployed at our first attempt or have not been deployed the way it should. The demo is now working fine at:
http://safedemo.eu-w.cloudapps.enterprisehost.biz/
As this is a technology similar to Azure WebSites v2, the interesting part is that it can be scaled out and it is using a framework-independent deploy. I also suspect that we can manage to use Ready-To-Run deployment which is part of ASP.NET Core 3.x to improve startup times and tiered compilation, again part of ASP.NET Core 3.x, to improve startup times as well. Those will be our next tests before we consider SAFE deployable on our hosting services.
As far as you know, is there any security issue in deploying with that layout ? Is there any specific file that we would need to protect? As of now, the server files are deployed into the publicly-accessible wwwroot folder though I guess they are not reachable since every connection is proxied to ASP.NET Core and since it will look for files into the Client/public folder. But since I'm new at SAFE, just wanted to check it with you.
Thanks 😊
That sounds like it would be fine :-) Ready-to-run is something new that we want to incorporate into the SAFE template as well in the future!
That sounds like it would be fine :-) Ready-to-run is something new that we want to incorporate into the SAFE template as well in the future!
We will try to publish using R2R and tiered compilatoin (still framework-independent) and I will post results tomorrow. 😊 Just to let you know.
just to let you know that we have been able to publish the demo app with tiered-compilation and Ready2Run images (win-x64) enabled. So far, so good.
We only had an error during the
fake build --target bundle
phase since we received an error about the missing RID specification notwithstanding the fact that we had placed the RID (win-x64) inside the fsproj file. Thus we decided to remove those settings during that fake build phase and then re-enable for the
dotnet publish --self-contained -r win-x64
phase that prepared the files that we published onto the server. No error during the compilation and it works fine when run onto the server.
Hope this was helpful. :-)
I think that this is all fixed with SAFE 2.
@isaacabraham I think this can be closed down