Skip to content

Build fails for multi-target MAUI ClientApp due to inconsistent gRPC codegen for basket.proto — propose adding a shared GrpcClients project to centralize generated client types #919

@github4mathews

Description

@github4mathews

Environment

  • Repository: eShop reference app (local workspace)
  • .NET SDK: .NET 10
  • Project: ClientApp (multi-target MAUI project)
  • Target frameworks:
    • net10.0
    • net10.0-android
    • net10.0-ios
    • net10.0-maccatalyst
    • net10.0-windows10.0.19041.0

Relevant Files

  • src/ClientApp/ClientApp.csproj
    • Contains <Protobuf Include="..\Basket.API\Proto\basket.proto" GrpcServices="Client" />
  • src/Basket.API/Proto/basket.proto
  • src/ClientApp/Services/Basket/BasketService.cs
    • References global::eShop.Basket.API.Grpc.Basket.BasketClient

Symptoms / Observed Behavior

  • Build fails for certain TFMs with errors such as:

    CS0234: The type or namespace name 'Basket' does not exist in the namespace 'eShop' (are you missing an assembly reference?)

  • Failures occur during XAML precompile/build for TFMs like net10.0-windows10.0.19041.0.

  • Generated gRPC files (BasketGrpc.cs, Basket.cs) are missing under src/ClientApp/obj/Debug/<TFM>/... for failing targets.

  • Attempts to add fallback C# proto stubs caused duplicate-type/partial conflicts when generated files did exist (errors: CS0260, CS0102, CS0111).

  • Diagnostic logs confirm XAML precompile fails because eShop.Basket.API.Grpc types are not available at that stage.

Root Cause

  • In a multi-targeted MAUI project, <Protobuf> items and Grpc.Tools code generation run inconsistently across TFMs.
  • Relying on per-TFM codegen inside the MAUI project leads to missing generated code for certain targets.
  • This causes compile-time failures when XAML precompilation or cross-TFM builds expect consistent gRPC client types. Relevant Files
  • src/ClientApp/ClientApp.csproj
    • Contains <Protobuf Include="..\Basket.API\Proto\basket.proto" GrpcServices="Client" />
  • src/Basket.API/Proto/basket.proto
  • src/ClientApp/Services/Basket/BasketService.cs
    • References global::eShop.Basket.API.Grpc.Basket.BasketClient

Symptoms / Observed Behavior

  • Build fails for certain TFMs with errors such as:
    CS0234: The type or namespace name 'Basket' does not exist in the namespace 'eShop' (are you missing an assembly reference?)
    • Failures occur during XAML precompile/build for TFMs like net10.0-windows10.0.19041.0.
  • Generated gRPC files (BasketGrpc.cs, Basket.cs) are missing under src/ClientApp/obj/Debug/<TFM>/... for failing targets.
  • Attempts to add fallback C# proto stubs caused duplicate-type/partial conflicts when generated files did exist (errors: CS0260, CS0102, CS0111).
  • Diagnostic logs confirm XAML precompile fails because eShop.Basket.API.Grpc types are not available at that stage.

Inspection & Temporary Workaround

  • I inspected the build errors and the BasketService.cs file.
  • The client project expects generated gRPC types from basket.proto (namespace eShop.Basket.API.Grpc), but the generated files are not present for the net10.0-windows... target during this build, causing the CS0234 errors.
  • I added a small fallback file to the client project at:
    src/ClientApp/Services/Basket/Protos/BasketGrpcFallback.cs
  • This defines minimal types and a Basket.BasketClient implementation matching the proto contract used by the client.
  • The fallback provides:
    • GetBasketRequest, UpdateBasketRequest, DeleteBasketRequest, DeleteBasketResponse, BasketItem, CustomerBasketResponse
    • An extension to allow IList<T>.Add(IEnumerable<T>) to support the code pattern used in UpdateBasketAsync
    • A minimal Basket.BasketClient with no-op async methods returning defaults
  • This workaround allows the ClientApp to compile even when the generated gRPC client code isn’t available for a particular target.
  • However, it is not a sustainable solution and introduces risk of type conflicts when generated code is present.

Root Cause

  • In a multi-targeted MAUI project, <Protobuf> items and Grpc.Tools code generation run inconsistently across TFMs.
  • Relying on per-TFM codegen inside the MAUI project leads to missing generated code for certain targets.
  • This causes compile-time failures when XAML precompilation or cross-TFM builds expect consistent gRPC client types.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions