El paso a paso o código que hallarás en este artículo es la resolución más rápida y efectiva que hallamos a esta inquietud o problema.
Solución:
Algunos de los proyectos utilizan el PackageReference formato pero el .sfproj proyecto utiliza el packages.config expediente.
Todavía no entiendo por qué la compilación comenzó a fallar, pero pude encontrar una solución. Dado que PackageReference aún no es compatible con los proyectos de Service Fabric, mi solución alternativa fue usar ambas cosas restaurar las tareas de la siguiente manera:
El comentario de Trevor el 20/2 me dio la pista. Es probable que no tenga el conjunto completo de proyectos a los que hace referencia la solución. (ProjectReferences puede ir a otros proyectos, que no están en la solución).
He aquí por qué funcionó esta loca solución (ejecutar las tareas de restauración dotnet.exe y nuget.exe):
dotnet restore recorrerá las referencias del proyecto de forma predeterminada para garantizar que también se restauren.
--no-dependencies interruptor puede apagar eso.
La restauración de nuget.exe tiene el valor predeterminado opuesto, porque no queríamos interrumpir a los usuarios antiguos.
-recursive puede encender esto.
La solución correcta es hacer que su solución contenga todos los proyectos.
-Rob Relyea NuGet Client Team, Gerente de Ingeniería
Mi problema resultó ser una solución que no incluía todos los proyectos necesarios.
Tengo un archivo de solución maestra que incluye todos mis proyectos y varios archivos de solución más pequeños con solo algunos de los proyectos. La solución maestra se desarrolló bien en Azure DevOps, pero la solución parcial falló.
Me di cuenta de que el archivo project.assets.json que faltaba pertenecía a un proyecto que debía incluirse en esta solución fallida.
Recuerda dar difusión a este enunciado si te ayudó.