ASP.NET Core 1.0 en IIS error 502.5

112

Acabo de actualizar mi servidor (Windows 2012R2) al .Net Core 1.0 RTMpaquete de alojamiento de Windows del anterior .Net Core 1.0 RC2. Mi aplicación funciona en mi PC sin ningún problema, pero el servidor sigue mostrando:

HTTP Error 502.5 - Process Failure


Common causes of this issue:

The application process failed to start
The application process started but then stopped
The application process started but failed to listen on the configured port

Anteriormente trabajó con la versión RC2. No sé qué podría salir mal.

Esto es todo lo que el visor de eventos dice:

Failed to start process with the commandline 'dotnet .\MyWebApp.dll'. Error code = '0x80004005'.

¡la peor parte es que los registros de aplicaciones están vacíos! Me refiero a que esos archivos stdout_xxxxxxxxx.log están completamente vacíos y todos tienen un tamaño de 0 bytes.

¿¿Qué tengo que hacer?? ¿Cómo puedo saber la causa del error si no está registrado?

Vahid Amiri
fuente
¿Posiblemente relacionado? stackoverflow.com/questions/37362183/…
Brendan Green
3
¿Cómo se relaciona? El código de error es claramente diferente. Por no hablar del hecho de que dije que funciona en mi propia PC con IIS.
Vahid Amiri
1
Primero, dije posiblemente relacionado, ya que menciona eso Failed to start process with commandline 'dotnet ./bin/Debug/netcoreapp1.0/WebApplication2.dll', Error Code = '0x80004005'.: la misma línea de comando y código de error que está informando. En segundo lugar, solo porque se ejecuta en su máquina, pero no en la máquina remota, indica que algo es diferente en el servidor. Si pudiera ampliar sobre cómo se implementa la aplicación en el servidor, sería útil.
Brendan Green
¿A qué te refieres con que tu aplicación funcione en tu PC? ¿Quieres decir que tienes un proyecto que se está implementando en iis? ¿Soy Ryt?
Vijunav Vastivch
1
@ VSG24 ¿Viste esta sección del documento de asp.net? Al publicar en IIS , enumera errores comunes y tiene un par de razones enumeradas para el error 502.5.
Hamid Mosalla

Respuestas:

112

Pude arreglarlo ejecutando

"C: \ Archivos de programa \ dotnet \ dotnet.exe" "C: \ fullpath \ PROJECT.dll"

en el símbolo del sistema, lo que me dio un error mucho más significativo:

"No se encontró el marco especificado 'Microsoft.NETCore.App', versión '1.0.1'. - Verifique las dependencias de la aplicación y elija una versión del marco instalada en: C: \ Archivos de programa \ dotnet \ shared \ Microsoft.NETCore.App - Se instalan las siguientes versiones: 1.0.0 - Alternativamente, instale la versión del marco '1.0.1'.

Como puede ver, tenía instalada la versión de NET Core incorrecta en mi servidor. Pude ejecutar mi aplicación después de desinstalar la versión anterior 1.0.0 e instalar la versión correcta 1.0.1.

hatsrumandcode
fuente
2
Me las arreglé para usar esto para encontrar que necesitaba NodeJS instalado ... ya que da un "mensaje mucho más significativo".
Tim Harker
No puedo decirte cuánto tiempo perdí en esto. Gracias. Mi error estaba relacionado con un certificado faltante. ¿Por qué no pude obtener este error a través de algún método sensato?
Sprague
4
¿Alguien puede decirme cuál es el comando? ¿Qué es C: \ fullpath \ dotnet? La ruta a su aplicación, pero ¿qué es dotnet ? No hay ningún archivo dotnet en la carpeta del proyecto
Jeremy Thompson
9
@JeremyThompson es la ruta del dotnet.exe que normalmente se encuentra en: C: \ Archivos de programa \ dotnet \ dotnet.exe
hatsrumandcode
1
Me encontré con este error después de que una actualización de .NET CORE 2.1.3 lo solucionó instalando el tiempo de ejecución / SDK de .NET correcto.
Mike Bovenlander
68

Tuve el mismo problema, en mi caso fue un permiso insuficiente de la identidad de usuario de mi grupo de aplicaciones, en la publicación en la página IIS de asp.net doc, hay un par de razones para este error:

  • Si ha publicado una aplicación autónoma, confirman que no ha configurado una plataforma de buildOptionsde project.jsonque los conflictos con el RID publicación. Por ejemplo, no especifique una plataforma de x86 y publique con un RID de win81-x64 ( dotnet publish -c Release -r win81-x64). El proyecto se publicará sin advertencias ni errores, pero fallará con las excepciones registradas anteriormente en el servidor.
  • Verifique el processPathatributo en el <aspNetCore>elemento en web.config para confirmar que es dotnetpara una aplicación portátil o. \ My_application.exe para una aplicación autónoma.
  • Para una aplicación portátil, es dotnet.exeposible que no se pueda acceder a través de la configuración de PATH. Confirme que C:\Program Files\dotnet\existe en la configuración de PATH del sistema.
  • Para una aplicación portátil, es dotnet.exeposible que no sea accesible para la identidad de usuario del grupo de aplicaciones. Confirme que la identidad del usuario de AppPool tenga acceso al C:\Program Files\dotnetdirectorio.
  • Confirme que ha hecho referencia correctamente al middleware de integración de IIS llamando al .UseIISIntegration()método de la aplicación WebHostBuilder().
  • Si está utilizando el .UseUrls() método de extensión cuando se autohospeda con Kestrel, confirme que esté colocado antes del .UseIISIntegration()método de extensión en WebHostBuilder(). .UseIISIntegration()debe establecer el Urlpara el proxy inverso al ejecutar Kestrel detrás de IIS y no tener su valor anulado por .UseUrls().

En mi caso, fue la cuarta razón, la cambié haciendo clic con el botón derecho en mi grupo de aplicaciones, y en la configuración avanzada en Modelo de proceso, configuré la Identidad para un usuario con suficiente permiso: identidad de usuario de mi grupo de aplicaciones

Hamid Mosalla
fuente
1
¡Esta es la respuesta que estaba buscando !, en mi caso también era el grupo de aplicaciones ....
Armando Ramirez
3
Gracias. En mi caso, el problema fue con la ruta a dotnet. Encontrado tales registros en el sistema de Visor de sucesos: Failed to start process with commandline '"dotnet" .\PROJECT.dll', ErrorCode = '0x80070002'.
0x49D1
Yo agregaría otra razón: "El instalador no puede obtener VC ++ Redistributable" ya que mi servidor no tiene conexión a Internet, no pudo descargar este paquete ... Por lo tanto, debe descargarlo manualmente: vincular e instalarlo.
Paco Mendez
4
dotnetestaba en mi camino, pero requería reiniciar el servidor para que fuera reconocido.
Danny Cullen
en mi caso, tengo que especificar --runtime value en el comando de publicación si proporciono la opción --framework; de lo contrario, NO proporcione --framework y está calculando el tiempo de ejecución de forma predeterminada.
Gomes
65

Conseguí que esto funcionara con un restablecimiento completo de IIS (acababa de instalar el paquete de alojamiento).

Resulta que simplemente presionar 'Reiniciar' en el Administrador de IIS no es suficiente. Solo tenía que abrir un símbolo del sistema y escribir 'iisreset'

michael_hook
fuente
También presioné las iis de reciclaje verde en el nodo raíz del servidor web en la interfaz de usuario. Esto lo resolvió para mí combinado con la configuración del usuario para el grupo de aplicaciones paraLocalSystem
JP Hellemons
Gracias Michael ... Esto también resolvió mi problema. Había estado buscando una respuesta durante un par de horas. ¡Gracias!
birwin
2
Tx! Su respuesta me recordó esto de ms docs "Reinicie el sistema o ejecute net stop was / y seguido de net start w3svc desde un símbolo del sistema para detectar un cambio en la RUTA del sistema". (después de instalar el paquete de alojamiento de .NET Core Windows Server)
Quinton Smith
También resolvió mi problema. Gracias
Met-u
Trabajó para mi. Gracias :)
Husnain Shabbir
11

Así que obtuve un nuevo servidor, esta vez es Windows 2008R2 y mi aplicación funciona bien.

No puedo decir con certeza cuál fue el problema con el servidor anterior, pero tengo una idea.

Entonces, debido a que previamente compilé la aplicación sin ninguna plataforma en mente, me dio la dllversión que solo funciona si el host de destino tiene el .Net Core Windows Hostingpaquete instalado. En mi caso estaba instalado y estuvo bien .

Después de que la aplicación no funcionó, decidí compilarla como una aplicación de consola con win7-x64tiempo de ejecución. Esta vez, en el momento en que ejecuté el exede mi aplicación en el servidor, se bloqueó con un error sobre una dll faltante:

The program can't start because api-ms-win-crt-runtime-l1-1-0.dll is missing

Ese dll es de Universal C Runtime que se incluye en Visual C ++ Redistributable para Visual Studio 2015 .

Intenté instalar ese paquete (tanto x64 como x86) pero falló cada vez (no sé por qué) en Windows Server 2012 R2.

Pero cuando intenté instalarlos en el nuevo servidor, Windows Server 2008 R2, se instalaron correctamente. Esa podría haber sido la razón detrás de esto, pero aún no puedo decirlo con certeza.

Vahid Amiri
fuente
5

Tuve el mismo problema al publicar la aplicación web. Si alguien aún tiene este problema, lo solucionó cambiando {AppName} .runtimeconfig.json

    {
  "runtimeOptions": {
    "framework": {
      "name": "Microsoft.NETCore.App",
      "version": "1.1.2"
    },
    "configProperties": {
      "System.GC.Server": true
    }
  }
}

Cambie la versión de "versión": "1.1.2" a "versión": "1.1.1" y todo funcionó bien

npo
fuente
5

Yo tuve el mismo problema.

Para averiguar la fuente exacta, encendí el registro en el archivo web.config:

<aspNetCore processPath="dotnet" arguments=".\MyWebService.dll" stdoutLogEnabled="**true**" stdoutLogFile=".\logs\stdout" />

y creó la subcarpeta de registros en la carpeta raíz MyWebService.

Después de reiniciar IIS e intentar ejecutar la API, recibí un error y faltaba el Core Runtime adecuado. Después de descargar una instalación DotNetCore.1.0.5_1.1.2-WindowsHosting, el error desapareció.

Eduard Silantiev
fuente
3
En mi opinión, debe eliminar los asteriscos del valor "verdadero" para evitar cualquier confusión.
AperioOculus
4

Tuve el mismo problema y todas las soluciones no funcionaron. Encontré esta joya y pensé en pasarla si ayuda a alguien más. Instale en Server 2012 R2 y obtenga el error de DLL que falta, intente reinstalar VS C ++ 2015 y obtenga un error. La solución es hacer lo siguiente:

Parece que el archivo C:\ProgramData\Package Cache\...\packages\Patch\x64\Windows8.1-KB2999226-x64.msutiene problemas para instalarse. Abra el símbolo del sistema de administración:

c:
mkdir tmp
mkdir tmp\tmp
move "C:\ProgramData\Package Cache\...\packages\Patch\x64\Windows8.1-KB2999226-x64.msu" c:\tmp
expand -F:* c:\tmp\Windows8.1-KB2999226-x64.msu c:\tmp\tmp
dism /online /add-package /packagepath:c:\tmp\tmp\Windows8.1-KB2999226-x64.cab

NOTA: reemplace "..." con el nombre de carpeta correcto. Después de esto, reinstale el paquete VS C ++ 2015.

Lee Harris
fuente
4

Tuve un problema similar, y para citar a Sherlock Holmes: " cuando has eliminado lo imposible, lo que queda, por improbable que sea, ¿debe ser la verdad? "

Verifiqué si el marco .NET al que me dirigía estaba instalado en el servidor y resultó que no lo estaba. Instalé 4.6.2 .NET Framework y funcionó.

TheDoctor05
fuente
4

Tuve este problema en mi servidor de producción después de que mi proyecto VS se actualizara automáticamente a .NET Core 1.1.2.

Simplemente instalé el tiempo de ejecución del núcleo 1.1.2 .net desde aquí en mi servidor de producción: https://www.microsoft.com/net/download/core#/runtime

Rikard Askelöf
fuente
Me encontré con el mismo problema pero con el net core 2.0.6 recién lanzado. Se corrigió instalando net core SDK 2.0.6 en un servidor de producción
dodbrian
4

SOLUCIONADO Acabo de resolver el mismo problema hoy mientras implementaba en AZURE . Luego intenté lo mismo para IIS local, obtuve el mismo problema. Como soy nuevo en .net CORE, luché unas horas antes de resolverlo.

En nuestra solución, después de publicar en IIS, observé mi archivo web.confile, especialmente debajo de la línea <aspNetCore processPath="bin\IISSupport\VSIISExeLauncher.exe" arguments="-argFile IISExeLauncherArgs.txt" forwardWindowsAuthToken="false" stdoutLogEnabled="false" />

En nuestra carpeta de implementación, el web.config generado se ve así:<aspNetCore processPath="dotnet" arguments=".\Yodlee.dll -argFile IISExeLauncherArgs.txt" forwardWindowsAuthToken="false" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />

Ahora POR FAVOR intente cambiar la configuración anterior en la solución de Visual Studio a<aspNetCore processPath="bin\IISSupport\VSIISExeLauncher.exe" forwardWindowsAuthToken="false" stdoutLogEnabled="false" />

En nuestra nueva carpeta de implementación, el archivo web.config generado se ve así:<aspNetCore processPath="dotnet" arguments=".\Yodlee.dll" forwardWindowsAuthToken="false" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />

Y esto RESUELTO mi problema, espero que ayude.

Agni
fuente
Hola @Agni, esto funcionó para mí, gracias. Pero, cada vez que intento publicar el proyecto nuevamente en Azure, se reconstruye y el web.config cambia automáticamente al original, con la parte que causa el problema: "-argFile IISExeLauncherArgs.txt". ¿Encontraste una solución para eso? (Estoy usando asp.net core 2.0).
Rodrigo Pires
1
en mi caso tuve que cambiarme processPath="dotnet"a processPath="C:\Program Files\dotnet\dotnet.exe". luego funcionó.
vaheeds
3

Tuve el mismo problema cuando actualicé mi máquina de desarrollo a Core 1.0.1, pero olvidé actualizar el servidor.

Alex Dresko
fuente
Para mí, reinstalé el SDK de net core desde aquí: microsoft.com/net/core#windows y luego funcionó.
Jean
1
VS2017 ahora es .NET Core 1.1 de forma predeterminada: todos los servidores remotos deben actualizarse antes de publicar proyectos actualizados en IIS. Puede obtener el mensaje de error más útil (".NET core 1.1 no instalado") pero en ejecucióndotnet .\YOURPROJDLL.dll
Coruscate5
3

Recibí el error HTTP 502.5 mientras intentaba publicar mi API .NET Core 2.0 en AWS EB, y lo resolví agregando el siguiente código al .csproj:

  <PropertyGroup>
    <PublishWithAspNetCoreTargetManifest>false</PublishWithAspNetCoreTargetManifest>
  </PropertyGroup>
Matheus Lacerda
fuente
2

Tuve el mismo problema. Cambié la identidad del grupo de aplicaciones a la cuenta de servicio de red. Luego establecí explícitamente la ruta a dotnet.exe en web.config para que la aplicación funcione correctamente como dijo @danielyewright en su github comentario de . Funciona después de establecer el camino.

Gracias

vik
fuente
2

Compartiendo que en mi caso, este error se debió a que olvidé actualizar project.json con:

"buildOptions": {
    "emitEntryPoint": true
  }
vinjenzo
fuente
2

Tuve el mismo error en cuestión, con los mismos problemas descritos por VSG24 en Respuesta propuesta: mensaje de error desagradable al escribir 'dotnet' en CMD:

El programa no puede iniciarse porque falta api-ms-win-crt-runtime-l1-1-0.dll

Resolví esto instalando manualmente las siguientes 2 actualizaciones en Windows Server 2012 R2 (y los requisitos previos y todas las demás actualizaciones vinculadas; lea atentamente las instrucciones de instalación en el sitio web de Microsoft):

  1. KB2919355
  2. KB2999226

Espero que esto ayude a alguien.

Johan Foley
fuente
2

Enfrenté el mismo problema cuando intenté publicar la versión de depuración de mi aplicación web. Este conjunto de archivos no contenía el archivo web.configcon el valor adecuado de atributo processPath.

Tomé este archivo de la versión de lanzamiento, se asignó un valor a la ruta a mi archivo exe.

<aspNetCore processPath=".\My.Web.App.exe" ... />
Barabas
fuente
2

En mi caso, hubo un problema con la versión Net Core instalada en el servidor. Acabo de instalar la misma versión que en mi máquina de desarrollo y todo está bien :-)

Pescado salado
fuente
2

Necesitaba instalar la última versión de .net Core que se encuentra aquí . No es necesario reiniciar el sitio o el servidor

Daniel Dirty Nativo Martin
fuente
2

Lo resolví agregando "permiso de edición" a la aplicación del sitio, lo asigné al directorio físico y luego seleccioné el usuario de Windows que podría tener acceso a esta carpeta raíz. (red privada).

Antonin GAVREL
fuente
2

En mi caso, después de instalar AspNetCore.2.0.6.RuntimePackageStore_x64.exey DotNetCore.2.0.6-WindowsHosting.exe, necesito reiniciar el servidor para que funcione sin 502 puerta de enlace incorrecta y error de proxy.

ACTUALIZAR:

Hay una manera de usarlo sin reiniciar: https://stackoverflow.com/a/50808634/3634867

John_J
fuente
2

Abra el símbolo del sistema con credenciales de administrador

Escriba el siguiente comando y presione enter

> IISRESET

O

Abra Visual Studio 2017 con credenciales de administrador

Escriba el siguiente comando en la Consola del Administrador de paquetes y presione enter

PM > IISRESET

PM> IISRESET
Attempting stop...
Internet services successfully stopped
Attempting start...
Internet services successfully restarted
Akshay Mishra
fuente
2

Para mí, fue causado por tener diferentes versiones de .Net Core instaladas. Coincidí con mi servidor de desarrollo y producción y funcionó.

Carla
fuente
1

También tuve este problema (el error se produjo tanto en VS 15 como en 17). Sin embargo, en VS15 devolvió un CONNECTION_REFUSEDerror y en VS17 volvió ASP.NET Core 1.0 on IIS error 502.5.

REPARAR

  1. Navegue al directorio de su proyecto y ubique la carpeta oculta .vs(se encuentra en el directorio de la carpeta de proyectos). (Recuerde mostrar archivos / carpetas ocultos)

  2. Cerrar VS

  3. Eliminar carpeta .vs
  4. Inicie VS como administrador (la carpeta .vs será recreada por VS)
Unicco
fuente
1

Esto es lo que pensé, y esto sucedió recientemente en Windows 10 después de que se instaló una actualización. Por lo que reuní, se instaló una actualización de Windows Defender que asumía que mi "Project.dll" (un proyecto principal de asp.net) se comportaba como un virus, por lo que se eliminó.

Entonces, una de las primeras cosas que le sugiero que haga antes de comenzar a instalar / desinstalar cosas es verificar para confirmar que su "Project.dll" está donde debería estar.

Cópielo de nuevo en la ubicación si ya no está allí.

Si tiene dificultades para volver a copiar el archivo, agregue una exclusión a la carpeta de su proyecto en Windows Defender . ( Aprenda cómo hacer eso aquí ).

Esto funcionó para mí instantáneamente y lo repetí en múltiples servidores de aplicaciones.

Seun S. Lawal
fuente
1

Para mí fue que connectionString en Startup.cs era nulo en:

services.AddDbContext<ApplicationDbContext>(options => options.UseSqlServer(Configuration.GetConnectionString("DefaultConnection")));

y fue nulo porque la aplicación no estaba buscando en appsettings.json la cadena de conexión.

Tuve que cambiar Program.cs a:

public static void Main(string[] args)
{
    BuildWebHost(args).Run();
}

public static IWebHost BuildWebHost(string[] args) =>
     WebHost.CreateDefaultBuilder(args)
     .ConfigureAppConfiguration((context, builder) => builder.SetBasePath(context.HostingEnvironment.ContentRootPath)
     .AddJsonFile("appsettings.json").Build())
     .UseStartup<Startup>().Build();
Andrei Dobrin
fuente
1

No tengo idea de por qué esto funcionó para mí, pero estoy usando la autenticación de Windows y tenía este código en mi BuildWebHosten Program.cs:

.UseStartup<Startup>()
.UseHttpSys(options =>
{
    options.Authentication.Schemes =
        AuthenticationSchemes.NTLM | AuthenticationSchemes.Negotiate;
    options.Authentication.AllowAnonymous = false;
})
.Build();

Después de eliminar el .UserHttpSysbit, ahora funciona y todavía puedo autenticarme como usuario de dominio.

BuildWebHost ahora parece

public static IWebHost BuildWebHost(string[] args) =>
    WebHost.CreateDefaultBuilder(args)
    .UseStartup<Startup>()
    .Build();
Bassie
fuente
Tengo autenticación de cookies en aspnet core. ¿Cómo configuro?
kudlatiger
@kudlatiger Lo siento, no estoy seguro, su mejor opción es crear una pregunta separada
Bassie
1

Recibí el mismo error y descubrí que el problema era que durante la publicación en Azure, mi archivo web.config se modificó, por lo que la siguiente línea terminó así:

<aspNetCore processPath="bin\IISSupport\VSIISExeLauncher.exe" arguments="-argFile IISExeLauncherArgs.txt" forwardWindowsAuthToken="false" stdoutLogEnabled="false" startupTimeLimit="3600" requestTimeout="23:00:00" />

El problema para Producción son los contenidos de los argumentos: "-argFile IISExeLauncherArgs.txt"

Parece que este problema se abordará en el próximo SDK de .NET Core (actualmente en versión preliminar), pero por ahora, la solución es agregar este bloque al archivo .csproj:

<Target Name="bug_242_workaround" AfterTargets="_TransformWebConfig">
    <Exec Command="powershell &quot;(Get-Content '$(PublishDir)Web.config').replace(' -argFile IISExeLauncherArgs.txt', '') | Set-Content '$(PublishDir)Web.config'&quot;" />
  </Target>

Esto modificará web.config y eliminará la parte problemática para su publicación.

Referencia: https://github.com/aspnet/websdk/issues/242

Espero eso ayude.

Rodrigo Pires
fuente
Tanto los atributos startupTimeLimit como requestTimeout que se agregan parecen ser un error de herramientas .
Mark G
1

Me funcionó después de cambiar la configuración de publicación.

ingrese la descripción de la imagen aquí

MAFAIZ
fuente
Lo siento, no puedo ver imágenes en mi organización. La descarga de imágenes está bloqueada (en la mayoría de las organizaciones).
Auguste
0

Tuve un problema similar (Asp.Net Core 2.x) que fue causado al intentar ejecutar una aplicación principal asp.net de 32 bits en IIS en un servidor de Windows de 64 bits. La causa principal fue que el web.config que se genera automáticamente (si su proyecto no incluye explícitamente uno, que los proyectos principales de asp.net no lo hacen de forma predeterminada) no contiene la ruta completa al ejecutable dotnet. Cuando instale el paquete de alojamiento en una máquina de 64 bits, se instalarán las versiones de 64 y 32 bits de dotnet, pero la ruta se resolverá de forma predeterminada en 64 bits y su aplicación principal asp.net de 32 bits no se cargará. En su navegador puede ver un error 502.5 y si mira el registro de eventos del servidor puede ver el código de error 0x80004005. Si intenta ejecutar dotnet.exe desde un símbolo del sistema para cargar la dll de la aplicación principal de asp.net en ese servidor, es posible que vea un error como "BadImageFormatException" o "

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <location path="." inheritInChildApplications="false">
        <system.webServer>
            <handlers>
                <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
            </handlers>
            <aspNetCore processPath="C:\Program Files (x86)\dotnet\dotnet.exe" arguments=".\My32BitAspNetCoreApp.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />
       </system.webServer>
   </location>
</configuration>
Nathan
fuente
0

Tuve el mismo problema y la razón en mi caso fue que el núcleo de EF estaba tratando de leer la cadena de conexión del appsettings.development.jsonarchivo. Lo abrí y encontré que la cadena de conexión estaba comentada.

//{
//  "ConnectionStrings": {
//    "DefaultConnection": "Server=vaio;Database=Goldentaurus;Trusted_Connection=True;",
//    "IdentityConnection": "Server=vaio;Database=GTIdentity;Trusted_Connection=True;"
//  }
//}

Luego los eliminé como a continuación y el problema se resolvió:

{
  "ConnectionStrings": {
    "DefaultConnection": "Server=vaio;Database=Goldentaurus;Trusted_Connection=True;",
    "IdentityConnection": "Server=vaio;Database=GTIdentity;Trusted_Connection=True;"
  }
}
yogui
fuente