Define Constraints are not filtering plugins, PluginImporter.DefineConstraints also has no effect

Unity Engine
,
1

Hi there,

I’ve submitted a bug report with a simple reproduction project for this. I’m using Unity 2021.2.13, latest at time of writing, but this issue seems to have been a problem for a long time.

What’s happening is that if create a few packages, each with an assembly definition, as an example let’s say it’s a package per platform and I have three packages called: Steam, Epic, GOG, and there are native SDK plugins for each platform added to each package (a very common use case). If I then set a Define Constraint for each package to: STEAM, EPIC, or GOG, and then compile out the app with none of these symbols set in the compiler symbols what I would expect to happen is that none of these packages are compiled and none of the native plugins would be bundled with the my app, except they are, all plugins are ‘infecting’ our builds. This is cause for a certification failure on some platforms.

I looked into further setting a define contraint per plugin using PluginImporter.DefineContstraints, this also has no effect, all plugins still end up in every build that the native plugins support.

I’ve submitted a simple reproduction project and bug report under issue number: 1405720

How are we meant to filter plugins from ending up in builds they don’t belong to? It’s not a decent enough workaround to be adding an removing packages or to deleting plugins before and after every build, everything else about the package is filtered with the define contraints why aren’t the plugins? it’s as though when the compiler looks for plugins it ‘only’ looks at the plugins platform inclusions and does not look at the define contraints at all. Other assets, scripts and such are filtered with the define constraint, it seems to be just plugins that are not being treated as you would expect.

Thanks.

2 Likes
2

Any thoughts on this topic from Unity? it seems like this is a pretty glaring issue, it’s making it pretty hard for us to make a robust compiler system to handle all of the different platforms and plugins we need to support, thanks.

1 Like
3

sorry to bump, it’s been two weeks and no response from the bug report or forum topic… and was hoping to get some sort of conversation going about this topic or any thoughts on how to work around this issue, thanks

1 Like
4

I ended up getting a reply from support that while this issue has been acknowledged, this was their answer:

But the problem is, when I follow the breadcrumbs on this, the plugin importer callbacks do not work when script compiling which I have to use ie. the callbacks only work when using Build & Run which any serious compiler setup can not use. So there is currently no way for us to filter native plugins from builds, we have to roll our own solution. It find it very frustrating that this problem has not been solved yet, as it would come up for just about any developer supporting multiple platforms, many many hours wasted by a lot of people to come up with their own solutions.

1 Like
5

I tired to find some example implementation and found this is where I should set the delegate:

That the delegate is called by:

And according to this Unity developer answer the callback does not work for script compilation:

6

Thanks a lot for this. I had same issue with managed plugin and this saved me.

I had to register multiple IShouldIncludeInBuildCallback because Unity failed to write correct regex on package name. They do this regex on package path, Regex.Match(packagePath, "\\/(.*)\\/").Groups[1].Value which make them get “com.company.package/Sub/Directory”, not actual package name. Seriously, Unity? So I had to register for each sub directory that contains dll.

And also note that the package path given to callback is absolute path which will depends on your project and package path on the file system.

This is the part of Unity’s code that has issue:

And this is the code that worked for me: