# Fody: IL weaving for .NET builds without the MSBuild plumbing

> Fody is an extensible engine that rewrites .NET assembly IL during the build through add-ins called weavers. This is a look at the core engine, how it hooks into MSBuild, and where it stops being the right tool.

**Fody/Fody** — Extensible tool for weaving .net assemblies

- Repository: https://github.com/Fody/Fody
- Stars: 4,546 · Forks: 462
- Language: C#
- License: NOASSERTION
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/fody-fody

## The plumbing Fody removes from .NET builds

Rewriting the IL of an assembly as part of a build is not hard in principle. It is tedious in practice, because doing it from inside a normal .NET project means writing code against both the MSBuild API and the Visual Studio API, then keeping that code working across IDE and SDK versions. Fody exists to absorb that layer. The README states the problem plainly: manipulating the IL of an assembly as part of a build requires a significant amount of plumbing code, and Fody "attempts to eliminate that plumbing code through an extensible add-in model."

The audience is narrower than the repository name suggests. This repository is the core Fody engine, and the README points readers elsewhere for the wider project. People who consume Fody usually never touch this code: they add a weaver package to a project and let the build do the rest. The people who do touch it are add-in authors, the ones writing the weaver that performs the actual transformation. If neither of those describes you, Fody is probably an indirect dependency of something else in your stack.

## How the engine, weavers and MSBuild fit together

The repository layout reflects a layered design rather than a single program. Alongside the Fody/ directory sit FodyTasks/, FodyCommon/, FodyHelpers/, FodyIsolated/ and FodyPackaging/. The names map onto distinct responsibilities: build tasks that MSBuild invokes, shared code used across the engine, helper APIs exposed to weaver authors, an isolated execution path, and packaging support for producing weaver packages.

A weaver is an add-in, and the README links to a dedicated page on addin discovery, which describes how addins are resolved during a build. That is the join point: MSBuild runs the Fody task, the task locates the configured weavers, and each weaver receives the assembly and rewrites its IL. The README also documents a ProcessedByFody class added to target assemblies "for diagnostic purposes," which gives you a way to confirm after the fact that weaving ran on a given assembly. The repository also carries a cecil submodule, which is consistent with the engine operating on IL through Cecil.

One detail worth noticing is that the engine supports in-solution weaving, documented separately, for add-ins that manipulate IL within the same solution. That is a different development loop from the usual consume-a-published-weaver path, and the documentation treats it as its own topic.

## Installing Fody and running a first weave

The README does not inline installation steps. It points to the Fody/Home repository, where the Usage page introduces using Fody, the Configuration page lists all configuration options, and the Addin discovery page explains how addins are resolved. Fody is published as the NuGet package Fody, and the README links a FodyAddinSamples repository that contains a working sample of every Fody addin. Follow those pages rather than guessing at a setup, because the engine alone does not transform anything: the transformation comes from a weaver package you add alongside it.

The intended workflow is to add the engine and a weaver to the project, then name the weaver in the FodyWeavers.xml file at the project level. The Configuration page in Fody/Home documents the keys and options that file accepts. To confirm the weave ran, look for the ProcessedByFody marker class in the built assembly, which the README describes as added to target assemblies for diagnostic purposes. If a build fails during weaving, the README links a Common errors page in Fody/Home for that class of failure.

## Where the core engine is the wrong layer to depend on

The most important limitation is structural. This repository is the engine, and the engine alone does nothing useful to your assembly. Value comes from weavers, which live in separate packages with separate maintainers and separate release cadences. Pinning Fody does not pin the behaviour of the weaver doing the rewriting, and a weaver that has not been updated for a newer Fody or a newer target framework is where builds break.

Build-time IL rewriting also has an operational cost that runtime approaches avoid. The transformation happens during the build, so the build becomes the place where problems surface, and the assembled output differs from the source in ways a debugger does not always make obvious. The README's own troubleshooting entry, a Common errors page, exists precisely because this class of failure needs its own documentation.

Strong naming is another boundary. The README links a dedicated Strong naming page, which tells you this is a subject the project considers distinct rather than incidental. If your assemblies are strong named, read that page before assuming weaving is transparent.

Finally, the README does not document rollback of a weave. There is no described mechanism for undoing a transformation on an already built assembly. The practical fallback is rebuilding without the weaver configured, which is a build-level answer, not an engine feature.

## Fody against source generators and PostSharp

The nearest alternative in modern .NET is the source generator, which runs inside the compiler and emits additional C# rather than editing IL after compilation. The difference matters at the debugging boundary: generated source can be inspected as source, while a weaver's output is IL that no longer corresponds to anything you wrote. Source generators also cannot do everything a weaver can, because they add code rather than modify what the compiler already produced.

PostSharp is the other comparison the material itself invites. It appears in the README as a Gold Sponsor with a link to postsharp.net, so it is a commercial product in the same problem space, and the sponsorship is disclosed rather than hidden. The approach differs: PostSharp is a single vendor's product with its own aspect model, while Fody is an engine plus an ecosystem of independently maintained weavers. Choosing between them is largely a question of whether you want one supported product or a set of composable packages you assemble and track yourself.

A third option is doing nothing at build time and handling the concern at runtime through reflection or a proxy library. That avoids the build coupling entirely, at the cost of runtime overhead and a different set of constraints. Fody's premise is that build-time rewriting is worth that trade.

## Maintenance, releases and the patronage model

The repository is not archived, and the last push was on 2026-09-21. Recent releases listed are 6.9.3 on 2025-08-21, 6.9.2 on 2025-03-01 and 6.9.1 on 2024-11-19, so the release cadence is measured in months rather than weeks. The README directs readers to Milestones for release notes, and the changelog link points to the same place.

Upgrade cost is mostly ecosystem cost. Bumping the Fody package means checking that each weaver you use supports the new version and your target framework, and the README's Common errors and Configuration pages under Fody/Home are the reference points when something stops resolving. Budget for that per weaver, not once.

The licensing position deserves attention and is not something to resolve by reading a badge. The repository's License.txt is present, but the license is reported as NOASSERTION, meaning it does not map cleanly to a standard SPDX identifier. More directly, the README states that all developers using Fody are expected to become a Patron on OpenCollective, and it links a Licensing and patron FAQ for the details. That is an expectation stated by the project, not a legal determination, and the FAQ is the document to read. If you are evaluating Fody for commercial use, treat the licensing and patron FAQ as required reading before adoption, and get your own advice on what it means for your organisation.

## Conclusion

Adopt Fody when you want IL manipulation wired into an ordinary MSBuild build and you are prepared to treat the weaver ecosystem, not the core engine, as the real dependency. Skip it if you need a runtime-only solution or cannot accept a build-time assembly rewrite. Before committing, verify two things against the Fody/Home documentation: which weavers you actually need, and what the licensing and patron FAQ expects of commercial users.

## FAQ

### What is Fody and what does the core engine actually do?

Fody is an extensible tool for weaving .NET assemblies, meaning it manipulates the IL of an assembly as part of a build. This repository is the core engine; the transformations themselves come from add-ins called weavers, which are distributed separately.

### How do I install Fody in a .NET project?

Fody is distributed as the NuGet package Fody, added to the project whose assembly you want woven. Weaving is then configured through a FodyWeavers.xml file, and the README points to the Usage and Configuration pages in the Fody/Home repository for the details.

### How does Fody know which weavers to run?

Weavers are add-ins, and the README links a dedicated addin discovery page describing how they are resolved. In practice you add the weaver's package and name it in FodyWeavers.xml.

### How can I tell whether Fody actually wove my assembly?

The README documents a ProcessedByFody class that is added to target assemblies for diagnostic purposes. Its presence in the built assembly is the intended confirmation that weaving ran.

### Does Fody cost anything to use?

The README states that all developers using Fody are expected to become a Patron on OpenCollective, and it links a Licensing and patron FAQ. The repository license is reported as NOASSERTION, so the FAQ is the document to consult rather than the badge.

## Sources

- [Fody/Fody on GitHub](https://github.com/Fody/Fody)
- [Issues](https://github.com/Fody/Fody/issues)
- [README](https://github.com/Fody/Fody/blob/master/README.md)
- [Releases](https://github.com/Fody/Fody/releases)

---

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