public bool TryGetCustomerId(out Guid customerId) { customerId = Guid.Empty; if (_contextAccessor.HttpContext?.Request.Headers.TryGetValue(CustomKnownHeaders.CustomerId, out var values) ?? false) { return Guid.TryParse(values.FirstOrDefault(), out customerId); } return false; }Después de migrar de .NET Core 3.1 a .NET 5, aparece el error "Uso de variable local no asignada" para la variable de parámetro de salida.
El error se muestra en la variable "valores". Error: "Uso de 'valores' de variables locales sin asignar"
Después de migrar de .Net core 3.1 a .Net 5, aparece el error "Uso de variable local no asignada"
Probé algo similar en netcore3.1 y obtuve el mismo error.
¿Está realmente seguro de que el código funciona en netcore3.1?
Parece que este es uno de esos casos en los que el compilador simplemente no puede decir que la variable se ha asignado definitivamente; consulte "acceso condicional fusionado con una constante booleana" aquí . Es posible que deba volver a escribir su código para ayudarlo:
public bool TryGetCustomerId(out Guid customerId) { customerId = Guid.Empty; string[] values = null; if (_contextAccessor.HttpContext?.Request.Headers.TryGetValue(CustomKnownHeaders.CustomerId, out values) ?? false) { return Guid.TryParse(values.FirstOrDefault(), out customerId); } return false; }Esto parece ser un error o al menos una limitación en el compilador. Aparentemente no se da cuenta de que la línea:
return Guid.TryParse(values.FirstOrDefault(), out customerId); nunca se ejecutará a menos que _contextAccessor.HttpContext no sea null , se llame a TryGetValue y se asigne un valor a los values .
Notablemente cambiando ?? false a == true (que es como suelo manejar este escenario exacto) no hace la diferencia. Aparentemente, el hecho de que no se llame a TryGetValue es suficiente para que el compilador trate cualquier uso posterior de values como potencialmente sin asignar, aunque los values NO PUEDEN desasignarse en la única rama en la que se está utilizando.
Es difícil ver esto como algo más que un error en el compilador que probablemente debería informarse en https://github.com/dotnet/roslyn .
Editar Esto no parece ser un problema en Visual Studio 2022 (incluso en proyectos .NET5), por lo que parece que MS reconoció el error y lo solucionó. Solo lo veo al abrir y compilar el proyecto usando 2019.