MVC Routes/RouteDebugger work when deployed to IIS7 but not in Cassini - asp.net-mvc

I am currently working on an MVC3 Application, and after fighting with some routes, noticed some odd behaviors:
I have added new routes, but these are not reflecting when I run the application with F5 in Cassini via Visual Studio 2010. If I deploy this same code to a server (with the same web.config) running IIS7, my new routes work.
I have installed Phil Haack's RouteDebugger tool. The web.config is set to have this enabled, but it does not display when running my site via Visual Studio 2010/Cassini. It works properly when deployed to a remote server with IIS7 - again, same config file.
Any thoughts? Is there some config/setup option that I am missing?
Thanks!

Looked to be a weird caching issue. After fighting with this for a day, by chance I opened up a different branch (main) of the same application, which worked fine.
Performed a reverse/forward integration and the main branch worked fine, dev branch still would not show the changes.
Did a comparison, and they were exactly the same bits.
Did a 'Get Specific Version' from TFS, overwriting everything, and the problem persisted.
Finally, I deleted both branches from my local drive, and then did a Get Specific Version, and suddenly everything worked. Odds are this solved the issue because it forced all of the bin/obj files to be wiped out (although in theory they should have been rebuilt since I was doing a Rebuild Solution).
All in all a really weird issue, so I figured I'd post this just in case someone runs into the same issue down the line, given the difficulty of debugging this.

Related

Web Config Issue with IIS 7.5 MVC 5 App

So I have an MVC 5 application which has been running fine and is published to two individual servers, with the same configuration, however one gives http status 500, the other works perfectly. Both servers are exactly the same windows release, and patched up to asp.net 4.5.1.
Browsing the site locally gives the source of the problem as the web.config file, with the relevant config source lines being -1: and 0: Both showing blank lines.
I've no idea what's going on with this one. I have copied the app in its entirety back from the working instance to the none working instance no avail.
I'm a bit stumped.
To note, i've also removed IIS and reinstalled as i thought that could be the cause of the issue.
So after much headscratching it turns out that some clown removed URL Rewrite module from this box. After reinstalling using the web platform installer all is well. I hope somebody finds this useful in future.
Nicolas Carlo, your response pushed me down an alternate route of diagnosing the problem and was helpful in this instance, thank you.

Umbraco 6 on Azure: UmbracoModule Service Unavailable

I'm deploying a new Umbraco 6 installation to Azure, and I've run into a problem I can't seem to diagnose.
Here are the steps I took to get the site deployed:
Created new MVC 4 project in VS2012
Installed UmbracoCms 6.0.0 via NuGet
Tested locally: SUCCESS
Set up correct connection string for Azure in Web.config (via transform)
Deployed to Azure using Web Deploy
Unfortunately, when I navigated to the Azure instance, I get a blank page with "The service is unavailable." I enabled detailed logging in Azure, and looked at the log files. There wasn't much that suggested a solution to me. This is what the detailed error says:
Module: UmbracoModule
Notification: ResolveRequestCache
Handler: PageHandlerFactory-Integrated-4.0
Error Code: 0x00000000
I'm out of ideas at this point...any ideas?
I've just gone through the steps of what you describe. I created a MVC4 project and downloaded Umbraco 6 via Nuget. What I did notice was that I had to 'include' a fair number of file into the project structure in the VS solution explorer.
I ran the website locally and ran an install just using SQL CE.
I created a website on Azure and I downloaded the .PublishSettings file and imported this into the Web Deploy options in VS. I then published the site 'as is' just to see what happened. I didn't expect the database to work but I just wanted to make sure that the application ran ok and I could at least access the Umbraco login screen.
When I accessed the site, it worked as expected and I could access the login screen at /umbraco/
Given the problems you are having, although this sounds simple, did you 'include' all the files in the solution explorer before deploying?
If you are still having issues, I would doing what I have done and just setting up another very simple site to test your deployment process. I have to be honest, I was surprised how easy it is.
I've just been through the same steps with the simple blog and it was quite hard. I didn't include anything into Visual Studio (except it's 2010 and I downloaded the publish profile) and the site ran fine locally.
On uploading Umbraco 6 to azure I got 'Could not load file or assembly MySql.Data, ' etc. .net error. Of course, it was there.
On repeating my deployment steps, swapping between Visual Studio, Web Matrix and Sql Azure Migration Wizard, checking it was release config on build etc. (not that it should need building) I got various 'The page cannot be displayed because an internal server error has occurred' on a blank white screen, and 'Could not load My.Sql' errors.
Coming back to it the next day, I deployed again, and my user had lost its role membership in the database. I ran the EXEC sp_addrolemembers again, and lo, the site now works. I wish I could be more specific on what went wrong and what got fixed, but it's all a bit voodoo.
I second what Digby said - make sure all your includes are, well, included and keep on deploying. I think azure is having a bit of a do lately, there was an outage last week on 23rd Feb.

MissingManifestResourceException on one server, not on others

I've been pulling my hair out over this one.
Our staging server (Windows Server 2008 R2 Standard) has recently stopped cooperating. To be more specific, when our ASP.NET MVC 3 site is started, it gives the exception
MissingManifestResourceException: Could not find any resources appropriate for the specified culture or the neutral culture. Make sure "Resources.TranslatedUrl.resources" was correctly embedded or linked into assembly "App_GlobalResources" at compile time, or that all the satellite assemblies required are loadable and fully signed.
which means the site goes through startup, but then encounters an error when trying to register our (customized) translatable routes using GlobalResources. The same code base works flawlessly on our demo server, virtual machine server and Visual Studio's development server. I even did a revert of the code base to a point in time where the site was demonstrably working, but no luck. This leads me to believe the problem is with the server itself, or IIS 7, in which the site runs.
Problem is, no one has (to my knowledge) done any reconfigurations of IIS or the server. I've been moving our CI from CruiseControl.net to TeamCity, but the compile and setup is done on a separate server, which, once all compilation and configuration is complete, moves the files to the staging server using Web Deploy. Is it possible that Web Deploy could, in some way, have altered the config of IIS or the server?
I suppose it is also possible that our hosting provider could have made some changes I don't know about, but it seems unlikely.
Any ideas? I'm all out of them myself.

IIS 6.0 suddenly shows directory listing instead of MVC 3 app

Over night an (internal, luckily) MVC web application has stopped working for me, without anything being changed as far as I know. The application itself absolutely hasn't been tinkered with in the last two days and the same goes for IIS.
The problem is that I get a directory listing of my www-folder instead of the applications default action (/Home/Index).
My www-folder contains the standard stuff:
bin
Content
Scripts
Views
Global.asax
Web.config
I have tried:
setting a "Specific Page" as Start Action but it doesn't solve the problem.
restarting the web page in IIS
enable/disabled "default content page" in IIS. Doesn't help, but IIS does pick up on a Default.html if I place it in the www-folder.
Now, this has happened once before. At the time I was on vacation and it was solved by restarting the entire World Wide Web Publishing Service. While it might work this time as well, I'd rather figure out the root of the problem before temporarily fixing it just to have it happen again further down the road. So while a WWW Publishing Service restart might get the site running again I'd rather understand why it happened in the first place before fixing it this way.
Finally, note that I'm running other MVC apps on the same IIS server and have never gotten this problem with them.
Open Command prompt
Go to C:\Windows\Microsoft.NET\Framework\<version> folder.
Run aspnet_regiis -i
That's all!
A little late.... But as I was receiving the same result.
My Application Pool was targeting the wrong .Net version (should be same as web app Target Framework). Simply adjusted within the "Set Application Pool Defaults" option, restarted and it was solved.
Hope it helps someone.
I had a similar problem.
The IIS root path had been changed by a collegue.
The solution was to fix the "Physical Path" in the "Advanced Settings" of the Default Web Site.
I don't think /Home/Index is possible to run om IIS 6.0 with out any configuration. ASP.NET MVC actually requires "Intergrated Mode", but could be run on classic with applying configuration.
That article by mister Haack, could be helpful: http://haacked.com/archive/2008/11/26/asp.net-mvc-on-iis-6-walkthrough.aspx
Saw this problem when I added a folder called "documents" at the root and also had a DOCUMENTS controller & view. I think it was confused if I wanted the route \documents which is in the CONTROLLER folder or the \documents folder below the root. One solution was to add an id to the route which makes it use the controller version of documents
Url.Action("Index", "Documents", *New With {.id = 1}*)
Can also change the name of the newly added folder below the root to DOCS.
Changing the .NET CLR version of the application pool might help.
Right click on the application pool in which your application is running and select Advanced Settings...
Change the .NET CLR VERSION to the version of your application(same as that in the config files)
Click ok
I had the same problem and here is how I resolved it.
I had a problem with the Global.asax file on the TFS server inheriting from the WebAPI project (and not the web project) although the web project was chosen as the startup project in Visual Studio. When I ran my build the Web API was set as the start up project on the web server since it was deploying the version on the TFS server that was inheriting from the WebAPI project. To resolve this I set another project as the startup project and then changed the web project to be the startup project again in Visual studio. I had to do this since TFS complained that there were no pending changes when I tried to check the version I had on my machine into TFS. I then checked my code in and ran the build again. This resolved my issue.

Deploying MVC Application to Web Server doesn't run correctly

I have reading posts all night looking for an answer to my issue and haven't found anything that works for me yet. I am sure there is a simple way to do this but I haven't been able to discover it yet.
Details:
MVC 2 Preview
Asp.net 3.5 sp1 framework
VS 2008 C# web application
Windows Server 2008
IIS 7
I have the application running well through VS 2008 no problem. When I hit the play to run in debug mode it starts the ASP.NET Development Server the application loads fine and works as expected, great!
When I publish the application locally or to my web server both on IIS 7 the application doesn't run correctly. Some of the icons are missing and the google maps map is missing. When I view the source it appears correct at first glance, but I can see the paths to the images are looking for the MVC paths and it isn't finding them. It appears the app is running as a regular asp.net app and not an mvc app, maybe?
I also tried to just hit the full source code locally on localhost and the exact same issue is present.
So, I guess my question is how do I deploy a MVC application to run the same in IIS as it does through the development server.
PS The environments are clean and pretty much out of the box.
#user68137 is correct in saying that you need to use relative paths for the images.
I got caught out on this one too, and here's my previous SO question about it...
In short, you need to do something like this...
<img src='<%= Url.Content( "~/Content/Images/banner.jpg" ) %>' alt="Banner" />
Hope this helps!
I had the relative paths set, but what I didn't realize is when I deployed it to the server it went to wwwroot\subsite... I had the relative paths set to src="....\image.jpg" to get back to the root of the site. My error was that if the site is not in the root then the subsite drills back to the root to find the images and of course doesn't find them. Same thing was happening with the JS files. I used the Url.Content and it worked great! problem solved!
The interesting this is when running through the VS dev server with a subsite it still worked well and found the paths even though it shouldn't have. VS dev server <> IIS
Thanks for your help on this!
Simon.
Once you know the virtual path to the location you are deploying the project to, you should go into the project configuration in Visual Studio and add it to your project. This way the visual studio development server will use the same path structure as the deployment server. This will save you countless hours of work when deploying.
When you run your website through Visual Studio, every single request gets processed through the ASP.NET pipeline, including images, CSS and other resources. IIS by default only processes specific extensions (e.g., aspx) unless you tell it otherwise through configuration. Paths like '/content/images/yourimage.jpg' should work just fine...I suspect it's something amiss in your IIS configuration.
Another possibility which I've run into is any custom ISAPI filters you may have installed on the IIS server (e.g., ISAPI_rewrite). It's easy to set up rules in its configuration that lead to some very unexpected results.

Resources