-
Notifications
You must be signed in to change notification settings - Fork 3.3k
Description
Environment
- Repository: eShop reference app (local workspace)
- .NET SDK: .NET 10
- Project: ClientApp (multi-target MAUI project)
- Target frameworks:
net10.0net10.0-androidnet10.0-iosnet10.0-maccatalystnet10.0-windows10.0.19041.0
Relevant Files
src/ClientApp/ClientApp.csproj- Contains
<Protobuf Include="..\Basket.API\Proto\basket.proto" GrpcServices="Client" />
- Contains
src/Basket.API/Proto/basket.protosrc/ClientApp/Services/Basket/BasketService.cs- References
global::eShop.Basket.API.Grpc.Basket.BasketClient
- References
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 undersrc/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.Grpctypes are not available at that stage.
Root Cause
- In a multi-targeted MAUI project,
<Protobuf>items andGrpc.Toolscode 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" />
- Contains
src/Basket.API/Proto/basket.protosrc/ClientApp/Services/Basket/BasketService.cs- References
global::eShop.Basket.API.Grpc.Basket.BasketClient
- References
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.
- Failures occur during XAML precompile/build for TFMs like
- Generated gRPC files (
BasketGrpc.cs,Basket.cs) are missing undersrc/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.Grpctypes are not available at that stage.
Inspection & Temporary Workaround
- I inspected the build errors and the
BasketService.csfile. - The client project expects generated gRPC types from
basket.proto(namespaceeShop.Basket.API.Grpc), but the generated files are not present for thenet10.0-windows...target during this build, causing theCS0234errors. - 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.BasketClientimplementation 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 inUpdateBasketAsync - A minimal
Basket.BasketClientwith 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 andGrpc.Toolscode 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.