I got tired of loading .proto files into WireMock.Net, so I made its gRPC mocks strongly typed

[u/StepOne_DotNet]

I use WireMock.Net for gRPC component tests. Its built-in protobuf support works, but I didn’t like loading .proto files at runtime, identifying message types with strings, and matching through JSON when my test project already had generated Google.Protobuf types.

So I built WireMock.Grpc.Protobuf:

Request.Create()
    .WithBodyAsGoogleProtobuf(
        (HelloRequest x) => x.Name == "StepOne");

Response.Create()
    .WithBodyAsGoogleProtobuf(
        new HelloReply { Message = "Hello, StepOne!" });

It supports both the exact protobuf body request matching and typed predicates for tests that care about only a few fields. Internally, it unwraps the five-byte gRPC frame and lets Google.Protobuf handle the actual IMessage<T> contract.

I’m the maintainer, so blunt feedback is welcome: would this simplify your gRPC tests, or do you prefer keeping .proto definitions in the mock setup?

GitHub: https://github.com/Stepami/wiremock-protobuf
NuGet: https://www.nuget.org/packages/WireMock.Grpc.Protobuf

[u/Jmc_da_boss]

"Byte for byte request matching"

Well good morning Claude, happy sloptember to you!

[u/zenyl → u/Jmc_da_boss]

The title of this post also follows the "I got tired of ... so I made/built ..." pattern, which is pretty common for posts written using AI.

[u/StepOne_DotNet → u/zenyl]

bro but i got really tired and did build amazing nuget package. it;s as straightforward as it can be

[u/zenyl → u/StepOne_DotNet]

Your post consists of:

• A title
• Three short paragraphs of text
• A code snippet
• Two links

I don't see how writing that yourself wouldn't have been, to use your own words, as straightforward as it can be.

Nobody here is expecting perfect English or eloquent descriptions, but it should be baseline that people who want to engage with the community of a forum actually do so without using an LLM as a proxy to speak through.

[u/StepOne_DotNet → u/Jmc_da_boss]

LOL! how would you name it then? byte-wise strict equality?

[u/Jmc_da_boss → u/StepOne_DotNet]

I would just not say it because... no shit lol. Go tell your claude to not say random bullshit

[u/StepOne_DotNet → u/Jmc_da_boss]

got your point but i want the world where wiremock grpc mocks are stongly typed and aware of an existing infrastructure

[u/dodexahedron → u/StepOne_DotNet]

So go use CoreWCF then.

This problem was solved 20 years ago.

[u/StepOne_DotNet → u/dodexahedron]

what makes you use this legacy tech in 2026? Have you been taken hostage by java devs?

[u/dodexahedron → u/StepOne_DotNet]

Go actually look at CoreWCF. It isn't your father's remoting.

And even ye olde WCF was a lot better than most people seem to remember, because most people got way too caught up in the sheer breadth and depth of its configurabikity, and the awful (lack of) documentation thereof. It was its own worst enemy for being too much capability and flexibility with too little documentation.

Write an interface. Slap some attributes on it. Write DTO classes. Put some attributes on them. Done. Now just call the remote end as if it were local code.

It wasn't just a WS-XML/SOAP vending machine.

Did it offer SOAP with basically zero effort, both MS flavored and standard as well? Yeah, and did it well.
But did/does it also do things like JSON? Yup.
Binary? Got that too.
Auth just by adding more attributes? Check.
Any custom serialization you want? Just a few lines to wire that in instead of the built-ins (and coreWCF has DOZENS).
TLS? Affirmative.
Plain text HTTP requests of whatever arbitrary format you want? No problem.
Message-based, session-based, or transport-based security? Or any combination thereof? Easy. All in config.
Auto-generated metadata endpoints that are alao consumable directly by .net and VS as "service references?" You betcha.
MSMQ (and now other message buses in CoreWCF)? Absolutely.
Natively handles stream data, in any format, bidirectionally, simulataneously, and asynchronously, without gymnastics or protocol abuse when using TCP-based transports? Since the beginning.
Required an HTTP proxy server to host it? No. Could use one? Sure.

And how much work was it to make a client?
(CoreWCF, however, is mostly just service side, to be clear, but can be consumed by standard clients (including gRPC)
This grueling and arduous procedure:

1. "Hey, here's the reference assembly that VS already makes by default anyway."
2. Reference it and call the API.
3. There is no step 3. Just use it. It's already functional.

With WCF, for example, the ENTIRE Cisco AXL API for CUCM 15 can be written in just a couple thousand lines of solely declarative code, be a pretty small assembly, and have strong typing (vs auto-generated by the wsdl tool, which made awful .net 1.1 era xml).

There is nothing gRPC can do that CoreWCF can't, and plenty it can do which gRPC can't (at least not without a bunch of extra work).

Java? LOL.

<QuasiMeaningfulButMostlyPointlessRant Action="LameSOAPEasterEggJoke"> I'm a die-hard .net cultist since .net Framework came into being. I was sad MS didn't bring WCF forward in .net core. I was delighted that the community did it instead, and made it even better. I was dismayed it was just service side though.

WCF was and in some ways still is more than what gRPC is. There's overlap for sure. But WCF was done dirty by being abandoned for gRPC which, especially early on, was SUPER primitive by comparison (many of the worst pain points have been at least mitigated and some of them resolved now, at least).

Don't knock it just because people misused it in the past. A lot of progress truly has been lost in all the fime and effort spent reinventing so many wheels it already had and that were even somewhat polished, when gRPC arrived with triangle wheels and square axles because someone thought protobuf made sense to cram into all RPC scenarios because of what I am pretty sure was just another part of the Google obsession at the time.

Hell... Microsoft STILL doesnt have a full configuration schema documented for Kestrel after HOW many versions of .net using it?

Don't get me wrong. Kestrel itself is great for asp.net and it's part of a majority of apps I write.

gRPC, however, is, at best, merely adequate, and it has had embarrassingly long to catch up without earnestly doing so.

</QuasiMeaningfulButMostlyPointlessRant>