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

Exclude types and methods by name #3

Open
CptMoore opened this issue Oct 15, 2022 · 4 comments
Open

Exclude types and methods by name #3

CptMoore opened this issue Oct 15, 2022 · 4 comments
Labels
enhancement New feature or request

Comments

@CptMoore
Copy link

CptMoore commented Oct 15, 2022

It would be nice to define a list of types NOT to publicize. In our case (BattleTech modding) it seems inheriting from publicized classes will crash ins some cases, so it would be nice to avoid certain types if a mod inherits from the type.

We would need it as part of the msbuild options as requested in #2

@js6pak
Copy link
Member

js6pak commented Oct 16, 2022

While excluding is something I'd want to implement, inheriting causing crashes sounds like a bug, could you send the dll you are trying to publicize and the type name thats causing the crash?

@CptMoore
Copy link
Author

Access checks are still being done by non-unsafe assemblies. When inheriting virtual methods that are originally protected and newly are public due to the compiler compiling it as public, non-unsafe assemblies will error out when calling the method.

Cant remember if unsafe even suppressed the error/crash, but the changing method visibility in child classes was the issue.

An idea would be to un-publicize the affected methods during publishing in the new child classes. Might not even work.

Another (what our community currently uses) is to inherit in library projects that access the non-publizised variant. By excluding the type, this workaround is easier in some cases.

@js6pak
Copy link
Member

js6pak commented Oct 18, 2022

Access checks are still being done by non-unsafe assemblies

That's why AssemblyPublicizer.MSBuild sets AllowUnsafeBlocks for mono and IgnoresAccessChecksTos for coreclr

Unless you mean the check failing in a "safe" assembly that's referencing an unsafe assembly that uses a publicized assembly, but I can't think of a case where it would actually crash?

but the changing method visibility in child classes was the issue.

Seems like I can't reproduce, could you share an example that actually crashes?

@js6pak js6pak added the enhancement New feature or request label Oct 18, 2022
@CptMoore
Copy link
Author

Seems like I can't reproduce

I couldn't reproduce it either since I don't work as deep with the code as the guy who wished for this feature. He said he had random crashes. The last time he tried the crashy solution was some time ago.

When I was trying to reproduce the issue within a more limited scope, the only difference between non-publicized and publicized cases was the member visibility in the child classes IL code. I assumed that this must be the main cause of crashing on the mods side.

Unless you mean the check failing

First sorry for my wording. With access checks I also meant things like reflection and visibility flags or even other things that exist (don't know how Unity finds methods etc..) With non-unsafe I actually meant non-mod / non-modified assemblies.

More information, still rather vague about the issue, again sorry:

Its actually Kmission (Cmission), a battletech modder reachable via RT Discord who has this issue and requested the exclusion feature from our own Assembly Publicizer (which will go away thx to the msbuild solution here)

His mods (e.g. https://github.com/BattletechModders/CustomAmmoCategories ) inherit from the games assembly classes:

ObjectSpawnData, WeaponEffect, MechRepresentation, Mech, SelectionStateCommandTargetSinglePoint, SelectionStateConfirm

Of which MechRepresentation inherits from a Unity class (MonoBehaviour). Some classes have a rather shallow inheritance hierarchy, others have deeper ones.

He tried the publicized inheriting, but just couldn't get rid of the random crashing. It only went away once he stopped inheriting from publicized classes, or more precisely, only inherit from non-publicized classes. He split his code into several libraries to make part of his code still benefit from publicized assemblies.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants