Question Best practices for handling assets without assembly definitions?

Greetings devs,

I'm adding Unit Tests to my latest project which required me to add an assembly definition. This of course broke everything until I added assembly definition references to all the stuff I was pulling in.

The issue I have now is that one of the third party assets I'm using doesn't have an assembly definition. I can't just add an assembly definition for it because then my Unity Cloud Build will fail because when it pulls the package from the asset store it won't have the assembly definition.

Right now it's looking like my only option is to actually pull the code for the asset into my project. This just smells bad to me. For one thing I'm bloating my project with code that's not mine and also makes it difficult to pull any updates to that asset.

So, I'm asking the community, what is considered a best practice for handling this situation?

Thanks!

 

I am not familiar with Unity Cloud and how it handles Asset Store assets. But given the fact that cloud builds pull that asset into your project this cannot be any different from you downloading and installing that asset into your project. Your project apparently depends on it, thus it cannot build without it.

Which makes me wonder how are you able to locally run or build your project if the project depends on that asset but you don‘t have it installed in the local version of your project?

 

First, thanks for the reply.
Second, I don't think I communicated the problem very well so let me try to explain (and I'll take Unity Cloud Build out of the equation for simplicity):

• I installed a third-party asset from the asset store into my project.
• I added an assembly definition to my project and added asmdef references to the assets I use in my project.
• The third-party asset in question did not have an asmdef so I get build errors since I can't add it as a reference to my project.

What are my options to deal with this?

The only option occurring to me at present is to pull the code for the asset into my project (hence part of my project's assembly). I don't like this idea because I'm bloating my project with code that's not mine and will introduce difficulty pulling future updates for the asset.

How do others deal with this?

 

Your only option is to manually add an assembly definition for the third party asset. I‘ve done this often but it‘s far less frequent now since Unity for years now requires assets with scripts to use assembly definitions. Thus if you still use an asset without an asmdef it‘s likely that it has not been updated for a long time, or may be flying under the radar when it comes to store approval process.

Even if the asset is updated, the asmdef you created will continue to exist. Any new scripts will automatically be governed by the asmdef you created.

In any case, the third party asset is already part of your project. There is no additional bloat if you add an asmdef for it and reference that in your own asmdef. You literally NEED that asset for your code to work.

 

I think I'm missing something here. Assuming I keep my third-party assets outside my version-controlled project, where would I put the asmdef I create for the third-party asset? If it's on the third-party folder (which would get my local build working) how would this be picked up on any other machine I pull the repo to (including the cloud build) since it's not part of my repo?

 

Yeah, you do.

As a rule of thumb, a source repository must contain all files necessary to open and build the project. And that‘s not just for Unity, any project.

Since you don‘t keep the third party asset in your repo it‘s not part of the project and that is the problem. You HAVE to put it inside of your project‘s Assets folder and in your repository. Not doing that will cause issues.

For one, whenever you pull the project there is something missing: the third party asset. You may be able to download that from a certain location, but what if that link goes down? What if the asset gets updated and is no longer compatible with your project and you have no way of getting the older version? What if at some point in time you simply can‘t remember what the exact 3rd party asset version is that allows you to make a successful build?

You can still avoid keeping the asset in your projects repository by linking (git: submodule or subtree) the asset‘s repo into your own - this references a specific version of the asset unless you pull its changes into your project. If the asset does not have a compatible public repo, you can create one yourself.

 

Hmm, I've been doing enterprise software development for decades and Unity development for over 3 years and I've never committed third party assets to my repository. Package managers like Nuget, npm, etc. reference specific versions of packages and pull them from their respective sources at build time.

If you look at the build log from Unity Cloud Build you will see that one of the first things it does after pulling my code down from GitLab is to import whatever packages it needs.

The issue I'm encountering here is that the package isn't shipped with an assembly definition that I can reference. That seems like a one-off issue, not a "rule-of-thumb".

 

Sorry I forgot but of course NPM packages are another way to store external references in a way that the project remains in a workable state after you pull it because you can rely on downloading those assets from a trusted, managed external source.

In that case the issue needs to be fixed in the npm package ideally. Any chance the author could fix this? What package is this anyway?

I assume the package isn‘t a Unity Package Manager package (they need to have an asmdef) but some other npm system. I would try to pull that 3rdparty package into my own unity package as a wrapper and import the latter via Package Manager. To make this work with cloud builds you likely have to import it from a git url so that the cloud server can also pull it from git.

 

Okay, now I feel like an idiot. Yes, it's a Unity Asset Store package and it does in fact have an assembly definition. Apparently, I had deleted it at some point after pulling it in. I use Maintainer to clean my project of any unused components and I suspect that's what did it. I was looking at the package contents on the asset store page and see the asmdef.

 

Happens to all of us. Problem solved is what matters.