Support for InitializerKind.AfterLastInstanceConstructor

[batzen]

Hi there,

is there any ETA when InitializerKind.AfterLastInstanceConstructor will be available or any advide for an alternative?

I would really like to move forward with migrating from PostSharp to Metalama, but without being able to inject code after the last instance ctor that's not possible for us.

[gfraiteur]

Unfortunately, the feature is not planned at the moment -- neither 2023.4 nor 2024.0. This is a non-trivial one.
We take note of your interest in the feature, however.

[batzen]

@gfraiteur that's sad to hear.
Do you have any suggestions for an alternative way to achieve safe initialization after running the called ctor?
PostSharp solved it by adding new ctor overloads containing the current ctor level.

[gfraiteur]

I don't know any other viable solution than these clumsy constructor overloads that PostSharp did. I guess we'll have to implement the same strategy in Metalama but currently the aspects we're busy with, caching and INPC, don't necessitate it.

[batzen]

That's very sad to hear as it will block us completely from migrating.

[batzen]

@gfraiteur I was able to implement it on my own.
I am a bit surprised that i was able to implement it in less than a working day and yet it's not on your roadmap. ;-)
And i am surprised how easy Metalama makes it to do such things in ~200 lines of code. ;-)
However there are a few issues i encountered, which i consider bugs in Metalama.
My solution uses a custom weaver combined with an aspect.

I am using version 2023.2.5

1. As soon as i reference the custom weaver project Metalama stops adding totally unrelated advices to totally unrelated classes that inherit from classes that have inherited aspects (so the advices work for the base class but not for derived classes)
2. Trying to override methods introduced by aspects does not work as the compiler doesn't see them
3. Debugging code that was changed/enhanced by Metalama is not possible when just setting breakpoints in the original code
4. Compiler errors, even when they are not caused by generated code, show the changed file which has a very high risk of changing the generated file, not noticing that and loosing all code changes during the next compile

Not sure if you are aware of all those issues and if it's ok to just write it here or if i should create separate issues for each.

[gfraiteur]

Glad to hear you found your way. I didn't think of the possibility of using Metalama SDK for this. But yes, indeed, you can do anything with the SDK. Things are much harder for us to implement "the right way" in the high-level framework, and we have to integrate this with a bundle of other constructor-related features.

• If you're using Metalama SDK, you should rather use v2023.3 because we have streamlined and fixed the SDK in this version.
• In general, the combined use of aspect weavers with normal aspects is poorly tested. We consider the SDK either a "geek-only" interface or an "emergency-only" toolkit, but it's not something we generally recommend to use for serious business. Hence, my omission in my initial reply that using the SDK may be a possible solution.

Trying to override methods introduced by aspects does not work, as the compiler doesn't see them.

What do you mean exactly? You should be able to override methods introduced by aspects.

Debugging code that was changed/enhanced by Metalama is not possible when just setting breakpoints in the original code

It should also work but only if you debug the source code. If you debug the transformed code (using the LamaDebug configuration), source-code breakpoints will not work because the PDB maps the IL code to the transformed code.

Compiler errors, even when they are not caused by generated code, show the changed file which has a very high risk of changing the generated file, not noticing that and loosing all code changes during the next compile.

I don't understand this point. Could you rephrase.

i should create separate issues for each.

Yes, it's better to create different conversations for each issue.

[batzen]

Ah, the debugging and compiler errors pointing to the generated files were because i used LamaDebug.

The "override methods introduced by aspects" issue also resolved itself as i made the mistake of trying to use "override" directly on the class that was changed by the aspect. Overriding there makes, of course no sense and is invalid code.

So the only remaining issues are that intellisense/design time stops working when introducing new attributes at the assembly level and that using a weaver causes inherited aspects to stop working.

Will create issues for those as soon as i find some time to build repros.

[gfraiteur]

Thank you for the feedback.

Note that the design-time issues with weavers are "by design" at the moment and we will not be able to work on this during upcoming weeks.

[batzen]

The weaver doesn't cause the design time issue.
A regular aspect that introduces attributes at the assembly level causes those issues.

[gfraiteur]

Please open a separate ticket for the design-time issue.