ASP.NET MVC 5 doesn't show the error messages - asp.net-mvc

Question

I have the following configuration in my "web.config":
<customErrors mode="Off">
</customErrors>
<compilation debug="true" targetFramework="4.5" />
<httpRuntime targetFramework="4.5" />
<pages>
<namespaces>
<add namespace="System.Web.Helpers" />
<add namespace="System.Web.Mvc" />
<add namespace="System.Web.Mvc.Ajax" />
<add namespace="System.Web.Mvc.Html" />
<add namespace="System.Web.Routing" />
<add namespace="System.Web.WebPages" />
</namespaces>
</pages>
If I have a mistake in my environment clearly shows errors, but when I upload it to windows azure shows the screen where it tells me that I have to put:
<customErrors mode="Off" />
or
<customErrors mode="RemoteOnly" redirectMode="~/file.html" />
and not shows errors. Is there some extra settings that I have to do in "web.config" in "ASP.NET MVC 5" to show the errors?

Answer 1

The default for publishing to Azure is to use the Release configuration. The Release configuration, among other things, disables the yellow screen of death you see in development, because this is information that 1) is potentially dangerous if seen by the wrong person (malicious) and 2) is not user-friendly for the casual user.
If you want to see the errors, then you follow the advice on that page. If your problem is that you have done that, and the errors still aren't showing then #Zabavsky, is probably right; you didn't add it to the configuration that it was deployed with (most likely Release).
However, I would caution you from actually doing that. Like I said earlier, the stack trace shown on error can potentially contain sensitive information that a malicious user could use to compromise your site, and if you turn it on in Release, even if just for a little while to debug, there's a good chance you might forget to turn it off. The ideal is to work out all your bugs in development. For the final verification when deploying to Azure, you can deploy using the Debug configuration (which will show the errors) to a staging version of your site. Then, once everything is good, you can do the final deployment using the Release configuration, instead.
If you want to get the stack trace from errors in production on an ongoing basis, your best bet is to use a tool like ELMAH, which will log exceptions that occur and present them to you in a protected way. By default, that will be only over localhost, which would require that you browse from within the server the site is running on. If you can't do that because you're just using an Azure Website instead of a virtual machine, then you can also enable access to a certain user role, or only via a certain IP (your static IP).