In the project I’m working on, I’ve been distributing my Unity C# scripts as managed plugins. It’s worked well in that it allows me to distribute fewer, thematically organized assets that are easier for users to manage. However, the system I’ve implemented involves using an external Visual Studio project to compile the scripts and import (copy) them into a Unity project I use for testing and to build the distribution package.
I’d like to get rid of the separate VS compilation project and use the new 2017.3 Assembly Definition Files break my project into modules. But, I’d still like to distribute those scripts as compiled plugins in a package, rather than source C# files.
Is there a clever way to do such a thing? Basically, I’d like to build and test with the source files, but distribute the compiles assemblies and plugins in the package I build. I’m concerned about…
- Needing both source C# and the resultant assemblies in the asset database to build the package
- (Name clashes if both are part of database)
- Id’s (and metafiles) referenced in prefabs and scenes. Eg. if I test with individual source files, with the asset matchup if they’re distributed in a plugin.
Any thoughts?
Mike
If I understood correctly, you want to ditch the “custom DLL code for Unity” Visual Studio projects and replace them with code in Unity and an .asmdef alongside it.
One thing you could try real quick is to just copy the resulting assembly from your project’s “Library/ScriptAssemblies” folder and stick it to a new Unity project and see if that works. It may work, or you may get issues like “assembly not signed” or something along the lines that might indicate that the assembly is not standalone, ie it requires something else from your build project.
In the latter case you’re better off sticking to the existing workflow. After all I can’t see much of a gain here, perhaps a little convenience but whether you hit “Build” in VS (with a post-build event that automatically copies your DLLs to the project of course) and then switch to Unity (which will reload your assemblies real quick), or whether you just tab from VS to Unity and wait for it to compile the changed code is not going to make much of a difference to your workflow.
Building the .unitypackage will be the same process in both cases.
Unless I missed something?
I prefer to distribute the scripts as plugins for configuration management reasons. It’s significantly fewer assets (a half dozen vs. a few hundred) and it guarantees that all the scripts in the assembly were built and tested together. The project is an internal toolkit in my organization and plugins ensure that people use the external interfaces as they were intended and don’t modify the source. (Basically, encapsulation and information hiding.) And, I’ve had far fewer incidents of people trashing their projects by trashing meta files.
The development process is no different from a “regular” unity developer from an external point of view. The plugin VS project does exactly what you suggest in copying the resultant assemblies back into the test and distribution Unity project, which detects the change and re-imports them automatically. As the meta files don’t change, script references from the plugin continue to work.
Assemblies built by the editor with ADFs can be imported like any other plugin. The goal is to have a single Unity project to develop code and assets, but to deploy the pre-compiled assembly vs. the script source. Script references in scenes and prefabs won’t resolve to the deployed assembly if they used with original source (different assets).
Probably not something that can be done easily. Just thought someone with a better knowledge of Unity internals might have an idea.
Thanks for the thoughts.