[Improvement] Unnecessary DLL in Build output

[Fijo]

I'm using this library via openupm in my game and am quite happy with being able to do that. There is however one thing that bugs me a little: I can't prevent the NaughtyAttributes.Test.dll from landing in the build output of my game even though I'm never using any of it. It's only required for the Samples which I am not using.

I briefly tried to fix this using either checkboxes within the "NaughtyAttributes.Test"-AssemblyDefinition or moving the sources to the sample folder. I didn't manage to solve it doing that and that's why I decided to open this Issue instead of just creating a PR.

[dbrizov]

Just made a build, and it's really going into the build. I need to see why.

[dbrizov]

If I mark the NaughtyAttributes.Test.asmdef as an Editor .dll, then it doesn't go into the build. However, in this case the test scripts don't work, because I can't attach them to game objects. What bugs me is that the .dll goes into the build even if nothing is referencing it. The other solution is to not include the Test folder into the plugin, but then the samples scene will be gone, and I don't want to do that. If you want to get rid of the .dll in the builds that badly, I guess your only option is to download the plugin via the Asset Store, and delete the Test folder.

[rhys-vdw]

There is a solution that achieves what you want: Tag the GameObjects as "EditorOnly" and then you can attach MonoBehaviours from the editor asmdef. You can apply this tag to every object in the sample scene.

Edit: Just tried checking out the project and testing it and it seems that this feature is broken in 2021.1.20f, despite working as advertised in 2020.3. I've responded to the forum thread above so I'll keep an eye on it for fixes.

Can I request this issue is reopened as there is a potential solution? I will report back with updates and we can close if it's a dead end.

Turns out I misread that thread, as well as made a mistake when testing it. It's not a viable solution.

[rhys-vdw]

I found a nice solution though that supports distributing the test scene as well as convenient editing when working with this project directly. See #288

[rhys-vdw]

@dbrizov would you be open to an amended upm release action that renames Samples to Samples~ just in the upm branch? I feel like that's probably the cleanest solution, allowing users to import them into their project to play around but not including it in builds by default.

[dbrizov]

@rhys-vdw If I rename it to Samples~, people won't be able to see them in the editor when they import them. I want to try a different solution. Check this #291

[rhys-vdw]

So a common pattern is to rename to Samples~ only in the release branch (upm branch). That way when you clone the repository it's all there. When you import the project from upm, unity adds a button in the package manager to import the samples into your project if you want them (even if the folder is suffixed with ~).

See favoyang's explanation:

One solution is that keep the folder Samples in version control while using a CI to rename it to Samples~. Your package.json shall remain no change.

This seems like the perfect solution for NA. it would just be a small change to your release action.

Stripping the attributes from the build #291 seems sensible too, but that's separate from the test assembly if I understand correctly.

[rhys-vdw]

Example from 2D Pixel Perfect Camera