@puckpuck can we revert the PR #105 in order to have a running sample again?

My current workaround for this is to add the following to the cartservice environment stanza in docker-compose.yml:

- ASPNETCORE_URLS=http://*:${CART_SERVICE_PORT}

This gets me past the frontend service failing to connect to cartservice and to a new error, a 500 from cartservice itself:

The request matched multiple endpoints. Matches: 

gRPC - Unimplemented service
gRPC - Unimplemented service

@puckpuck can we revert the PR #105 in order to have a running sample again?

I'm going to investigate this deeper to try and figure out what in the PR broke it. I'll know more by tomorrow.

@puckpuck can we revert the PR #105 in order to have a running sample again?

I'm going to investigate this deeper to try and figure out what in the PR broke it. I'll know more by tomorrow.

Ya I'd like to know why as well. I wanted to remove the generate files, which ./services/CartService.cs is one of, but obviously would prefer the example still works :D

Ya I'd like to know why as well. I wanted to remove the generate files, which ./services/CartService.cs is one of, but obviously would prefer the example still works :D

Though the logic doesn't seem like much, I don't believe that file is generated. It acts as a thin wrapper around calling into the CartStore itself.

Ya I'd like to know why as well. I wanted to remove the generate files, which ./services/CartService.cs is one of, but obviously would prefer the example still works :D

Though the logic doesn't seem like much, I don't believe that file is generated. It acts as a thin wrapper around calling into the CartStore itself.

Ah that does seem plausible. I wonder if this wrapper pattern is typically used in C# protobuf projects..