# Obfuscating an Entity Framework Core app without breaking your data layer Entity Framework Core is a mapping layer, and the thing it maps *from*, by default, is your names. Call a class `Invoice` with a property `Status` and — with no configuration at all — EF decides there is a table `Invoices` with a column `Status`, because convention derives the schema from the CLR identifiers. That convention is wonderful for productivity and a landmine for obfuscation. The moment [Nebula.NET](https://delta1labs.com/products/nebula) renames `Invoice` to `a` and `Status` to `b`, the convention faithfully concludes your database has a table `a` with a column `b`, and nothing matches reality anymore. The usual reaction is to exclude the whole data layer from obfuscation. That works and it is a bad trade: your entities and your `DbContext` are often the clearest description of your domain you ship, and you have just left them in plaintext to protect a database schema that was never the sensitive part. There is a precise fix instead. Find every place EF reads a CLR name at runtime, make the schema *explicit* so it stops deriving from those names, and then let Nebula rename the members. This post is that inventory and those patterns. ## Where EF actually reads a name Renaming is safe exactly where EF does not depend on the original identifier at runtime, and unsafe where it does. There are four places it does: 1. **Convention-based table and column names.** With no explicit mapping, the table name is the `DbSet` property name (or the type name) and each column is the property name. Rename the member and the derived schema name moves with it. 2. **String-based member access.** `EF.Property("Status")`, `entry.Property("Status")`, and shadow-property lookups resolve a member *by string*. A string does not participate in renaming, so after obfuscation it names a member that no longer exists and throws. 3. **Migrations.** A generated migration and the model snapshot contain the schema names as string literals. If those were produced from convention, they encode the *original* names; after a rename the running model derives *different* names and the two disagree. 4. **Anything reflecting over your model by name** — a few serializers, auditing shims, or a provider feature that keys off navigation-property names. LINQ, notably, is *not* on this list. `Where(i => i.Status == open)` compiles to an expression tree holding a `MemberInfo`, not the string `"Status"`. When Nebula renames the property, that `MemberInfo` points at the renamed member, and EF translates it through your mapping. Consistent renaming — which Nebula guarantees across the whole assembly — keeps every compiled query intact. The breakage is always about *names resolved from strings*, never about typed member access.

## Pin the schema, then obfuscate freely The entire strategy is one idea: *decouple the schema name from the CLR name*. Once every table, column, key and index name is a string literal in your configuration, the CLR identifiers carry no schema meaning, and Nebula can rename them to `a.b` with no effect on the database. ```csharp protected override void OnModelCreating(ModelBuilder model) { model.Entity(e => { e.ToTable("Invoices"); // table name is now a literal e.HasKey(x => x.Id); e.Property(x => x.Id).HasColumnName("Id"); e.Property(x => x.Status).HasColumnName("Status"); e.Property(x => x.Total).HasColumnName("Total").HasPrecision(18, 2); e.HasIndex(x => x.Status).HasDatabaseName("IX_Invoices_Status"); // Navigation + FK column, pinned the same way. e.HasMany(x => x.Lines) .WithOne(l => l.Invoice) .HasForeignKey(l => l.InvoiceId) .HasConstraintName("FK_InvoiceLines_Invoices"); }); } ``` Those string literals — `"Invoices"`, `"Status"`, `"IX_Invoices_Status"` — are exactly the kind of thing Nebula's string encryption protects in the output, but they are never *renamed*, because they are data, not identifiers. The `x => x.Status` lambdas are typed member access, so they ride the rename automatically. The net result: `Invoice.Status` can become `a.b` in the shipped binary while the SQL EF emits still reads and writes the `Status` column. Data annotations achieve the same decoupling if you prefer them on the type: ```csharp [Table("Invoices")] public class Invoice { [Column("Id")] public int Id { get; set; } [Column("Status")] public InvoiceStatus Status { get; set; } [Column("Total")] public decimal Total { get; set; } } ``` Either way, the obfuscation rule in `nebula.json` is simply that your data layer is *not* special — it obfuscates with everything else: ```json { "preservePublicApi": true, "encryptStrings": true, "controlFlowObfuscation": true, "renaming": { "rules": [ { "pattern": "MyApp.Data.*", "action": "rename" } ] } } ``` No blanket exclusion for `MyApp.Data.*`. The entities get renamed; the schema is pinned in configuration; the two no longer touch. ## Kill the string-based access The patterns that genuinely break are the ones that resolve a member from a string, because a string never follows a rename. Find them and move to the typed form. ```csharp // ✗ Breaks: "Status" names a CLR member that obfuscation renamed to "b". var q1 = db.Invoices.Where(i => EF.Property(i, "Status") == open); // ✓ Typed member access — compiles to a MemberInfo that follows the rename. var q2 = db.Invoices.Where(i => i.Status == open); ``` Shadow properties are the one case where a string is legitimate — the member does not exist on the CLR type at all — so there is nothing to rename and nothing to break. Declare them explicitly and access them by their *schema* name, which you control: ```csharp model.Entity().Property("LastModifiedUtc"); // shadow, no CLR member // ... var ts = db.Entry(invoice).Property("LastModifiedUtc").CurrentValue; // safe: not a CLR name ``` Raw SQL is the other place to audit. A raw query must name the *column* (`Status`), never the CLR property — and since you pinned the column name to a literal, those line up permanently regardless of obfuscation: ```csharp // Names the column, which is fixed — safe under any rename. var rows = db.Invoices.FromSqlInterpolated( $"SELECT * FROM Invoices WHERE Status = {(int)open}"); ``` ## Migrations: generate against the mapped model Migrations encode schema names as literals, so they are safe *if those literals are your pinned names*. They become a hazard only when the snapshot was generated from convention and therefore captured CLR-derived names that later move. Two rules keep migrations clean: - **Generate migrations from the non-obfuscated build.** The design-time tooling reflects over your model to produce the migration and the snapshot; run it against the normal `Debug` assembly, never the obfuscated artifact. The migration you commit then contains your explicit schema literals. - **Never put `nameof(SomeProperty)` in a hand-edited migration.** `nameof` captures the CLR name at compile time, so after a rename it emits `"b"` where you meant the column `"Status"`. Write the column name as a literal. ```csharp // In a migration — literal column names, matching your explicit mapping. migrationBuilder.CreateIndex( name: "IX_Invoices_Status", table: "Invoices", column: "Status"); // literal, not nameof(Invoice.Status) ``` Because the obfuscated binary and the migration both speak in the same fixed schema vocabulary, `context.Database.Migrate()` at startup behaves identically whether or not the assembly was obfuscated. ## The rare surgical exclusion Occasionally a specific feature still reflects over a CLR name at runtime — an auditing component that records the navigation-property name, or a provider extension that keys off it. When that happens, preserve *that member*, not the assembly. Nebula lets you opt a single member out with an attribute, which keeps the exclusion visible in the source where the dependency lives: ```csharp public class Invoice { // A downstream component reflects over this navigation's name at runtime. [Obfuscation(Feature = "renaming", Exclude = true)] public List Lines { get; set; } = new(); } ``` That is the whole escape hatch — one property, documented by its own attribute — instead of a wildcard that spares your entire domain model. The discipline is worth it: the point of obfuscating a data-driven app is that the valuable logic is *in* the entities and the query layer, and a blanket exclusion protects none of it. ## Putting it together EF Core breaks under obfuscation only where it resolves a name from a string at runtime, and every one of those places has a decoupled alternative. Pin tables, columns, keys and indexes with explicit mapping so the schema stops deriving from CLR identifiers; replace `EF.Property` and `nameof`-in-migrations with typed or literal forms; generate migrations from the clean build. Do that and your `MyApp.Data.*` types obfuscate right alongside the rest of the app — renamed, string-encrypted, control-flow-hardened — while the database sees exactly the schema it always has. You protect the domain model that was worth protecting, and you give up nothing to the mapping layer.