A friendly warning appears in the output window after C# 7.3 project is built with PostSharp 6.0.18 - suggesting the latest PostSharp version (as of this post writing) only officially supports up to C# 7.2.

I'd appreciate if we could have C# 7.3 support in PostSharp 6 (perhaps next update)?

Here goes more details of mine development machine:

Running on environment:
Windows 10 (x64)
.NET Framework 4.7.1
Visual Studio Enterprise 2017 (version 15.7.5)
PostSharp (version 6.0.18)

Steps to reproduce:
Create a new C# Console application (targetting .NET Framework 4.7.1), and enable PostSharp for the project.
Go to project's properties. Select 'Build' tab. Click on the 'Advanced...' button (on the bottom of the page).
Change language version to 'C# latest minor version (latest)' (which is version 7.3 as of this post writing). Click on the 'OK' button.
Save all changes (Ctrl+Shift+S). Build the project (right click the project in Solution Explorer, and select Build).

Output:
1>------ Build started: Project: ConsoleApp, Configuration: Debug Any CPU ------
1>H:\ConsoleApp\packages\PostSharp.6.0.18\build\PostSharp.targets(149,5): warning : The selected CSharp language version is not supported by PostSharp. The latest supported version is 7.2. Using unsupported language version may result in a build failure or run-time errors. Please select the latest supported version in project properties or upgrade to a newer version of PostSharp.
1>"H:\ConsoleApp\ConsoleApp\ConsoleApp.csproj" (default target) (1) ->
1>(PostSharpCore target) ->
1> H:\ConsoleApp\packages\PostSharp.6.0.18\build\PostSharp.targets(149,5): warning : The selected CSharp language version is not supported by PostSharp. The latest supported version is 7.2. Using unsupported language version may result in a build failure or run-time errors. Please select the latest supported version in project properties or upgrade to a newer version of PostSharp.
1>
1> 1 Warning(s)
1> 0 Error(s)
1>
1>Time Elapsed 00:00:05.49
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

Provide enhanced support for the "current class logger" custom message logging idiom. Notably:

1. Remove the need to declare boilerplate like:

class Foo
{
static readonly Logger _logger = Logger.GetLogger( LoggingRoles.Custom, typeof( Foo ) );

void Bar()
{
_logger.Write( LogLevel.Debug, "Hello!" );
}
}

most likely by providing a class with static methods, for example:

class Foo
{
void Bar()
{
CurrentClassLogger.Write( LogLevel.Debug, "Hello!" );
}
}

2. Further to (1), honour the AllowDynamicEnabling=false configuration setting around invocations of current class logger logging methods.

3. Further to (2), to allow users to JIT-away blocks of code that are only used for diagnostic purposes, provide access to the static readonly bool for the current class logger, for each log level. For example:

/*
public static class CurrentClassLogger
{
...

public static readonly bool IsDebugEnabled;

...
}
*/

class Foo
{
void Bar()
{
if ( CurrentClassLogger.IsDebugEnabled )
{
// Compute some diagnostic statistics - maybe needs heap alloc etc.
var stats = ...;
CurrentClassLogger.Write( LogLevel.Debug, "Stats {0} more stats {1}", stats.X, stats.Y );
}
}
}

Currently, OnEntry etc are all void methods, meaning they're not inherently async friendly. It's becoming exceedingly rare to be able to write code without calling async methods these days, and it's more and more common to need to call async methods from within an OnMethodBoundary aspect (database or web service calls especially).

The naïve approach of simply changing the override signature to make the aspect async void in order to be able to await within the aspect has subtle issues which are not intuitive to debug.

Ideally, we'd have additional overrides available in OnMethodBoundaryAspect for Task OnEntryAsync and Task OnExitAsync so that we can await inside these aspects without risking unexpected behaviour.

I understand that at the IL level these are actually two separate types of injection, but I have on several occasions wished I could add a module initializer to an assembly from an aspect provider, not by marking an existing static member as one but by including the module initialization behavior in the aspect itself. Similarly, there are a few types which could have benefited from automatic introduction of static members (perhaps a new StaticTypeLevelAspect base class?). I imagine these are similar in some manner of abstract implementation detail, yet wind up being somewhat unrelated due to the way module initializers are implemented under the hood, but to me they have been related in their usefulness.

We often want to do something when a certain property value changes. Therefore, it will be very convenient if in the case of a value change, the PostSharp library will run a predefined function.

For example, in ViewModel there is a property named ProductId.

The programmer will be able to write a function called OnProductIdChanged that will be executed if the ProductId value changes.

How it will happen: When the value of a property changes, the PostSharp library checks whether there is a function named OnPropertyNameChanged. If it does, it will be executed.

This need is so common, and saves the need to subscribe to the PropertyChanged event at ViewModel.

Here is page https://www.postsharp.net/alternatives.

Here is column header
```
Niche Languages
F#, Erlang
```

I doubt Erlang relates to .NET as viable alternative at at all.
Niche Language which is Niche and is concurrent of Postsharp is https://github.com/rsdn/nemerle.

What `niche language` means?
F# may be `niche` as current number of users.
But F# is NOT Niche about its applicability. Its applicable in areas of scripting and tooling and data munging and secured engineering is LARGER than of C#. In this sense C# is `niche`.

About F#. Your statements are wrong and do you bad job advertising Postsharp product management of being unaware of alternative and telling falsehoods.

`Empowers every team member: architects, senior developers and application developers`. Operations, support, analysts, build engineers are not part of team?
F# empowers all parties you forgot to mention. More, F# empowers people because it is free.

`Makes source code semantically simpler and more concise`. Just Google it. F# does it much better then any amount of tooled C#.

`Improves architecture and makes application maintenance easier and less expensive `. Again F# does this and Google it.

No checked other statements lower in table, but there should be critique either.

If you do not want to look bad, drop Erlang. Change `niche` with specific language columns like `F# Language` `Nemerle language`