PostSharp Blog

PostSharp 2026.0 Generally Available: Support for .NET 10, C# 14 and Extension Blocks

Wed, 07 Jan 2026 07:00:00 +0000

Alongside Metalama 2026.0, we’re announcing the general availability of PostSharp 2026.0. This release brings full support for .NET 10 and C# 14, including proper handling of the new extension blocks syntax introduced in C# 14.

.NET 10 and C# 14

We’ve updated and tested PostSharp to fully support the .NET 10 SDK and C# 14 across all packages. You can now confidently use PostSharp with the latest .NET stack.

Extension Blocks Support

C# 14 introduces extension blocks as an alternative syntax for defining extension methods. This new language feature required careful consideration in PostSharp to ensure predictable behavior.

By default, multicast attributes now skip extension block members. This prevents aspects from being unintentionally applied to compiler-generated metadata associated with extension blocks.

For scenarios where you do want to target extension block members, we’ve added the AllowExtensionBlockMembers property to both MulticastAttribute and MulticastAttributeUsageAttribute. Setting this property to true enables your aspects to target extension block members explicitly.

Additionally, developers using IAspectProvider or IAdviceProvider interfaces can use the new ReflectionHelper.IsExtensionBlockMetadata utility method to identify compiler-generated metadata associated with extension blocks.

Updated Framework Baselines

We’ve raised the minimum supported frameworks to reflect the current .NET ecosystem:

.NET Standard 2.0 (minimum)
.NET Framework 4.7.0 (minimum)
.NET 6.0 (minimum for .NET Core-based projects)

All pre-2017 target frameworks and obsolete .NET Core versions that have lost mainstream support have been removed. Please consult the breaking changes documentation for complete migration guidance.

Conclusion

PostSharp 2026.0 continues our commitment to keeping PostSharp compatible with the latest .NET releases. While our new feature development is focused on Metalama, we remain dedicated to ensuring that PostSharp users can stay current with the evolving .NET platform.

Happy meta-programming with PostSharp!

This article was first published on a https://blog.postsharp.net under the title PostSharp 2026.0 Generally Available: Support for .NET 10, C# 14 and Extension Blocks.

Security Notice: Data Leak Affecting a Limited Number of Accounts

Sun, 07 Sep 2025 23:00:01 +0000

We regret to inform you of a data leak that occurred on the PostSharp Customer Portal between Wednesday, September 3rd, and Tuesday, September 9th.

Who is affected?

A total of 38 customer accounts were impacted. If your account was affected, you will:

Receive a personal notification email within the next 24 hours.
Notice that you can no longer sign in to the portal using your license keys.

What data was leaked?

Only the content of the https://www.postsharp.net/account page of the portal was exposed, including:

Company name and billing address (or customer name and address for natural persons)
All subscription dates, number of users, licensed products, and support level
All license keys for PostSharp and Metalama

What was not leaked?

Contact lists or email addresses
Prices, invoices, or quotes
Support tickets
Source code (never uploaded to our servers)

Who accessed the data?

At most, one other PostSharp customer may have received your data in error.

How did this happen?

A caching error occurred in the daily job that sends subscription renewal notifications, causing account data to be sent to the wrong recipient. The first customer of the batch received all emails.

Timeline of events

Wed 9/3, 11:00 AM – First incorrect email sent.
Mon 9/8, 8:00 PM – Data leak reported by the receiving customer.
Tue 9/9, 2:00 PM – Report read and incident confirmed.
Tue 9/9, 4:30 PM – Credentials invalidated and issue remediated.

How we fixed it?

All past magic URLs were invalidated by rotating the salt for each affected account.
License keys exposed in the leak were disabled for authentication to the portal.
The caching bug was fixed.

Do you need to take action?

No action is required. Your license keys will continue to work normally with PostSharp and Metalama products.
If you prefer, we can issue new license keys on request, to ensure that any leaked key cannot be used by another party.

How to log in now?

If your license keys no longer work for portal login:

Use email authentication (one-time PIN or magic link) for one of your account contacts.
If you do not know your contact, please write to hello@postsharp.net from your work email.

We take full responsibility for this incident and sincerely apologize for the error. We are committed to ensuring it does not happen again.

This article was first published on a https://blog.postsharp.net under the title Security Notice: Data Leak Affecting a Limited Number of Accounts.

Breaking Update of PostSharp Caching adapter for Redis in 2025.1

Mon, 01 Sep 2025 23:00:01 +0000

We have released a refactored version of PostSharp.Patterns.Caching.Backends.Redis in PostSharp 2025.1 to address a reliability issue that could surface in multi-node Redis deployments (master/replica or cluster) when cache dependencies are enabled under sustained load. The fix required a redesign of the internal data schema, which is why this is a breaking change (one-time cache purge). Outside of that purge, the upgrade is straightforward and brings measurable gains in performance, consistency, and resilience.

Impact at a glance:

If you run multi-node Redis with dependencies, the update removes a potential failure mode.
You only need a one-time cache purge, and you’ll still benefit from performance and diagnostics improvements.
There is no risk of user data loss; only old cached entries stay in the database until purged.
No impact for the other backends.

Who is affected?

Affected by the bug:
- Applications that use PostSharp.Patterns.Caching.Backends.Redis with support for dependencies in a Redis master/replica or cluster setup.
Affected by the refactoring:
- All applications that use PostSharp.Patterns.Caching.Backends.Redis, with or without support for dependencies, are affected by the redesign of the data schema. You must purge the cache after the update, and there is no other impact. All versions prior to 2025.1.7 are affected.

Customers using Metalama.Patterns.Caching.Backends.Redis are affected by this issue too, and the solution has not yet been ported to Metalama. Please contact us if it matters to you.

What was wrong?

The previous design of the RedisCachingBackend relied on a retry loop in GetItem operations to retrieve a consistent snapshot of the cache item, which includes both the cache value and its dependencies, stored in separate Redis keys. Under heavy load in a master/replica setup, this loop could exhaust its iterations and fail.

The consistent snapshot of value and dependencies was required because recursive dependencies (when a cached method calls another already cached method) were flattened in the SetItem operation, so the RemoveItem and InvalidateItem operations did not need to operate recursively. This was a poor design choice.

The previous component was only tested in a single-node Redis topology. We believe the root cause was a lack of testing in multi-node topologies under high load.

How was this fixed?

We redesigned the data schema so GetItem never needs to iterate:

Dependencies are no longer flattened. The RemoveItem and InvalidateItem operations now work recursively.
Cache keys (a single logical cache item requires several Redis keys) are now versioned, so we don’t need loops to ensure read consistency.

What else has been improved?

Since a major refactoring was required to implement the new data schema, we went the extra mile and made the component more resilient in high-load production environments:

Performance improvements due to the new design of the Redis data schema that is always observationally consistent for read operations.
Key compression (hashing). Enable this feature by assigning the CachingServices.DefaultKeyBuilder property.
More resilient thanks to new behaviors controlled by the following properties on the RedisCachingBackendConfiguration object:
- Exception handling: RedisCachingBackendConfiguration.ExceptionHandlingPolicy.
- Retry policies: RedisCachingBackendConfiguration.BackgroundRecoveryRetryPolicy, RedisCachingBackendConfiguration.BackgroundTasksRetryPolicy, RedisCachingBackendConfiguration.TransactionRetryPolicy.
- Concurrency control: BackgroundTasksMaxConcurrency and InvalidationMaxConcurrency.
- Node selection: ReadCommandFlags and WriteCommandFlags, defaulting to PreferReplica and PreferMaster, respectively.
Support for sharding clusters, with keys containing taghashes. Tested on a 3+3 cluster.
Support for dependencies with a very large number of dependent cache items.
GC process:
- Detection of overloads and automatic temporary disabling.
- Periodic background cleanups to handle situations that were not detected by processing keyspace notifications in real time.
Keys contain the PostSharp Caching schema version for safe updates.
Fixed bugs with sliding expiration.
Improved documentation.

What changes are breaking?

The data schema has changed, so you must purge the old version’s cache; otherwise it will contain permanently unreachable data (garbage) forever.
The CacheValue.Dependencies and CacheItem.Dependencies properties now contain first-level dependencies rather than all recursive dependencies. These objects are largely implementation details and do not surface to the aspect-oriented API of PostSharp Caching.

How to update?

Update all PostSharp packages to 2025.1.8 and deploy your application.
Purge the cache using Redis’s FLUSHDB command after your old application has been undeployed.

If you ignore this post and only update the package, the Redis database will contain the data of the old version forever, since the dependency-management keys are set to never expire.

For details about the refactored PostSharp Caching for Redis, see our documentation.

Conclusion

PostSharp Caching for Redis now runs on a more robust, versioned schema that removes a reliability edge case and improves performance and consistency across single-node, replicated, and sharded clusters when dependency support is enabled. The component has been overhauled for better observability and resilience. The only required action is a one-time cache purge after upgrading to 2025.1.8 or later.

If you rely on the Metalama Redis backend, let us know so we can prioritize porting the same improvements.

Thanks to customers who surfaced the scenario early—enjoy the improved backend.

This article was first published on a https://blog.postsharp.net under the title Breaking Update of PostSharp Caching adapter for Redis in 2025.1.

PostSharp Is Now Source Available

Thu, 07 Aug 2025 23:00:01 +0000

This spring we open-sourced Metalama. Continuing that push for transparency and dependability, PostSharp’s source code is now available to enterprise customers at no extra cost. You can access a read-only mirror of our primary Git repository, including every version back to 1.0 (2009). It’s an exact copy of the repo we use to build the product — down to the commas. We also provide a supported, Docker-based build for versions 2024.0, 2025.0, and 2025.1. Those versions are no longer obfuscated in our public builds.

The code is released under a permissive, proprietary source-available license. You can modify, build, and distribute the software, provided users of the modified code hold a valid PostSharp license.

We are releasing our source code with the following use cases in mind:

Troubleshooting
Supply chain security
Supply chain resilience

In an era of tightening regulations (like the EU’s Cyber Resilience Act) and increased focus on software supply chain security, transparency isn’t optional — it’s necessary.

Who qualifies

To access the source, you need an Enterprise E1 support plan or higher, which is included in:

a 10-user subscription of PostSharp Ultimate, or
a 15-user subscription of PostSharp Framework.

There’s no additional cost — it’s included in your subscription.

If you have fewer users but need source access, add more users to your subscription.

See our support policies for a description of our support levels and their eligibility.

Before getting access to the repo, you must sign a Non-Disclosure & Non-Competing Agreement.

Use case 1. Troubleshooting

You now have full visibility into the source to troubleshoot issues.

We’ve disabled obfuscation in all maintained versions. When decompilation isn’t sufficient, you can read the original source.

Note: SourceLink is not available yet.

Use case 2. Supply chain security

Supply chain security isn’t just about trusting suppliers — it’s about trusting the code you run. With full access to our source, you can run your own analysis tools and assess the code’s quality.

Auditing the source alone isn’t enough. You need to guarantee that the binaries you execute were built from that audited source. That means you should be able to build the code yourself. To make that practical, we provide a Docker-based build that requires only Windows containers.

Once you’ve built the packages, you have two theoretical options to verify the chain of custody:

Use the packages you built yourself instead of sourcing them from nuget.org, or
Compare your packages with those sourced publicly.

In practice, our public binaries won’t be bitwise identical to what you build because our public builds are signed with Authenticode using a timestamp and a private certificate we cannot share. For that reason, only the first option — using your own built packages — is available to guarantee the chain of custody.

You can use Package Source Mapping (a NuGet client option) to ensure packages are sourced from your private builds rather than PostSharp’s public ones.

Use case 3. Supply chain resilience

Companies rely on PostSharp for mission-critical applications and need contingency plans for scenarios such as product end-of-life, company closure, or temporary inability of the supplier to deliver fixes or platform updates. By giving enterprise customers full source access, we enable practical contingency plans. You have the legal right and technical capability to:

Fork and maintain your own version of PostSharp if our support becomes unavailable
Apply critical security patches without waiting for official updates
Maintain older versions beyond their official support lifecycle
Ensure business continuity even in worst-case scenarios

Section 9 of the license agreement provides the legal framework for these business continuity scenarios, so you can be confident your critical systems won’t be held hostage by vendor dependencies.

How does it work?

1. Getting access

Sign in to the customer portal.
Check your support entitlements. You must have an Enterprise support plan (E1 or higher).
Go to the source access page.
Sign the Non-Disclosure/Non-Competing Agreement online (or offline).
Allow one business day for review and account update.
Return to the source access page and create Git users and passwords.
Clone the repositories using Git.
Check out one of the support release branches: release/2024.0, release/2025.0, or release/2025.1.

2. Building packages

See README.md in the cloned repo for details about requirements and build instructions.

You need a Windows 11 machine with Docker Desktop configured for Windows containers.
Open a PowerShell prompt and execute ./Build-Docker.ps1.
Wait — initial image creation can take over an hour on a high-end notebook; subsequent builds may take around 30 minutes.

Getting support

We’re here to help. Enterprise customers can email support@postsharp.net for help with source access, builds, or questions about the source-available license. Customers with Enterprise E2 support plans or higher can also reach us on Microsoft Teams or Slack for real-time collaboration and faster resolution of complex issues.

Limitations

The source code of Visual Studio Tools for Metalama and PostSharp is currently not available.
Our obligation is limited to a successful Docker build from the unmodified source:
- Although the repo includes CI/CD scripts, running those tests or configuring CI/CD infrastructure is not supported.
- We do not provide support for modified source code.
We only support building release branches for currently maintained versions.

Conclusion

Publishing PostSharp’s source is the final step in our 2025 transparency and dependability initiative, following Metalama’s earlier move to open source. Eligible customers now have full access to the source, improving supplier security and resilience.

If you want access, visit the PostSharp Customer Portal to verify your eligibility, complete the NDA/NCA process, and gain repository access.

This article was first published on a https://blog.postsharp.net under the title PostSharp Is Now Source Available.

Announcing Metalama 2025.1: Going Open Source!

Fri, 02 May 2025 04:00:01 +0000

Today, we’re excited to announce that Metalama 2025.1, our first open-source release, is now generally available! With this milestone, Metalama gets its own dedicated website at https://metalama.net. Be sure to check out the announcement to learn more about this transition and why it is so significant. This post covers the details of the changes in licensing, pricing, and support, and what they mean for our customers. Our goal is to make Metalama more accessible while continuing to provide productivity features and robust support for those who choose our premium plans.

Our objective with this move is to make our tools more accessible while offering enhanced support and services to customers who opt for higher-tier commercial plans, ensuring a balanced and sustainable approach for all users.

This article is part of a 3-post series announcing the launch of our 2025.1 versions:

Metalama Is Now Open Source – Adding Full Meta-Programming Capabilities to C#: an introduction to Metalama and our open-source vision.

Announcing Metalama 2025.1: Going Open Source!: changes in licensing and support terms for Metalama.

Announcing PostSharp 2025.1: changes in licensing and support terms for PostSharp.

TL;DR

The Metalama product line has been reorganized, with most of the code now open source. IDE tooling is now free for individuals, non-commercial use, or companies with up to three users.
Starting with version 2025.1, only the latest versions of our products will be available under an open-source or free license. Maintenance of older versions is reserved for commercial or enterprise customers based on their service level.

If you have any questions or concerns regarding this transition, please contact us at hello@postsharp.net.

These changes would not have been possible without breaking changes. Please check the release notes for details.

Open-source transition

Metalama is now primarily free and open source, released under the MIT license. The following components remain commercial:

Visual Studio extensions for Metalama.
Architecture validation (formerly the Metalama.Framework.Validation and Metalama.Extensions.Architecture namespaces).
Code fix toolkits (formerly the Metalama.Framework.CodeFixes namespace).
Redis and Azure adapters for Metalama.Patterns.Caching.

New product catalogue

The Metalama product line has been restructured to align with our new open-source business model, making our tools and frameworks free for individuals, small teams, and non-commercial use, while offering premium services and packages to larger organizations.

We have introduced a simplified product catalogue:

Metalama Community — A free edition, including Visual Studio tools, for individuals, non-commercial use, and organizations with up to three users.
Metalama Professional — A full-featured edition for commercial use.
Metalama Enterprise — Includes all Professional features, plus enhanced support and service benefits.

For a detailed comparison of editions, visit: https://www.postsharp.net/pricing/metalama.

Transitioning your existing subscriptions

Unless you are using Metalama Free, your current license key will continue to work with Metalama 2025.1 without any loss of functionality. Here’s how the transition affects different licenses:

Metalama Free: This edition has been retired, and its license will not work with Metalama 2025.1. Your options are:
- Use only the open-source components.
- Switch to Metalama Community.
- Upgrade to a Metalama Professional license.
Metalama Professional: Now the full-featured edition with unlimited functionality, but with limited support.
Metalama Starter and Metalama Ultimate: These editions have been retired. Your current license key will function as Metalama Professional in the new version, but you’ll need to convert your subscription to Metalama Professional upon renewal.

Pricing overhaul

We’ve restructured Metalama’s pricing to reflect the new model:

Metalama Professional: First-year pricing is $89 for individuals and $295 for businesses.
Volume Discounts are no longer available. Larger teams are now served by Metalama Enterprise, which offers four tiers with varying benefits and team sizes.

See Metalama pricing.

If the pricing changes negatively impact you and your software licensing budget has already been approved, please contact us. We’ll honor the previous pricing to ensure a smooth transition.

Support model updates

We have updated our support model to align with the open-source transition.
These changes apply only to new or renewed subscriptions. Existing contracts remain under the previous License and Support Services Agreement (LSSA).

Servicing phases

We have introduced servicing phases to clarify the lifecycle of Metalama versions (YYYY.N):

Current: Supported until the next version is released.
Extended: Supported for six months after the next release.
Long-Term Support (LTS): Supported for two years after the next LTS release or until the underlying platform reaches end-of-life.

Starting with version 2025.1, only the current version will be maintained under the open-source model. Access to Extended and LTS builds will require a commercial license.

Updates are never mandatory. Once a build becomes eligible for you, it will remain accessible indefinitely.

Note that maintenance builds of previous versions remain accessible to all users, regardless of support level.

For more details, visit: Versioning Policies.

Premium support tiers

We have formalized premium support into clear tiers, offering benefits such as:

Private support tickets
Access to Extended and LTS builds
Faster response times and issue escalation
Defined number of technical contacts
Access to proprietary source code
Advisory and video calls
GDPR/vendor form assistance
Private Slack or Teams channels
Priority bug fixes and remote debugging
EULA amendments and regression shields
License audit waivers
Open-source sponsorship tiers

For newly acquired or renewed subscriptions, the support level is determined by the edition (Professional or Enterprise tiers E1–E4). For existing subscriptions, the support level is determined by the number of users.

Please visit Service Levels for details regarding support benefits and how they map to product editions.

To know your current support level, please visit the customer portal.

Source code access

Metalama’s open-source code is now available on GitHub under the MIT license. Additionally, Enterprise customers gain exclusive access to private GitHub repositories for:

Premium packages (e.g., architecture validation, code fix toolkits, Redis and Azure adapters).
Core packages once they enter Extended Support or LTS phases.

To request access, check your support level in the customer portal and email us at hello@postsharp.net with the GitHub usernames to be granted access.

Conclusion

By transitioning Metalama to an open-source business model, we aim to promote greater awareness and adoption of meta-programming within the developer community.

We believe that vendor-led open source strikes the right balance between transparency and dependability: developers gain the ability to inspect and contribute to the code, while the vendor ensures long-term support through a sustainable commercial offering. If the vendor fails to uphold its commitment to maintaining the software, the community has the freedom to step in and take over.

Our goal is to create a fair balance between open-source accessibility, proprietary features, and premium services. We’ve worked hard to ensure these changes benefit as many users as possible. However, if you feel these changes impact you unfairly, please don’t hesitate to reach out. We’re committed to finding a solution that works for you.

Thank you for your continued support, and happy meta-programming!

-gael

This article was first published on a https://blog.postsharp.net under the title Announcing Metalama 2025.1: Going Open Source!.

Announcing PostSharp 2025.1

Fri, 02 May 2025 03:00:01 +0000

Today’s big announcement is that we are releasing Metalama 2025.1, our first open-source release. Be sure to visit the new website at https://metalama.net and check out the open-source announcement. Alongside this, we’re also launching PostSharp 2025.1 to align with our updated business model. This article explains the changes in licensing and support.

This article is part of a 3-post series announcing the launch of our 2025.1 versions:

Metalama Is Now Open Source – Adding Full Meta-Programming Capabilities to C#: an introduction to Metalama and to our open-source vision.

Announcing Metalama 2025.1: Going Open Source!: changes in licensing and support terms for Metalama.

Announcing PostSharp 2025.1: changes in licensing and support terms for PostSharp.

Your current subscription and license keys remain unaffected by these updates. All changes will take effect upon renewal.

Product consolidation

To simplify our product lineup, the following products will no longer be available for separate purchase:

PostSharp Logging is now included in PostSharp Framework.
PostSharp MVVM, Caching, and Threading are now exclusively part of PostSharp Ultimate.

If you already have a license or subscription for these products, don’t worry: your access will remain unchanged. You can continue to renew your subscription or add new users as needed.

Pricing updates

For the first time since 2016, we’ve adjusted PostSharp pricing to reflect currency fluctuations:

USD prices have increased by 5–10%, depending on the product.
EUR prices have been adjusted by -5% to +5%, depending on the product.

For detailed pricing information, visit: https://www.postsharp.net/pricing/postsharp.

Servicing phases

Until now, we maintained legacy versions and made bug-fix releases available to everyone. Starting with PostSharp 2025.1, access to maintenance builds for legacy versions will be reserved for commercial customers. This change aligns PostSharp with Metalama’s support model.

We’ve introduced the concept of servicing phases to clarify the lifecycle of PostSharp versions (YYYY.N):

Current: Supported until the next version is released. Available to all users, including those with a free edition.
Extended: Supported for six months after the next release (instead of two months prior to 2025.1). Available to all commercial customers.
Long-Term Support (LTS): Supported for two years after the next LTS release or until the underlying platform reaches end-of-life. Available to customers with Enterprise support.

Starting with version 2025.1, only the current version will be available to PostSharp Essentials users. Access to Extended builds will require a commercial license, and LTS builds will require an Enterprise support level.

Updates are never mandatory. Once a build becomes eligible for you, it will remain accessible indefinitely.

Maintenance builds of previous versions will remain available to all users, regardless of support level.

For more details, visit: Versioning Policies.

Support levels

You might be wondering about the new Enterprise support level.

Previously, we didn’t have a formalized approach to SLAs, and we informally prioritized customers based on their expenditures. Moving forward, your support level will depend on the number of licenses you acquire. For PostSharp Framework, Enterprise support starts at 15 users; for PostSharp Ultimate, it starts at 10. These thresholds are designed to align with the pricing of various Metalama Enterprise support plans, as PostSharp subscriptions also include a Metalama license.

Details about support levels and their mapping to the number of users can be found here: Support Levels.

Plans to release the source code

To further align PostSharp with Metalama’s support model, we plan to release PostSharp’s source code in a private GitHub repository accessible to enterprise customers, with rights to modify and build the product. We expect this to be available by next spring and will keep you updated.

PostSharp Essentials improvements

PostSharp Essentials now offers unlimited support for async methods, addressing a long-standing limitation.

Website updates

With Metalama now having its own dedicated website, we’ve streamlined and reorganized https://www.postsharp.net to provide a cleaner, more focused experience.

Summary

PostSharp 2025.1 introduces updates to licensing, pricing, and support models, aligning with Metalama’s open-source vision. While no new features or platform updates are included, these changes simplify the product lineup and clarify support levels. Stay tuned for updates on the release of PostSharp’s source code.

This article was first published on a https://blog.postsharp.net under the title Announcing PostSharp 2025.1.

Metalama status update, March 2025

Mon, 31 Mar 2025 08:00:01 +0000

This month, we released a preview of Metalama 2025.1, marking a significant milestone as the first open-source version of Metalama. Our efforts to complete the open-source transition will continue in April.

Metalama 2025.1: open-source preview

Earlier this year, we shared our plans to make Metalama open-source. Since then, we’ve been working hard to bring this vision to life. In March, we released the first preview of Metalama 2025.1, with most components now licensed under MIT. This is a major step toward transitioning Metalama to an open-core business model.

What’s left to do

While we’re excited to share this progress with the Metalama community, this isn’t the big announcement yet. There’s still work to be done:

Fixing some bugs
Testing on VMs and physical devices
Launching a new website
Updating documentation and README files
Migrating the issue tracker to GitHub
Aligning sales pages and processes with the new offering

Licensing notes

At this stage, licenses for the new business model are not yet available for purchase.

Existing Metalama commercial licenses remain compatible with the commercial parts of Metalama 2025.1. However, Metalama Free is not compatible. To use Visual Studio Tools for Metalama, you’ll need either a Metalama license key or to activate Metalama Community. Metalama Community is available for non-commercial users, individuals, companies with up to three users, and contributors to open-source projects.

Resources to get started

Here’s how you can explore Metalama 2025.1 today:

End of support for Metalama 2024.2

As per our support policies, support for Metalama 2024.2 has ended. The only supported version now is Metalama 2025.0.

Metalama 2025.0 maintenance builds

We’ve released several maintenance builds for Metalama 2025.0 (2025.0.9 and 2025.0.10), addressing bugs and integrating the latest stable Roslyn build.

Updated roadmap

Our focus in April is to finalize the open-source transition. Here’s the updated timeline:

First week of April: Release Candidate (RC)
Late April or Early May: General Availability (GA)

Thank you for your continued support. Happy meta-programming!

-gael

This article was first published on a https://blog.postsharp.net under the title Metalama status update, March 2025.

Metalama Status Update, February 2025

Thu, 27 Feb 2025 08:00:01 +0000

Last month, we shared our exciting plans to make Metalama open-source, and throughout February, we’ve been hard at work making it happen. While we’ve made significant technical progress, we’re not quite ready to release just yet.

On the technical side, we’ve successfully modularized key features in preparation for the transition, allowing us to keep some components proprietary. However, the legal aspects of dual-licensing Metalama are still in progress. It’s a complex process, and we want to ensure everything is done right from the start. This is the main factor delaying the release of our source code and binaries.

Updated Roadmap

Here’s our revised timeline for the open-source release:

First half of March: First open-source preview release
Second half of March: Release Candidate (RC)
Second half of April: General Availability (GA)

If the legal process takes longer than expected, we’ll use the extra time to introduce a new feature in the 2025.1 release: intercepting event invocations.

Between the RC and GA releases, our focus will shift toward supporting infrastructure, including:

Launching a dedicated Metalama website
Migrating project and issue management to GitHub
Updating our e-shop and CRM systems

Stay Tuned!

We’re committed to making this transition smooth and impactful. Thank you for your patience and enthusiasm — we’re almost there! Keep an eye out for our updates.

This article was first published on a https://blog.postsharp.net under the title Metalama Status Update, February 2025.

Metalama Status Update, January 2025

Fri, 31 Jan 2025 08:00:01 +0000

As we returned from the winter break, we hit the ground running by launching Metalama and PostSharp 2025.0. But that wasn’t all—after careful consideration and experimentation, we’re thrilled to share some groundbreaking news: Metalama is going open-source!

Metalama and PostSharp 2025.0 are generally available

Following the release of Metalama and PostSharp 2025.0 Release Candidate (RC) in November, we dedicated much of December to squashing bugs. With Metalama maturing steadily, we’ve started addressing long-term, low-priority issues from our backlog.

Our first major milestone of the year was deploying PostSharp and Metalama 2025.0 on January 4th. Here’s what’s new:

Metalama 2025.0:
- Adds support for C# 13 and .NET 9.
- Introduces significant enhancements to the aspect framework.
- Delivers substantial performance improvements.
  Check out the Metalama 2025.0 announcement.
PostSharp 2025.0:
- Adds support for C# 13, .NET 9, and long paths in projects targeting .NET Framework.
- Improves runtime performance for WeakEventHandler.
- Enhances the debugging experience with Windows PDB files.
  Learn more in the PostSharp 2025.0 announcement.

Metalama 2025.1: going open-source

Earlier this week, we announced that Metalama 2025.1 will be free and open-source. To ensure the project’s sustainability, we’ll offer commercial IDE tooling, extensions, and support. We fully commit to a cooperative development process, moving everything to GitHub. Metalama will get a dedicated website and GitHub organization, marking its evolution into an independent, community-driven project separate from PostSharp Technologies.

Visit the announcement to learn more about:

What will be free and open-source, and what won’t?
Our new commercial offerings.
Our updated policies for long-term support.

Your input is invaluable as we implement these changes, so don’t hesitate to share your thoughts while the plans are still being developed.

Godot + Metalama = ♡, by Philip Rotter

Godot, the incredibly efficient open-source game engine, has gained popularity among developers. While many prefer using C# over GDScript due to its rich ecosystem, exporting C# properties to Godot often involves tedious boilerplate code.

In his latest guest post, Enhancing Godot Development with Metalama, Philip Rotter demonstrates how Metalama can streamline this process. By leveraging Metalama, Philip eliminates redundant code and makes C# development with Godot both fun and efficient — all through a simple, straightforward aspect.

Thank you very much to Philip for this insightful contribution! It will be an invaluable resource for Godot users looking to explore Metalama for the first time.

Looking ahead

With Metalama’s transition to open-source, 2025 is shaping to be an exciting year! We’re committed to empowering developers with cutting-edge tools to remove code repetition, built together in a collaborative community. Stay tuned for more updates, and don’t forget to share your feedback on Slack or GitHub as we continue to evolve and innovate.

Happy meta-programming!

This article was first published on a https://blog.postsharp.net under the title Metalama Status Update, January 2025.

Enhancing Godot Development with Metalama

Wed, 29 Jan 2025 07:00:00 +0000

Godot is an amazing open-source game engine that provides developers with the tools to build games efficiently. While GDScript is Godot’s native language, many developers prefer to use C# for its rich ecosystem and the ability to leverage third-party libraries. One such library is Metalama, a powerful metaprogramming framework that can streamline repetitive or error-prone tasks.

In this article, we’ll explore how to use Metalama to simplify property usage customization in Godot. Specifically, we’ll address a common problem: defining property usage for exported properties in the Godot editor.

About the author

Philip Rotter is a full-stack developer and passionate game creator with a deep knowledge of diverse game engines and development tools. Currently, he’s focused on building Gradual Warfare, a mobile game developed using the Godot Engine. Gradual Warfare is a future-punk strategy game that blends auto-battle and idle mechanics for an engaging and dynamic player experience. Connect with him on LinkedIn.

The Problem: Boilerplate Code for Property Usage

The Godot editor allows developers to customize components and resources by overriding the _ValidateProperty method and setting flags that define property behavior. However, managing property usage flags often results in repetitive and boilerplate-heavy code.

For example, imagine you want to create a class with an exported string property that’s only useful in the editor and another property that is hidden in the editor but serialized for runtime use. Here’s how you would traditionally handle this:

[GlobalClass]
[Tool]
public partial class ArmyContainer : Resource
{
    [Export]
    private string ExportString;

    [Export]
    public bool ContainsHello;

    public override void _ValidateProperty(Dictionary property)
    {
        if (property["name"].AsStringName() == nameof(ExportString))
        {
            property["usage"] = (int)PropertyUsageFlags.Editor;
        }
        else if (property["name"].AsStringName() == nameof(ContainsHello))
        {
            property["usage"] = (int)PropertyUsageFlags.NoEditor;
        }
    }
}

This approach works but quickly becomes cumbersome as the number of properties grows. What if we could eliminate this boilerplate and simplify the code?

The Solution: Attributes and Metalama

Using Metalama, we can replace the repetitive code with clean, declarative attributes. Here’s what the rewritten class will look like:

[GlobalClass]
[Tool]
public partial class ArmyContainer : Resource
{
    [Export]
    [OnlyInEditor]
    private string ExportString;

    [Export]
    [HideInEditor]
    public bool ContainsHello;
}

Much cleaner, right? With the help of Metalama, we’ll make these attributes automatically handle property usage without manually overriding _ValidateProperty.

Step 1: Define Custom Attributes

First, we’ll define the base attribute, GenPropertyUsageAttribute, which will serve as the foundation for specific attributes like OnlyInEditor and HideInEditor.

[AttributeUsage(AttributeTargets.Field | AttributeTargets.Property)]
[RunTimeOrCompileTime]
public class GenPropertyUsageAttribute : Attribute
{
    // Default value: 6 (store and show in editor)
    public int PropertyUsageFlags { get; set; } = 6;

    public GenPropertyUsageAttribute() { }

    // Constructor to override default PropertyUsageFlags
    public GenPropertyUsageAttribute(int propertyUsageFlags)
    {
        PropertyUsageFlags = propertyUsageFlags;
    }
}

Now, let’s create two derived attributes for common use cases:

OnlyInEditor: The property is visible in the editor but not stored.
HideInEditor: The property is stored but not visible in the editor.

[RunTimeOrCompileTime]
public class OnlyInEditorAttribute : GenPropertyUsageAttribute
{
    public static new int PropertyUsageFlags { get; set; } = 4; // Editor-only, no storage

    public OnlyInEditorAttribute() : base(PropertyUsageFlags) { }
}

[RunTimeOrCompileTime]
public class HideInEditorAttribute : GenPropertyUsageAttribute
{
    public new static int PropertyUsageFlags { get; set; } = 2; // No editor, storage only

    public HideInEditorAttribute() : base(PropertyUsageFlags) { }
}

Step 2: Create the Aspect

Next, we’ll create a Metalama aspect that scans for attributes like OnlyInEditor and HideInEditor, then injects logic into the _ValidateProperty method to apply the appropriate PropertyUsageFlags.

internal sealed class GenPropertyUsageTypeAspect : IAspect<INamedType>
{
    public void BuildEligibility(IEligibilityBuilder<INamedType> builder)
    {
        builder.MustHaveAttributeOfType(typeof(ToolAttribute));
        builder.MustBeConvertibleTo(typeof(GodotObject));
    }

    public void BuildAspect(IAspectBuilder<INamedType> builder)
    {
        // Select fields that have the [GenPropertyUsage] attribute.
        var fields = builder.Target.AllFieldsAndProperties
            .Where(property =>
                property.Attributes.OfAttributeType(typeof(GenPropertyUsageAttribute)).Any());

        // Skip the aspect if we don't have any field.
        if (!fields.Any())
        {
            builder.SkipAspect();
            return;
        }

        // Introduce a method named _ValidateProperty 
        // using the template ValidatePropertyTemplate defined below.
        builder.IntroduceMethod(
            nameof(this._ValidateProperty),
            tags: new { Fields = fields },
            whenExists: OverrideStrategy.Override );
    }

    // Template for the new _ValidateProperty method.
    [Template]
    public void _ValidateProperty(Dictionary property)
    {
        // Call the base method or the hand-written implementation, if any.
        meta.Proceed();

        var name = property["name"].AsStringName();

        // Enumerate all fields identified in the BuildAspect method.
        // (This loop executes at build time.)
        foreach (var classFieldOrProperty in (IEnumerable<IFieldOrPropertyOrIndexer>)meta.Tags["Fields"])
        {
            if (name == classFieldOrProperty.Name)
            {
                var attribute = classFieldOrProperty
                    .Attributes
                    .GetConstructedAttributesOfType<GenPropertyUsageAttribute>()
                    .First();

                property["usage"] = attribute.PropertyUsageFlags;
            }
        }
    }
}

Step 3: Create the Fabric

Finally, we’ll use a Metalama fabric to apply our aspect to all eligible classes.

internal sealed class GenPropertyUsageTypeFabric : ProjectFabric
{
    public override void AmendProject(IProjectAmender amender)
    {
        amender
            .SelectDeclarationsWithAttribute(typeof(ToolAttribute))
            .OfType<INamedType>()
            .AddAspectIfEligible(t => new GenPropertyUsageTypeAspect());
    }
}

Testing the Result

To test the implementation, you can create a Tool script in Godot with annotated properties:

[GlobalClass]
[Tool]
public partial class ArmyContainer : Resource
{
    [Export]
    [OnlyInEditor]
    private string ExportString;

    [Export]
    [HideInEditor]
    public bool ContainsHello;
}

In the Godot editor:

ExportString will be visible but not serialized.
ContainsHello will be serialized but not visible in the editor.

This approach eliminates boilerplate code and makes property management much cleaner.

Conclusion

With Metalama, we extended Godot’s functionality by automating the customization of property usage. This approach saves time, reduces boilerplate, and minimizes errors. By leveraging attributes and metaprogramming, we can focus on creating games rather than managing tedious editor logic.

Stay tuned for more tutorials on how to enhance Godot development with powerful tools like Metalama. Have fun coding!

This article was first published on a https://blog.postsharp.net under the title Enhancing Godot Development with Metalama.

PostSharp Blog

PostSharp 2026.0 Generally Available: Support for .NET 10, C# 14 and Extension Blocks

.NET 10 and C# 14

Extension Blocks Support

Updated Framework Baselines

Conclusion

Security Notice: Data Leak Affecting a Limited Number of Accounts

Who is affected?

What data was leaked?

What was not leaked?

Who accessed the data?

How did this happen?

Timeline of events

How we fixed it?

Do you need to take action?

How to log in now?

Breaking Update of PostSharp Caching adapter for Redis in 2025.1

Who is affected?

What was wrong?

How was this fixed?

What else has been improved?

What changes are breaking?

How to update?

Read more

Conclusion

PostSharp Is Now Source Available

Who qualifies

Use case 1. Troubleshooting

Use case 2. Supply chain security

Use case 3. Supply chain resilience

How does it work?

1. Getting access

2. Building packages

Getting support

Limitations

Conclusion

Announcing Metalama 2025.1: Going Open Source!

TL;DR

Open-source transition

New product catalogue

Transitioning your existing subscriptions

Pricing overhaul

Support model updates

Servicing phases

Premium support tiers

Source code access

Conclusion

Announcing PostSharp 2025.1

Product consolidation

Pricing updates

Servicing phases

Support levels

Plans to release the source code

PostSharp Essentials improvements

Website updates

Summary

Metalama status update, March 2025

Metalama 2025.1: open-source preview

What’s left to do

Licensing notes

Resources to get started

End of support for Metalama 2024.2

Metalama 2025.0 maintenance builds

Updated roadmap

Metalama Status Update, February 2025

Updated Roadmap

Stay Tuned!

Metalama Status Update, January 2025

Metalama and PostSharp 2025.0 are generally available

Metalama 2025.1: going open-source

Godot + Metalama = ♡, by Philip Rotter

Looking ahead

Enhancing Godot Development with Metalama

About the author

The Problem: Boilerplate Code for Property Usage

The Solution: Attributes and Metalama

Step 1: Define Custom Attributes

Step 2: Create the Aspect

Step 3: Create the Fabric

Testing the Result