Introduce full scope AOP to C#

[akovac35]

Dear community, I would like to suggest introducing AOP to C# again. While this was attempted several times in the past, it does not seem to have caught the interest of the decision makers; and let's face it, it would be expansive both to produce and maintain. But perhaps this time we can muster a few compelling reasons:

• about using an existing library; libraries come and go, as do their developers. Language features are "forever". Would you risk using a library for a core solution component in your medium size project? What about a project where huge damages may be involved - would you rather rely only on Microsoft to be able to support your core component?
• an AOP extension library and .NET framework are developed in cycles; first, there is a .NET framework update, followed by a month or more for an AOP extension library to support new framework updates, followed again by .NET framework update sometimes later. Can you afford to wait a month or more for a critical production fix if your core component is based on an AOP extension library which does not yet support the .NET framework update that you require to fix a production problem?
• there is no doubt AOP features make a language more expressive and developers more productive. the following is an easy example of what is possible: https://github.com/akovac35/enterprise-aspects
  Advanced samples are available here:

1. https://www.eclipse.org/aspectj/doc/released/adk15notebook/index.html
2. AspectJ in Action: Enterprise AOP with Spring Applications Second Edition Series: In Action Paperback: 568 pages Publisher: Manning Publications; Second edition (October 8, 2009) Language: English ISBN-10: 1933988053 ISBN-13: 978-1933988054

• regarding implementation details, Java AspectJ can be used as the design and implementation example, both regarding compile time / run-time weaving and regarding language syntax elements. Eclipse plugins for AspectJ can be used for understanding debugging requirements,
• I know that at least one major IBM enterprise product uses AOP internally (IBM Business Automation Workflow), and the reason for using it is that software complexity is much lower and productivity higher because of using AOP. The drawback is that if AOP is not a language feature, you are finished when library is not supported anymore - even if you buy it, that may not be enough to sustain the company and developers behind the library (though there is always an option to hire them).

Granted it might not be obvious on the first glance how such a feature may be useful, but that is simply because most developers are not used of thinking the AOP way (and that simply because most programming languages don't implement it). Take a look at the provided examples and it should become clear just what is possible with AOP. AspectJ can be used as an implementation example and something to improve upon.

Having AOP directly in C# would certainly make .NET even more appealing for new enterprise applications as well as for migrating existing ones. While .NET is already moving where Java once stood, to replace Java entirely it will also need to have a (better) AOP.

[DaZombieKiller]

This currently feels more like a marketing blurb than a full proposal, how would you suggest that this be implemented in C#? Are there any syntactic advantages to this being a language feature over a library (or part of corefx)? Do you have any code examples that show how this could help you write better code? I'm just having trouble personally understanding the value of this without more information.

[HaloFour]

#107

This isn't a competition. C# isn't going to rush a feature in order to try to be first to market. That's an almost guaranteed way to make mistakes.

[dsaf]

• ...Language features are "forever"...

That is a reason to be very conservative.

Having AOP directly in C# would certainly make .NET even more appealing for new enterprise applications as well as for migrating existing ones.

Enterprise developers is not the crowd Microsoft is trying to please these days.

[MgSam]

• ...Language features are "forever"...

That is a reason to be very conservative.

Having AOP directly in C# would certainly make .NET even more appealing for new enterprise applications as well as for migrating existing ones.

Enterprise developers is not the crowd Microsoft is trying to please these days.

True. And ironic, given that the overwhelming majority of their revenue comes from enterprises.