I have developed an app on a dev machine using ASP.Net MVC and all is fine and it works. I have moved it to the Prod Server and when I type http://mydomain.com I get the error:
The incoming request does not match any route
If I then make a request to http://mydomain.com/pagename I then get a IIS 7 404 page.
It is hosted in a Full Trust Mode and Integrated Pipeline according to Softsys hosting who its hosted with.
I am currently accessing the site via a temporary DNS name eg/http://mydomain.com.serv7.temphostspace.com and my host believes this might be it.
From the support ticket this is what they say *"I believe, this is caused since you are access your website through temporary URL http://mdomain.com.serv7.temphostspace.com/ and relevant setting might be missing in your configuration."
Any ideas?
Thanks
Your host is probably barking up the wrong tree, unless the site isn't configured. I'd try and request a static file you know is there to be certain. As for the problem at hand, how are you wiring up the routes? Could something in production be failing before this and prevent this from happening?
Anyhow, first place I would start is by using the ASP.NET Routing Debugger to see what routes your app thinks it has.
Similar problem: ASP.NET MVC running IIS7 deployment problem
Resolution from there: http://haacked.com/archive/2008/11/03/bin-deploy-aspnetmvc.aspx
Turns out it was trust issues not configured right
Related
We're moving an instance of a third party, .NET-based website to a Win2016 server, IIS 8, from an external hosting service. Under the site, there's a WCF web service in a subfolder. There are no virtual directories or apps.
mysite.../Order/v4/service.svc
When I browse to pull the wsdl (https://MySite.../Order/v4/Service.svc?wsdl ), it is redirecting to Login.aspx (https://MySite.../Order/v4/Login.aspx).
Browsing to https://MySite/Order/v4/Service.svc?wsdl redirects to https://MySite/Order/v4/Login.aspx .
IIS has no default document set / web.config's defaultDocument is commented out.
Vendor indicates
That would be a redirect that was setup either on IIS or another
appliance that is doing that.
Same behavior occurs running on the server itself (localhost) and sys eng confirms it shouldn't be leaving the network to hit any firewall.
There are no other .config files on the server with any reference to "Login.aspx".
This still feels like it is some piece of configuration but even doing things I shouldn't need to do like restarting the server just to make sure no caching of settings is hanging around isn't affecting it.
Any guesses on what might be attempting to redirect?
Following Rich-Lang's suggestion in comments provided the information to identify that the global.asax file was handling an error in the web.config. Since the code in this case was in codebehind in a dll, and the vendor indicated their code does not redirect, I had not seen that culprit before. Removing the global.asax and turning off customErrors allowed me to see the underlying issue.
I got an MVC project working in IISExpress. But when hosted in Azure app service and local host's IIS, I got 302 redirect from http://localhost//facebookapp/start to http://localhost/(S(gf3a4leuiyjafjltxdjabhae))/facebookapp/start, then get 404.
I also reported this here
I realize this must be a router problem, but I have no clue how to trace it down. Any help is appreciated!
Thanks!
Turns out the application I used the sample used localhost/facebookApp as the virtual directory, which certainly won't work if i blindly published to azure and IIS host.
I've developed a new WEB API 2 that works great locally, however when I upload the same code to my production server (Arvixe in this case) all I get is a 404 when I call it. I've spent HOURS searching the web, reading forums, etc.. and have been able to find no resolution, so I'm asking here as my last effort.
I'm currently only testing with the default project that gets created when you do New Project > ASP.NET Web API 2 Empty Project in Visual Studio. This creates an empty project with a single ValuesController. You should be able the JSON response by called /api/values, but this doesn't even work.
I'm using Fiddler to test the API locally and on the web server.
http://localhost:1993/api/values <--- works great
but
http://api.mydomain.com/api/values <--- returns 404
Note: I created a subdomain "api" in this case, but everything for the code for the API is unchanged from when it was created.
Why in the world does this work locally but not on the production web server?
That the server returns 404 (Not Found) may indicate a lot of things. However you can check using the following step:
Add a simple text document like readme.txt to your a folder sub-domain http://api.mydomain.com, and try to get access to that. If you can't access to that file, it means that the subdomain is not configured properly.
Publish the webservice using the "Publish" functionality, so that all DLLs will be copied.
After that,try to reach the Web ApI again.
Hope that help.
"Note: I created a subdomain 'api' in this case, but everything for the code for the API is unchanged from when it was created."
Above comment of your's is suspicious, you should publish your WEB API application in the root directory. Like if http://example.com is pointing to "MyExample" folder, then application should be published on "MyExample" folder.
After that you will be able access your api with http://example.com/api/{controller}/{action}
Just a simple suggestion which I'm sure you have already considered, but have you opened the http port 80 on the server's firewall?
Also stick a plain old html file in the root of your project and see if the server serves it up.
in your case, since you create a subdomain of 'api', you should try
http://api.mydomain.com/api/api/values
note that if you're using database for the function, you should change the connectionString in your web config
Please verify the .net framework on you hosted domain that may be old one.
Web api 2 is supposed on 4.5 framework.
One reason for web api 2 method working OK on local machine but not on production server is that the method you are calling is working on local machine but not on remote server. In such a case you will receive message 404 or 500, and you would be lost why this routing is failing.
Why a method would fail on remote server, well there may be many reasons. For me, I was querying database in my method and my connectionString was not set for remote server.
One way of resolving it would be to put some very simple code in that particular method and test that routing is working. Then check your original code for errors reasons.
I have a fairly detailed problem with which I hope someone can help. Basically, I have a .NET 4.0 website hosted on IIS7 that has some pages that necessitate URL rewriting. In order to implement these features, I have added a method to my global.asax that maps the extension-less URLs to their proper ASPX pages, and then performs a context.RewritePath in order to display the correct page.
Initially, I called this method from application_BeginRequest. However, we have some business necessary logging that occurs when Session_Start is called, and it appears that this logging is not always happening since the implementation of the URL rewriting in application_BeginRequest - Basically, every session gets logged in the DB, and after initial deployment of the URL rewriting, our session logs have dropped by about 20%, with no corresponding errors in the application log. At the same time, our IIS logs seem to be showing a relatively unchanged amount of traffic, so to my eyes, it appears that the sessions are not instantiating properly.
As a workaround for this issue, I moved the URL rewriting from application_BeginRequest to application_AcquireRequestState, so that this code won't fire until after I'm (mostly) sure that the Session has started. This works in my local dev environment and on our staging server (Windows Server 2008 - IIS 7 - .NET 4.5 Framework installed). In the Production environment (Windows Server 2008 - IIS 7 - .NET 4.5 Framework), I get 404 errors when trying to browse to the extension-less URL to be re-written.
I'm completely stumped - I've verified that I'm using the Integrated app pool, my web.config has the "runAllManagedModulesForAllRequests=true" attribute, my IIS features include HTTP redirection and static file compression, but nothing appears to be working. There's a hack that I found for using the Classic app pool, and creating extra script map handlers to handle wildcard URLs with no extensions, but I'm hesitant to put that in place in production.
Any help you can provide would be greatly appreciated. Thank you!
I would concentrate on why there was a 20% drop in session logs. Are you sure there wasn't also a drop in traffic? Are you using redirects for people coming to your site using the old .aspx Urls? Perhaps you received more 404 traffic that would not trigger the Session_Start? Did Google Analytics confirm that traffic maintained normal levels after the UrlRewite was put into place? You could also use IIS Log Parser to filter out static files and query 200 vs 404s from the log files to get a better sense of actual traffic.
I am building an asp.net web application which has been working on local and staging. however, when i deployed to live, there is a little weird issue occurred. below is the live environment details.
live environment:
Server 2003
IIS 6
when the request url is below, if page not found, it will redirect to page 404 configured in the IIS.
"http://www.xxxx.com/folder1/default.aspx"
however, when the request url is below (with a dot in the folder), it will show a IIS default 404 message which is "The system cannot find the file specified." which isn't what i configured in the IIS and it seems like it skips all the http handlers and modules. Therefore, my custom http handler stop working with this kind of url.
"http://www.xxxx.com/folder.1/default.aspx"
My guess it something to do with the IIS setting. i have have several research, there is no other issue like me.
appreciated if anyone can help. Thanks a lot.
Dion
One of the possible reason could be tool such as UrlScan - you need to explicitly configured it to allow dot(.)s in the url - this can be done by editing <Windows Folder>\system32\inetsrv\urlscan.ini and setting AllowDotInPath=1