Después de tanto batallar ya hallamos el arreglo de este atolladero que muchos de nuestros usuarios de este sitio han tenido. Si tienes algún detalle que aportar no dudes en compartir tu información.
Solución:
El ejemplo que estaba citando usa LINQ to Objects, donde las expresiones lambda implícitas en la consulta se convierten en delegados… mientras que estás usando EF o similar, con IQueryable consultas, donde las expresiones lambda se convierten en árboles de expresión. Los árboles de expresión no admiten el null operador condicional (o tuplas).
Solo hazlo a la antigua:
price = co == null ? 0 : (co.price ?? 0)
(creo que el null-El operador de fusión está bien en un árbol de expresión.)
El código al que se vincula utiliza List. List implementos IEnumerable pero no IQueryable. En ese caso, la proyección se ejecuta en memoria y ?. obras.
estas usando algo IQueryable, que funciona de manera muy diferente. Para IQueryable, se crea una representación de la proyección y su proveedor LINQ decide qué hacer con ella en tiempo de ejecución. Por razones de compatibilidad con versiones anteriores, ?. no se puede utilizar aquí.
Según su proveedor de LINQ, es posible que pueda usar . y aun no te sale nada NullReferenceException.
Eres capaz de sustentar nuestra labor fijando un comentario y dejando una puntuación te lo agradecemos.