Manipulating the IL of an assembly as part of a build requires a significant amount of plumbing code. This plumbing code involves knowledge of both the MSBuild and Visual Studio APIs. Fody attempts to eliminate that plumbing code through an extensible add-in model.

Already a Patron? skip past this section

It is expected that all developers using Fody become a Patron on OpenCollective. Go to licensing FAQ

Support this project by becoming a Platinum Sponsor. A banner with your company logo will be added here with a link to your website. A "Sponsored by" text and link will be added to the description of the NuGet Package for the life of your sponsorship. You also get 1 hour of remote support per month.

Support this project by becoming a Gold Sponsor. A large company logo will be added here with a link to your website.

Support this project by becoming a Silver Sponsor. A medium company logo will be added here with a link to your website.

Support this project by becoming a Bronze Sponsor. The company avatar will show up here with a link to your OpenCollective Profile.

Thanks to all the backers and sponsors! Support this project by becoming a patron.

For the generous donation of ReSharper licenses.

It is expected that all developers using Fody become a Patron on OpenCollective.

No, it will include version 3.3.3 and higher.

It is an honesty system with no code or legal enforcement. When raising an issue or a pull request, the GitHub Id may be checked to ensure they are a patron, and that issue/PR may be closed without further examination. This process will depend on the issue quality, your circumstances, and the impact on the larger user base. If a individual or organization has no interest in the long term sustainability of the project, then they are legally free to ignore the honesty system.

• Open-Source Maintainers are Jerks! | Nick Randolph & Geoffrey Huntley
• FOSS is free as in toilet | Geoffroy Couprie
• How to Charge for your Open Source | Mike Perham
• Sustain OSS: The Report
• Open Source Maintainers Owe You Nothing | Mike McQuaid
• Who should fund open source projects? | Jane Elizabeth
• Apply at OSS Inc today| Ryan Chenkie
• The Ethics of Unpaid Labor and the OSS Community | Ashe Dryden

Fody (all code, NuGets and binaries) are under the MIT License.

Using any OSS license in a modified form causes significant problems with adoption of tools. There is no simplified guidance on using modified licenses. For example they are not included in choose a license or tldr legal. It often forces an organization to obtain approval from a legal department. It means any consuming tools need to ensure that the modified license does not propagate in an undesirable way.

Yes in theory this is true, however the long term reality has shown this not to be the case. The vast majority of consumers of open source projects do not contribute enough to ensure those project survive. This results in a small core team spending large amounts of their own free time maintaining projects.

No. As per the MIT license:

the software is provided "as is", without warranty of any kind

For a supported product, you should instead consider PostSharp. PostSharp is a mature and supported product that is used by Fortune 500 companies as well as startups, and it doesn't require knowledge of IL.

They offer a free edition and their feature list includes: Aspect-Oriented Programming, Logging, INotifyPropertyChanged, Caching, Transactions, Security, Multithreading, Code Contracts, XAML plumbing, and Architecture Validation.

Yes all projects are under MIT and you can ignore the community backing honesty system and use Fody for free.

Yes. You must be a Patron to be a user of Fody. Contributing Pull Requests does not cancel this out. It may seem unfair to expect people both contribute PRs and also financially back this project. However it is important to remember the effort in reviewing and merging a PR is often similar to that of creating the PR. Also the project maintainers are committing to support that added code (feature or bug fix) for the life of the project.

There are two options for an organization.

1. Apply a multiplier to the Patron cost. The Patron tier has no upper bound on the monthly amount. This allows an organization with multiple developers to pay a single monthly price. For example: An organization with 5 developers would pay $15 per month, i.e. 5 x $3 per patron. An organization with 10 developers would pay $30 per month, i.e. 10 x $3 per patron and so on.
2. Create an Open Collective organization A organization can Create an Open Collective organization and then allow their developers to draw on the funds from that organization. See FAQ for backers. This is the recommended option as it also opens up the opportunity for developers to select other projects they feel need support.

No. Only those coding against projects that directly, or indirectly, consume the Fody NuGet package.

Yes, since the only point of (optional) enforcement is when an issue or PR is raised, then legally an organization can ignore the honesty system and route all issues and PRs though a single GitHub user account. However if a single GitHub user account is drawing on significant time to support, they may be requested to purchase some hourly support.

It is be expected that the core team of maintainers of any open source projects that consume or produce Fody weavers would become Patrons. Non core contributors do not need to become Patrons. For example, in the context of GitHub, this would be any people with push access to the the repository. The reasoning is that if a project is utilizing Fody, that should not be a blocker for the larger community from contributing to the project.

Yes.

Consumers of that produced library do not need to become Patrons.

Install using NuGet. See Using the package manager console for more info.

Fody ships in two parts:

1. The core "engine" shipped in the Fody NuGet package
2. Any number of "addins" or "weavers" which are all shipped in their own NuGet packages.

The below examples will use Virtuosity.

Since NuGet always defaults to the oldest, and most buggy, version of any dependency it is important to do a NuGet install of Fody after installing any weaver.

Install-Package Fody

Subscribe to Fody on Libraries.io to get notified of releases of Fody.

Install the package in the project:

Install-Package WeaverName.Fody

e.g.

Install-Package Virtuosity.Fody

To indicate what weavers run and in what order a FodyWeavers.xml file is used at the project level. It needs to be added manually. It takes the following form:

<?xml version="1.0" encoding="utf-8" ?>
<Weavers>
  <WeaverName/>
</Weavers>

e.g.

<?xml version="1.0" encoding="utf-8" ?>
<Weavers>
  <Virtuosity/>
</Weavers>

See Configuration in the wiki for additional options.

The Project Configuration Manager provides an interactive tool that can support you configuring your weavers, which is especially helpful in solutions with many projects.

To build a project using Fody you will need:

• Visual Studio 2017 or later
• .Net >= 4.6

Older versions of Visual Studio may still work, but are not actively supported. We do our best to not break backward compatibility, but can't guarantee this forever.

• Classic .NET: See Support ended in NET Framework version history. i.e only 4.5.2 and above is supported.
• .NET core: Follows .NET Core Support Policy.

No explicit code is in place to check for non supported versions, and throw an error. As such earlier versions of .net may work as a side effect. It's all up to the individual weavers that you use and what version they are able to support.

Any bugs found must be reproduced in a supported version.

Downstream plugins are recommended to follow the above guidelines.

While it may seam trivial to "implement support for earlier versions of .net" the long term support implications are too costly. For example to support earlier versions of .net require

• Custom VMs to verify problems.
• Added complexity to setting up build environment.
• Bugs in unsupported versions in .NET may be manifest as bugs in Fody.

Edit and continue is not supported. There is no extension point to re-weave an assembly after the edit part.

The following are not supported

• Projects using the project.json.
• Projects using the xproj.
• Projects mixing the old .csproj format with new <PackageReference> nodes.

To tell the difference between the old and new csproj formats.

The old format starts with

<Project ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

The new format starts with

<Project Sdk="Microsoft.NET.Sdk">

For all these scenarios is it instead recommended to move to the new VS 2017 SDK style projects.

References

• Bye-Bye Project.json and .xproj and welcome back .csproj
• Project.json to MSBuild conversion guide
• Migrate from project.json to new VS 2017 SDK style projects

This technique of "weaving" in new instructions is fantastically powerful. You can turn simple public properties into full INotifyPropertyChanged implementations, add checks for null arguments, add Git hashes to your Assemblies, even make all your string comparisons case insensitive.

• 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

Fody Uses Mono.Cecil and an add-in based approach to modifying the IL of .net assemblies at compile time.

• No install required to build
• No attributes required
• No references required

The name "Fody" comes from the small birds that belong to the weaver family Ploceidae.

• BasicFodyAddin A simple project meant to illustrate how to build an addin.
• FodyAddinSamples is a single solution that contains a working copy of every fody addin.

• Anotar Simplifies logging through a static class and some IL manipulation.
• AssertMessage Generates 'message' from sourcecode and adds it to assertion.
• AsyncErrorHandler Integrates error handling into async and TPL code.
• AutoDependencyProperty Generates WPF DependencyProperty boilerplate from automatic C# properties.
• AutoProperties Gives you extended control over auto-properties, like directly accessing the backing field or intercepting getters and setters.
• AutoDI A dependency injection container and a framework to simplify working with dependency injection (DI). It is built on top of the Microsoft.Extensions.DependencyInjection.Abstractions.
• BasicFodyAddin A simple project meant to illustrate how to build an addin.
• Bindables Converts your auto properties into Wpf dependency or attached properties. Allows specifying options, defining readonly properties, and calling property changed methods.
• Caseless Change string comparisons to be case insensitive.
• Catel For transforming automatic properties into Catel properties.
• Cauldron Provides method, property and field interception. It also provides weavers for Cauldron.Core and Cauldron.Activator.
• ConfigureAwait Allows you to set the async ConfigureAwait at a global level for all your await calls.
• Costura For embedding references as resources.
• CryptStr Encrypts literal strings in your .NET assemblies.
• DependencyInjection automatic dependency injection for Ninject, Autofac and Spring.
• EmptyConstructor Adds an empty constructor to classes even if a non empty one is defined.
• EmptyStringGuard Adds empty string argument checks to an assembly.
• EnableFaking Allows faking your types without writing interfaces for testing purposes only.
• Equals Generate Equals, GetHashCode and operators methods from properties.
• Equatable Generate Equals, GetHashCode and operators methods from explicit annotated fields and properties.
• Expose Exposes members and optionally implements interface of a field declared in class.
• ExtraConstraints Facilitates adding constraints for Enum and Delegate to types and methods.
• FactoryId Simplifies the implementation of Factory Method Pattern
• Fielder Converts public fields to public properties.
• FodyDependencyInjection Dependency injection with Fody add-ins.
• Freezable Implements the Freezable pattern.
• InfoOf Provides methodof, propertyof and fieldof equivalents of typeof.
• InlineIL Provides a way to embed arbitrary IL instructions in existing code.
• Ionad Replaces static method calls.
• Janitor Simplifies the implementation of IDisposable.
• JetBrainsAnnotations Converts all JetBrains ReSharper code annotation attributes to External Annotations.
• Lazy Automates the plumbing around System.Lazy.
• LoadAssembliesOnStartup Loads references on startup by using the types in the module initializer
• LoggerIsEnabled Adds ILogger.IsEnabled check around the logging statement for the Microsoft.Extensions.Logging
• MethodBoundaryAspect Allows to decorate methods and hook into method start, method end and method exceptions (like PostSharp)
• MethodCache Caches return values of methods decorated with a CacheAttribute.
• MethodDecorator Decorate arbitrary methods to run code before and after invocation.
• MethodTimer Injects method timing code.
• ModuleInit Adds a module initializer to an assembly.
• Mutable Make F# setters for union types and eliminate need for CLIMutable attribute for records.
• Mvid Adds the ability to specify the assembly MVID (Module Version Id).
• Nancy.ModelPostprocess Modify Nancy models after route execution but before serialization
• NObservable MobX-like observable state management library with Blazor support.
• NullGuard Adds null argument checks to an assembly
• Obsolete Helps keep usages of ObsoleteAttribute consistent.
• Padded Adds padding to fight the false sharing problem.
• PropertyChanged Injects INotifyPropertyChanged code into properties.
• PropertyChanging Injects INotifyPropertyChanging code into properties.
• Publicize Converts non-public members to public hidden members.
• QueryValidator Validates your DB queries during a build.
• Realm Mobile database: a replacement for SQLite & ORMs.
• ReactiveUI.Fody Generates ReactiveUI RaisePropertyChanged notifications for properties and OAPHs.
• Resourcer Simplifies reading embedded resources from an Assembly.
• RomanticWeb Fody weaver plugin for RomanticWeb instrumentation.
• Spring Spring constructor configuration.
• Stamp Stamps an assembly with git data.
• StampSvn Stamps an assembly with SVN data.
• StaticProxy Proxy Generator, also for .net standard / .net core (.net standard 1.0+).
• Substitute Substitute types with other types to e.g. intercept generated code
• SexyProxy Proxy generator with support for async patterns.
• SwallowExceptions Swallow Exceptions in targeted methods.
• TestFlask Records your method args and responses to replay, assert and test.
• Throttle Easily use throttles with minimal coding
• ToString Generate ToString method from public properties.
• Tracer Adds trace-enter and trace-leave log entries for selected methods.
• Undisposed Debugging tool to track down undisposed objects.
• Usable Adds using statements for local variables that have been created, and implement IDisposable.
• Validar Injects IDataErrorInfo or INotifyDataErrorInfo code into a class at compile time.
• Vandelay Simplifies MEF importing\exporting.
• Visualize Adds debugger attributes to help visualize objects.
• Virtuosity Change all members to virtual.
• WeakEvents Automatic publishing of weak events via compile time code weaving and a supporting runtime library.
• With Methods to return copies of immutable objects with one property modified.
• YALF Yet Another Logging Framework.
• Tail Adds a postfixed method call instruction to recursive calls.

The below addins are no longer maintained. Raise an issue in the specific project if you would like to take ownership.

• ArraySlice ArraySlice allows to build shared memory array views without performance impact. It uses IL manipulation to achieve the fastest implementation.
• AutoLazy Automatically implements the double-checked locking pattern on specified properties and methods.
• Cilador Write your own mixins in C# for code reuse without inheritance.
• Commander Injects ICommand properties and implementations for use in MVVM applications.
• Mixins A mixin is a class that provides a certain functionality to be inherited or just reused by a subclass.
• NameOf Provides strongly typed access to a compile-time string representing the name of a variable, field, property, method, event, enum value, or type.
• RemoveReference Facilitates removing references in a compiled assembly during a build.
• Scalpel Strips tests from an assembly.
• Seal mark all non-virtual(abstract, non-sealed) types as sealed by default.
• Stiletto Compile-time static analysis and optimization for the Stiletto IoC library.

Bird designed by Marco Hernandez from The Noun Project

• Wiki Home
• Configuration
• AddinSearchPaths
• DeployingAddinsAsNugets
• HowToWriteAnAddin
• InSolutionWeaving
• AssemblyVerification
• ModuleWeaver
• PdbReWritingAndDebugging
• SignedAssemblies
• SupportedRuntimesAndIde
• TaskAddsAFlagInterface
• TaskCouldNotBeLoaded
• WeavingTaskOptions
• ThrowingAnExceptionFromAnAddin
• Mono Support
• Building From A Network Share

This project exists thanks to all the people who contribute. [Contribute].