If "inherited generated classes" are eo custom classes that inherited efl classes, internal will occur compiler error.
e.g.

mcs -d:EFL_BETA -target:library -out:src/tests/efl_mono/efl_mono_test.dll -r:src/bindings/mono/efl_mono.dll src/tests/efl_mono/dummy_child.eo.cs src/tests/efl_mono/dummy_numberwrapper.eo.cs src/tests/efl_mono/dummy_test_object.eo.cs src/tests/efl_mono/dummy_test_iface.eo.cs src/tests/efl_mono/dummy_inherit_helper.eo.cs src/tests/efl_mono/dummy_inherit_iface.eo.cs src/tests/efl_mono/dummy_part_holder.eo.cs src/tests/efl_mono/dummy_event_manager.eo.cs src/tests/efl_mono/dummy_constructible_object.eo.cs
src/tests/efl_mono/dummy_part_holder.eo.cs(83,80): error CS0122: `Efl.PartConcrete.NativeMethods.efl_part_get_ptr' is inaccessible due to its protection level

With this patch

diff --git a/src/bin/eolian_mono/eolian/mono/function_definition.hh b/src/bin/eolian_mono/eolian/mono/function_definition.hh
index a0f28df..149272a 100644
--- a/src/bin/eolian_mono/eolian/mono/function_definition.hh
+++ b/src/bin/eolian_mono/eolian/mono/function_definition.hh
@@ -61,7 +61,7 @@ struct native_function_definition_generator
     if(!as_generator
        (
         indent << eolian_mono::marshall_annotation(true) << "\n"
-        << indent << "public delegate "
+        << indent << "internal delegate "
         << eolian_mono::marshall_type(true)
         << " "
         << string << "_api_delegate(" << (f.is_static ? "" : "System.IntPtr obj")
@@ -76,7 +76,7 @@ struct native_function_definition_generator

In T8162#141719, @Jaehyun_Cho wrote:

@lauromoura
It is confirmed that SA1402 is not mandatory but it is recommended.

Since SA1402 is problematic with eo and SA1402 requires additional effort, I think it would be better we do not apply SA1402 for now.

We focus on other mandatory rules and major issues and then we may consider SA1402 later when we are able to do it.

Resolved in D9816

@lauromoura
It is confirmed that SA1402 is not mandatory but it is recommended.

@lauromoura
I will ask the reporter who raised this issue in detail and I will let you know.

If actually needed, we could disable this rule for generated code and keep it only for the manual code.

In T8162#141476, @Jaehyun_Cho wrote:

@Jaehyun_Cho, what would be the reason for these requirements? (We're not questioning them, just trying to understand the issue better. :) )

The main reason is to make class name and cs file name same :)
As you know, efl_ui_layout.eo.cs contains class Layout in the namespace Efl and Ui.
Therefore, it was suggested that efl_ui_layout.eo.cs should be renamed to Layout.cs which is the same name with class Layout. And Layout.cs should be moved to Efl.Ui namespace directory to avoid duplicate cs file names.

This may be hard with meson. See my first comment on its limitations.

I totally understand. If it is hard on upstream with meson, then I consider that I run some script manually to generate directories and change the cs names only for Tizen.

In T8162#141471, @Jaehyun_Cho wrote:

@segfaultxavi
The main issues of this task are as follows.

1. All C# source files (.cs) should be located in the directory named fully-qualified namespace.
   • e.g. cs file for class Efl.A.cs should be located in directory Efl. This means that Efl/A.cs

@segfaultxavi
The main issues of this task are as follows.

Sorry I missed D9692, I've reverted ac99e2ac9410d5b2ef6225fa1aaaf9ffcd6578fb

For now, I've removed the underscore of Evt_Args by ac99e2ac9410d5b2ef6225fa1aaaf9ffcd6578fb

Can we change this task name?

In T8163#140968, @lauromoura wrote:

.... and there's talk of using C for classes ...

Is there? O_o

In T8163#140932, @segfaultxavi wrote:

Trying to automatically convert eo event names to verbs in the past tense is going to be an nightmare :)

In T8166#140933, @segfaultxavi wrote:

Just to be sure, we're talking about removing the I prefix from the EventArgs classes, no? This makes sense.

Just to be sure, we're talking about removing the I prefix from the EventArgs classes, no? This makes sense.

Trying to automatically convert eo event names to verbs in the past tense is going to be an nightmare :)
All events should already be like that (as shown in the list above), and the rest should be renamed in the eo file.

Would that be an option, @lauromoura? Are all users of these methods inside the same assembly?

You'd better use internal instead if you want to hide them.

In T8165#140891, @segfaultxavi wrote:

If a method is meant to be used only by derived classes, shouldn't it be protected? What am I missing?

I don't like hiding it from the editor since it won't show up for writers of derived classes.

If a method is meant to be used only by derived classes, shouldn't it be protected? What am I missing?

What's the issue with the current approach? it's not clear from the task description.

The interface name was added to the struct name in order to avoid collisions between event arg structures with the same name. Removing this prefix leads at least to the following clashes:

From C# guidelines in https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/names-of-type-members#names-of-events:

Here is a list of generated events from the C# files. (without the prefix).

We could try hiding them but AFAIR they should be public so inherited classes can use them.

Evt today comes from the name of the event. Related to T8163

This could be kinda tricky to do in a generic way. We may end up having to build a list of irregular verbs and their past tense in order to generate them.

We may encounter some difficulty generating the files in sub folders as a meson issue [1] limits the output of custom_target command to be placed in the same folder as it is called.

Good news! DocFX already filters out methods with the [EditorBrowsable(EditorBrowsableState.Never)] attribute :)
https://dotnet.github.io/docfx/tutorial/howto_filter_out_unwanted_apis_attributes.html#3-default-filter-configuration