# Fody and the case for weaving code at compile time

> Fody is an extensible tool that weaves .NET assemblies by manipulating their IL as part of a build, and this repository is its landing page rather than the engine itself. The interesting part is what the weaver model removes from a developer: the MSBuild and Visual Studio plumbing that would otherwise be written by hand for every build-time transformation.

**Fody/Home** — The landing page for Fody repositories

- Repository: https://github.com/Fody/Home
- Stars: 719 · Forks: 63
- Language: C#
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/fody-home

## This repository is the front door, not the engine

The Home repository is described as the starting point for people to learn about Fody, the project. It is not the codebase you reference in your project.

The readme points to the main Fody code repository for the core engine, at the Fody/Fody repository, and the top level of this tree shows what the landing page actually contains: a `pages/` directory holding the documentation, a `BasicFodyAddin/` directory with a simple project meant to illustrate how to build an add-in, an `images/` folder, a `src/` directory, a `runTests.ps1` script and an `mdsnippets.json` file.

The documentation index is the substance of the repository, and it is a real one. There is a Licensing and Patron FAQ, a Usage page introducing how to use Fody, a Configuration page covering all configuration options, a page on how add-ins are resolved, a list of Fody weavers and add-ins, a page on common errors, a page on in-solution weaving for writing an add-in that manipulates IL within the same solution, a page on the ProcessedByFody marker class added to target assemblies for diagnostic purposes, a page on strong naming, a page on supported runtimes and IDE, and pages on add-in development and add-in packaging. There are also links to a FodyAddinSamples repository containing a working sample of every Fody add-in, and to a Fody Project Configuration Manager tool that provides an interactive way to configure weavers, which the readme notes is especially helpful in solutions with many projects.

So this is the documentation project, and the audience is a developer deciding whether compile time weaving is a reasonable idea and where to start if it is.

## Your first use starts on the usage and configuration pages

There is no install command in this repository to copy, and that is not an omission. The Home repository is documentation, and the pages it carries are where the first use is actually described.

The Usage page is introduced as an introduction to using Fody, and the Configuration page covers all configuration options for Fody. The Addin discovery page explains how add-ins are resolved, which matters because the whole model rests on the build finding the weaver you asked for and nothing else.

The sequence a new user would follow is visible in the structure of the documentation. Learn what a weaver is, read the configuration options, understand how add-ins are discovered, then pick a weaver from the list of Fody weavers and add-ins. The FodyAddinSamples repository, described as containing a working sample of every Fody add-in, is the place to see a transformation applied to real code rather than described.

For a solution with many projects, the readme points to a Fody Project Configuration Manager, an interactive tool that can support configuring weavers, which it describes as especially helpful in solutions with many projects. That is a signal about how the tool is expected to be used: per project configuration is tedious enough by hand that a helper is worth publishing.

Two pages exist for the failure cases, and their existence is a fair signal about the tool's risk profile. There is a page on common errors for when a build goes wrong, and a page on supported runtimes and IDE for whether your toolchain is covered. There is also a page on strong naming, which covers the case where your assembly is signed and the weaving has to re-apply the strong name if necessary.

The one thing this repository does not give you is a command to paste. Everything above is in the pages directory, and the pages are the deliverable here.

## The problem is the plumbing, not the transformation

Fody is described as an extensible tool for weaving .net assemblies, enabling the manipulation of the IL of an assembly as part of a build, which requires a significant amount of plumbing code. That plumbing involves knowledge of both the MSBuild and Visual Studio APIs, and Fody attempts to eliminate it through an extensible add-in model.

This framing is worth dwelling on, because it explains why the project looks the way it does. The transformations themselves are not hard. Turning a simple property into a full INotifyPropertyChanged implementation is a matter of rewriting the getter and adding the event. The hard part is doing that to an assembly after the C# compiler has produced it, inside a build, across every project in a solution, on every machine that builds it, with the correct references, the correct strong name and the correct pdb.

The list of plumbing tasks the readme gives is the entire scope of the problem:

- Injection of the MSBuild task into the build pipeline
- Resolving the location of the assembly and pdb
- Abstracts the complexities of logging to MSBuild
- Reads the assembly and pdb into the Mono.Cecil object model
- Re-applying the strong name if necessary
- Saving the assembly and pdb

That is six items, and each of them is the kind of detail that is easy to get subtly wrong once and then impossible to debug. The engine handles them once, and an add-in author handles only the IL change they care about.

The readme is clear that this technique is very powerful, and it gives four examples of what it means in practice. You can turn simple properties into full INotifyPropertyChanged implementations, add checks for null arguments, add Method Timings, and even make all your string comparisons case insensitive. Each of those maps to a specific add-in in the ecosystem, and the last one, Caseless, is a good illustration of how far the model goes: rewriting the semantics of an operator across an assembly is not something a source generator can easily do, because the comparison is compiled into the IL.

## Three properties that decide whether a weaver fits your build

The readme states three consequences of using Fody, and they are the ones to check before anything else.

No install required to build. The weaver is a build step, not a tool you install on a developer machine and hope everyone has, which removes an entire class of onboarding problem.

Attributes are optional depending on the weavers used. Some weavers work by attribute on the members they should affect, and some work globally on the whole assembly. Whether you end up annotating your code is a property of the specific add-in, not of Fody, and an add-in that requires no attributes at all is what makes the case insensitive string comparison example possible.

No runtime dependencies need to be deployed. This is the most important of the three, and it is the reason the approach is still relevant. The weaving happens at build time, and what ships is ordinary IL that the runtime already understands. There is no extra DLL to reference at run time, no bootstrapper, no proxy assembly.

The mechanism underneath is Mono.Cecil, the object model for reading and writing.NET assemblies, and the add-in based approach to modifying the IL of.net assemblies at compile time. The readme credits Jb Evain for the use of Mono Cecil, and with GitHub credited for project hosting.

One more detail is easy to overlook and useful in practice. The ProcessedByFody class is a marker class added to target assemblies for diagnostic purposes. That means the tool leaves evidence in the output, which is what you want when you are trying to work out why a particular build produced a particular binary.

## A model you extend, not a set of features you enable

The add-in model is the part that distinguishes Fody from a collection of individual tools, and the documentation set reflects that by devoting pages to writing your own.

The Addin development page covers building a new Fody add-in, and the BasicFodyAddin directory in this repository is a simple project meant to illustrate how to build one. The Addin packaging page covers packaging and deployment of Fody weavers, and the in-solution weaving page covers writing an add-in that manipulates IL within the same solution, which is the case where your weaver needs to reference types from the project it is weaving.

The FodyAddinSamples repository contains a working sample of every Fody add-in, and the readme links a list of Fody weavers and add-ins. The four examples in the overview point at that list: PropertyChanged, NullGuard, MethodTimer and Caseless.

This is a meaningful difference in approach from a source generator. A source generator runs in the compiler and produces more C#, so it can only add code, and anything it wants to do to existing code has to be expressed as new code. A weaver operates on the compiled output, which means it can rewrite what the compiler already produced, including changing the semantics of existing operations rather than only adding around them. It also means the weaver is a post-compile step, with a post-compile step's properties: it runs on the whole assembly, it needs the pdb, it has to leave the strong name valid, and it can, in principle, produce output that is hard to trace back to source without source map support.

The cost of the model is the same in both directions. A generator that fails usually fails the build loudly. A weaver that misbehaves can produce an assembly that compiles and runs and is subtly wrong, which is why the documentation includes a page on common errors and a page on the supported runtimes and IDE.

## The project asks for money, and says so plainly

The repository spends more of its space on funding than on code, and that is worth reporting accurately because it is a real part of the adoption decision.

The readme says Fody requires significant effort to maintain, and as such it relies on financial support to ensure its long term viability. It then states that it is expected that all developers using Fody become a Patron on OpenCollective. This is repeated in the documentation and further learning section, with a link to the Licensing and Patron FAQ for more information.

That is unusual phrasing, and it is deliberate. The project is not merely accepting donations, it is stating an expectation, and the FAQ page exists to explain what that means in practice, presumably in terms of what the licence entitles you to and what using the project without contributing entails.

The sponsor tiers are documented: Gold Sponsors, whose large company logo is added with a link to the website, Silver Sponsors, Bronze Sponsors whose company avatar is shown with a link to the OpenCollective Profile, and the general patrons and sponsors list. The listed companies include PostSharp, G-Research, Particular Software, and others.

There is also a donations page, and the readme says every month the Fody project will donate a portion of funding raised to a charity or other cause.

For an adopter, the practical reading is that the code is MIT licensed and in the `license.txt` file at the root of this repository, so using it does not require payment, but the project's funding model is a patronage model rather than a permissive free-for-all model. If your organisation has a policy about contributing to open source dependencies, that conversation should happen before you adopt, not after.

## Where compile time weaving is the wrong tool

There are three situations where a weaver is the wrong answer, and the reasons are structural rather than fixable with configuration.

The first is a build you do not control. A weaver is a post compile step that rewrites your assemblies. If your build produces artefacts that are signed, audited, reproducible bit for bit across machines, or verified against a hash elsewhere in the pipeline, then a tool that changes the output after the compiler runs is a liability rather than a convenience. You have moved the trust boundary from the compiler to the weaver, and the weaver's version becomes part of your build's identity.

The second is a requirement for source level transparency. When something goes wrong in a woven assembly, the stack traces and the decompiled output refer to code that is not in your source tree. The ProcessedByFody marker helps with identification, and the documentation includes a common errors page, but debugging a bug that only appears after weaving is a different discipline from debugging source.

The third is a project that must not add build time. Every weaver is work at every build. On a large solution with many projects, that cost is paid repeatedly, and it is paid before anyone sees a result.

There is also the question of whether the transformation you want is the right kind. If you want to add null checks to public methods, a weaver is ideal. If you want to remove them, or to change the behaviour of a language operator in a way that alters the meaning of existing code, a weaver may be doing exactly what you asked and something you did not intend. The Caseless example, making all string comparisons case insensitive, is the clearest case of a transformation that changes semantics rather than adding safety, and it is a good model for asking the question of your own candidate weaver.

## Conclusion

Fody fits a .NET team that wants compile time behaviour such as property change notification, null argument checks or case insensitive string comparison without writing the MSBuild and assembly manipulation plumbing itself, and that is prepared to add a build step to every project. It is the wrong choice for a codebase that cannot accept a post compile assembly rewrite, for a project that must run on a runtime the weaver does not support, and for a team that wants a library with no build time impact at all. Before adopting, verify three things: which runtime and IDE combination your project uses, since the documentation has a dedicated page for supported runtimes and IDE, how the weaver resolves add-ins in your build, and whether the strong naming behaviour is acceptable, because the weaver re-applies the strong name if necessary. The code here is MIT licensed, the repository publishes no GitHub releases, and the last push was on 2026-10-14.

## FAQ

### What is Fody and what does it do?

Fody is an extensible tool for weaving .net assemblies, enabling the manipulation of the IL of an assembly as part of a build. It uses Mono.Cecil and an add-in based approach, and handles the MSBuild and Visual Studio plumbing that such a transformation would otherwise require.

### Does using Fody add any runtime dependencies?

No. The readme states that no runtime dependencies need to be deployed, and that no install is required to build, because the weaving happens at compile time and the output is ordinary IL the runtime already understands.

### What can a Fody weaver actually change?

Because a weaver rewrites compiled IL rather than generating more source, it can change existing behaviour. The readme gives examples including turning simple properties into full INotifyPropertyChanged implementations, adding checks for null arguments, adding Method Timings, and making all string comparisons case insensitive.

### Where does the Fody Home repository differ from the Fody engine?

The Home repository is the landing page and documentation project, holding the pages on usage, configuration, add-in discovery, common errors, strong naming, supported runtimes and IDE, and add-in development and packaging, plus a BasicFodyAddin sample. The core engine code is in the separate Fody/Fody repository.

### What does Fody require from the people who use it?

The readme says Fody requires significant effort to maintain and relies on financial support for its long term viability, and that it is expected that all developers using Fody become a Patron on OpenCollective. There is a Licensing and Patron FAQ page explaining the details.

## Sources

- [Fody/Home on GitHub](https://github.com/Fody/Home)
- [Issues](https://github.com/Fody/Home/issues)
- [License: MIT](https://github.com/Fody/Home/blob/master/LICENSE)
- [README](https://github.com/Fody/Home/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/fody-home