I am trying to get a demo site for a client setup. This is the 1st application my company is doing in MVC.NET, so I get to experience all the new things to find out (and all the headaches it'll cause).
Anyway, the site works fine locally (localhost) and on the server inside our domain. External users not on the domain however, only get 404 errors. I've tried several different settings/ config options I've found on this site, but nothing is working. I don't know if it's a web.config issue or an IIS issue, or even simply a permissions issue (though it has all the same permissions as the other sites we run with Web Forms).
IIS: v7 in intergrated mode.
Windows Server Web
Well, because you received a 404, the server is being reached okay which is a good sign. (Dealing with firewall issues at a company is always a lot of fun.)
A common problem for something like this is the use of virtual directories to host the website. For example, if the address to your site is http://example.com/MySite/, in MVC that would translate to: /MySite/View/Index.aspx. HOWEVER...if you are using virtual folders, /MySite/ may instead point to another spot on the server (e.g. C:\WebSites\MySite). If you are indeed using virtual paths, make sure you have your files stored at the correct path.
There is a troubleshooting tutorial here: http://support.microsoft.com/kb/248033
thanks for the answers everyone. Turns out it was something with our DNS routing setup with the sub-domains. It was getting rerouted to a place that didn't exist. Our IT guy finally got around to fixing it (ugh!)
Related
After publishing a MVC5 web application of mine to my IIS server (Individual User Accounts), it would seem that the URL is accessed incorrectly.
During debug, it would be e.g http://localhost:1234/api/Account/UserInfo?=XXXXX
The debug works just fine. The only issue kicks in after I've published it via my IIS7 server.
After publishing and using Google Chrome's console, it would appear that the page is requesting for a resource at mydomainname.com/api/Account/UserInfo?=XXXX instead of mydomainname.com/WEBAPPLICATIONNAME/api/Account/UserInfo?=XXXX.
My best guess is to modify the URLs in /Scripts/app/app.datamodel.js but it would just cause more parsing problems.
I've searched around and can't seem to find any related problems. I hope someone here will be able to lend a hand.
Look like you are using relative path like "/api/Account/UserInfo". Instead i'll recommend you to use #Url.Content("/api/Account/UserInfo"). This will solve your problem
Explanation
In local system when we run application in WebDev server it never have sub folder (like WEBAPPLICATIONNAME) therefore you relative path work correctly. but when you host your application in IIS under Default website in another new website /Virtual folder (like 'WEBAPPLICATIONNAME') then "/api/Account/UserInfo" fall back to Default Website because for '/' in starting. #Url.Content or #Url.Action make sure to add virtual directory name, hence changing your path to "/WEBAPPLICATIONNAME/api/Account/UserInfo" in IIS.
I just deployed a new MVC 4 web application and have been keeping an eye on the IIS logs to make sure everything is running smoothly. I noticed that some user's browser's request two files that do not exist in my project and I have no idea what they are: eh.js & eh.css. These two files are not part of my project and I don't know why they are being requested from the server, IIS returns 404. Has anyone else ran into this? Can anyone tell me what eh.js & eh.css are?
Well I feel sheepish, eh.js and eh.css are resources on my organization's error page.
I have an MVC 4 web site with an ApiController which has a Post method.
Locally everything is running just fine, I can post successfully.
However after I deploy to Azure, I get a 404 message.
I have tried everything I found within the first 7 pages of google..
I've tried the famous solution of adding the runAllManagedModulesForAllRequests module also.
Please help...
It would be helpful to see some code, hard to speculate otherwise.
Azure however, manages its resources separately. Are you pointing to the absolute path in Azure? Referencing resources locally within azure doesnt work unless you've set up a virtual lan and are referencing another machine in that lan.
I am testing an mvc4 site locally and have set up my hosts file / IIS so that I can run it from a test domain name. I am following instructions from here: http://ben.onfabrik.com/posts/oauth-providers
When I access it via the bound domain set up in IIS it does 'work'... but the entire contents of _Layout.cshtml are missing. All that displays is the html from the View being called.
When I run the site using the Debugger, or on live hosting it comes up as expected. So I don't think there's any problem with paths, or using ViewStart.
It's only when accessing it via the domain (bound to localhost on IIS) that the _Layout.cshtml content is missing.
Any ideas as to why this might happen and how I can resolve it? Thanks
This doesn't answer the question, but until somebody can offer a better response, it might help others in a similar position.
I had to run the site from VWD using the Debug button - that runs the app on the standard .Net Development Server, which gives you a port number.
Adding that port number to the end of my domain name made my _Layout.cshtml display.
e.g. http://testdomain.com:54829/
I'm building an ASP.net mvc app, and am having some problems getting ELMAH deployed using xml logging to a medium trust server, though it works fine on my local machine. It keeps getting a 404 error.
The problem might be that the host doesn't allow relative filepaths, so the "~/App_Data" doesn't work for logging. I switched that to:
logPath="\\Something\Something\ID\www.website.com\web\content\App_Data"
in the web.config. The syntax might be completely off, but I've tried a few variations and none of them worked.
I subsequently found this question and added the recommended code to my web.config, but still no luck. Does anyone know how to get ELMAH to work on medium trust?
Thanks!
The asp.net worker process (or the aspnet user) has minimum rights to write into the filesystem. Try a place like c:\temp where everybody can write files. After this check and set access rights for aspnet user.
It turned out that the ELMAH.dll was calling SQLite, which isn't allowed under medium trust, and was causing ELMAH to fail when deployed to medium trust. I needed to download the source code for ELMAH and re-build it without the reference to SQLite. It is now working. Yay!