Error de servidor en la aplicación '/'. ASPNETDB.MDF ... EN LA PRODUCCIÓN DE SERVIDOR

Question

Me estoy poniendo el siguiente error al cargar mi sitio para Servidor de producción utilizando la base de datos en App_Data ASPNETDB.MDF

Error de servidor en aplicación '/'.

Tiempo de ejecución error

Descripción: error de aplicación Una ocurrió en el servidor. La corriente configuraciones personalizadas de error de este aplicación a prevenir los detalles de la error de aplicación de ser vistos remota (por razones de seguridad). Eso podría, sin embargo, ser visto por los navegadores que se ejecuta en la máquina servidor local.

detalles: Para habilitar los detalles de este mensaje de error específico para ser Se puede ver en las máquinas remotas, por favor crear una etiqueta dentro de una archivo de configuración "web.config" ubicado en el directorio raíz de la aplicación web actual. Esta etiqueta debe entonces su "modo" atributo ajustado en "OFF".

web.config:

<!-- Web.Config Configuration File -->
<configuration>
    <system.web>
        <customErrors mode="Off"/>
    </system.web>
</configuration>

Notas: La página de error actual que está viendo puede ser sustituida por una costumbre página de error al modificar el atributo "defaultRedirect" de la de aplicaciones etiqueta de configuración para el punto a una costumbre URL página de error.

<!-- Web.Config Configuration File -->
<configuration>
    <system.web>
        <customErrors mode="RemoteOnly" defaultRedirect="mycustompage.htm"/>
    </system.web>
</configuration>

M confundido por qué ESTA produjo un error ?? Y HIW de arreglar esto para mostrar WEB ...

Answer 1

Have a look at scottgu's article - Recipe: Deploying a SQL Database to a Remote Hosting Environment (Part 1) and an article from Scott Mitchell - Deploying a Local Database to a Remote Web Host

Answer 2

For quick troubleshooting only: Just follow what it was asking... open your web.config file and change the mode attribute to Off temporarily. I am assuming you have it redirect to something else at the moment that prevents you from seeing the real error.

In the long run, it's a good practice to capture and log errors into some sort of persistence media (db, log file, etc.) and troubleshoot from those. Perhaps thru a custom admin web interface to look at the errors or simply ftping the log files back to your machine and investigate it locally.