Custom UnityEngine.UI.dll shared across a team

Unity Engine
1

Hello all,

I currently am working on a project that require us to overwrite some of the default behaviour of the UI dll. (we have a custom way of handling colors among other things that use to make unity work better for us) So I made a clone of the Unity-UI bitbucket repo to make our few changes but still allows us to pull in the updates that Unity makes so that we can stay up to date with them as they make bug fixes, improvements, etc.

After doing that we set up some environment variables to make the .csproj file included in the UI repo to be able to build that and have it automatically update the dll in the Program File directory, per the comments in that project file.

I was curious if anyone has any luck or advice with sharing this changed dll across a team, most of whom wont be downloading or editing UI dll that I have created but do need it to update automatically on their local machine.

Some attempts at a solution

  1. We’ve tried putting the dll in the assets folder and this sort of works, however building fails because it then references the default dll in the program files and not the one in the project files which caused building to fail.

  2. We tried editing the .csproj files that are in the same level as the Assets folder but turns out unity doesnt actually use that and it is just for the visual studio/MonoDevelop compilation.

  3. We also are trying a solution in which we insert a process before calling the mono.exe that Unity uses to compile but haven’t got that working 100% yet.

Current solution:

The only solution we’ve found so far is to have a post update hook script on the local machine that copies over the dlls from the project folder (above the “Asset” directory so that unity doesnt try to include it in its build) into the program folder. (we are using SVN as our source repo)

All of these issues seem like a really complicated way to solve this problem when the majority of the stuff we do with Unity has been pretty straight forward

Anyone have any ideas or pointers to help us getting a more systemic solution that isnt quite as hacky?

Thanks,

Colton

2

First question, does it actually have to Override, or would it be easier to just build an extension method or build a duplicate class (modified) with a similar name?

For the UI dll’s to work properly, they have to be in the install folder for Unity (Unity\Editor\Data\UnityExtensions\Unity\GUISystem<version>) for the build, just using it as an asset wouldn’t work.

The simpler solution is to just make your own scripts with your own classes (either using existing controls as a base or copies with different names) or a script with extension methods to extend the base controls.

3

Override seemed like easiest due to the fact that we make some pretty low level changes and it would require us to duplicate a lot of the dll. (eg. we changed the m_Color variable to be a custom class that we created called UIColor which allows us to assign a Color type instead of an actual color, and then define those colors in a centralized place as to make color iterations a lot easier to do and make our color use consistent across the project). But after trying to get it to work across our entire team I’m not so sure.

Another reason I thought override would be easier is when the Unity devs release updates they also release them in bit bucket, so by cloning their repo we could then merge those into our branch as we wanted.

We did consider duplicating all the classes but it seemed like it would be more work in the long run and the risk of our dev’s using the unity classes instead of the custom ones seemed like a very big one that would have some hard to detect bugs since the majority of functionality would be exactly the same

Ideally I would love to be able to have a project setting that tells Unity to look for the DLL’s in a different spot but I’m beginning to see that isn’t exactly an option.

4

There was a little talk about extending the DLL location for the UI system, possibly extending the Module behaviour (In the Unity Module component), however nothing concrete was said.
Plus it might not happen to U5

Unity are aware of the limitations of deploying your own fixes at present and want to make it better.

For now, all we have are the patterns above.

5

Thanks for the info! I think we can make this work for now, just wanted to make sure I wasn’t missing something super simple before getting too far down the path with these hacky feeling solutions.

I just put in a feature request and if anyone else reading this post needs this as well you can vote for it at the link below.

http://feedback.unity3d.com/suggestions/extend-dll-location-of-ui-system-dlls

Colton