Feature Request: Report potential accessibility issues in run-time code referred to in templates

[WhitWaldo]

For testing purposes, I've got my aspect and its related classes in one project, some dummy entities in another project and my unit tests in a third project. I was trying to work through some build errors I'd seen on my dummy entities after setting the configuration manager to LamaDebug and noticed that I have a bunch of errors along the lines of "LAMA06' Error CS0122 in code generated by aspect 'MyAspect': 'XYZ' is inaccessible due to its protection level".

After poking at this a bit, it's spot-on - because my entities are in a separate project, they don't have access to methods marked as internal in my aspects project.

I would propose one of two paths forward. If a project containing a Metalama project points to a run-time field, property or method marked as anything other than public as part of building out whatever it's doing: 1) It throws a build error indicating that because of the protection level applied to whatever it's named, this will result in downstream runtime errors 2) It automatically change the visibility of the offending field, property or method to public so that at run-time in the other project, it will be available and show a build warning indicating that this was done

Thank you for the consideration!

[PostSharpBot]

Hello @WhitWaldo, thank you for submitting this issue. We will try to get back to you as soon as possible. Note to the PostSharp team, this ticket is being tracked in our dashboard under ID TP-33603.

[gfraiteur]

I like your first proposal best because automatically changing stuff is generally a recipe for mess and failure.

[gfraiteur]

I'm closing this feature request as declined because it goes against our design philosophy.

We don't attempt to have completely "fool-proof" aspects at the moment; we allow aspect authors to make errors, which will result in invalid C# code being generated. However, we ensured that the C# error messages blame the proper aspect.

We are taking this approach because there are many cases where we cannot enforce code validity. These cases are:

• dynamic member references
• Use of ExpressionBuilder or similar classes
• Dynamic implementation of interfaces (new in 2024.2)

When a rule is not enforceable without undermining the framework's usability, we prefer not to enforce this rule at all.

Therefore there's little chance that we are going to look at features like the one proposed in this ticket.