Stop using magic strings in your Firestore .NET queries

If you use Firestore with .NET, you've probably written code like this: query . WhereEqualTo ( "Location.home_country" , "Portugal" ); That "Location.home_country" is a string. Nobody checks it at compile time. If you typo it, rename a property, or forget that your C# property Country maps to home_country in Firestore, you won't know until runtime. I kept running into this in my own projects, so I wrote a typed wrapper around Google's official Firestore client that uses lambda expressions instead of strings. What it looks like // Before — string-based, no compile-time checking query . WhereEqualTo ( "Locaiton.home_country" , "Portugal" ); // typo, compiles fine // After — lambda-based, compiler catches errors query . WhereEqualTo ( u => u . Locaiton . Country , "Portugal" ); // CS1061: 'User' does not contain a definition for 'Locaiton' The library reads [FirestoreProperty] attributes automatically, so you always use the C# property name and it resolves the Firestore storage name for y