Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement AOP at IL level (like PostSharp) #7300

Closed
vbcodec opened this issue Dec 7, 2015 · 5 comments
Closed

Implement AOP at IL level (like PostSharp) #7300

vbcodec opened this issue Dec 7, 2015 · 5 comments
Labels
Area-External Discussion Resolution-External The behavior lies outside the functionality covered by this repository

Comments

@vbcodec
Copy link

vbcodec commented Dec 7, 2015

There are two proposals to implement AOP like #5561 and #5292. First proposal operates on Roslyn level, and require access to AST and/or generating code as string. This way is very messy and look like workaround than solution. Certainly, this is not what average coders want from AOP. Second proposal that use superseding is better, but require language improvement and there are issues how to implement it in right way.
Unfortunately, both proposals are overkill and have shortcomings compared to IL - level. Implementing AOP as IL codegen, do not require heavy Roslyn improvements, nor language changes (with fear of polluting language with non mature specific concept), and have very big advantage - ability to handle members that exist in libraries. This - IL - way is enough for most scenarios, simply to understand and use. Extensions and other features work in this way, and work very well.

@MgSam
Copy link

MgSam commented Dec 7, 2015

Those proposals are complementary, not alternatives. IL codegen is extremely messy and means that you have no way to verify what the behavior of your code is until runtime (or by inspecting the re-written IL). The proposals you mention neatly deal with that issue by making the injected code available for perusal at design time.

@tmat
Copy link
Member

tmat commented Dec 7, 2015

One of the big problems with IL rewriting is that is degrades debugging experience. The rewriter generally doesn't have enough information (which is only present in source) to produce the correct debugging information.

@gafter
Copy link
Member

gafter commented Dec 8, 2015

This is kind of out-of-scope for Roslyn, which is a compiler and language analysis framework for C# and VB.

@Inverness
Copy link

I've been working on a project using Fody as a way of achieving AOP with IL weaving.

Fody basically sets up a system that lets you easily utilize IL weaving libraries at build time. Mono.Cecil is used to edit the assemblies and preserve debugging information.

I don't think is something Roslyn needs to handle.

@m0sa
Copy link

m0sa commented Mar 11, 2016

Still, CSharpCompilation.Emit is very closed down. It would be great if there would be an extension point to hook into the process of creating IL and pdb.

@gafter gafter added the Resolution-External The behavior lies outside the functionality covered by this repository label Mar 24, 2016
@gafter gafter closed this as completed Mar 24, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-External Discussion Resolution-External The behavior lies outside the functionality covered by this repository
Projects
None yet
Development

No branches or pull requests

7 participants