Ensuring API Compatibility Level

I’m currently working on a plugin/package that relies on the .NET 2.0 API Compatibility Level due to some scripts using System.IO. Are there any known import hooks I can wire into to change these settings?

Upon import, if the API Level is not changed from 2.0 Subset to 2.0, there is a weird compiler error (it looks like type exceptions embedded into one long nasty string of nonsense, not the usual typedef error, or any standard Unity error for that matter). This error goes away after switching API level and letting Unity finish the import process.

I have tried to tie into the AssetPostprocesser callbacks (like OnPreProcessModel), which changes the level when my scripts are not present, but that is not a workable solution, since I need those scripts.

I have 2 partial solutions that aren’t as elegant as I would like.

1: include Player Settings in the package (but I don’t want to overwrite all of the other settings for the existing project)

2: Include an embedded .unitypackage with the troubled scripts and have the setting flagged and the package auto-import using the AssetPostprocessor.OnPostprocessAllAssets hook. I can easily automate the packaging process, but this seems like a hack to me.

Anyone else face this or have better ideas than the ones I’ve posted?

Thank you!!

I don’t think any developer wants his API level to be changed behind his back. The subset is smaller and in general especially mobile developers strive for a small binary. You should wrap the code needing the full set into the compiler directive #if NET_2_0.
Other than that you could inform the user via pop-up that for the full feature set to work, he needs to switch it.