UI

What happend to unity UI in 2019.14. Did you completely remove unity.UI in version 14?

 

What are you talking about? Everything is working.

 

I am talking about unity.UI in 2019.2.014a

 

Do you mean UnityEngine.UI? Do you have compilation errors?

 

It seemed like they completely removed it

 

I am on 2.0b1 - It disappeared for me too. Added the package, still no UnityEngine.UI namespace. Quick actions recommends UnityEngine.UIElements, but that's not the same Buttons have no onClick and InputField isn't there.

EDIT (Solved): Had to add the Unity.ugui to my ASMDEF file too.

 

I'm Unity asset developer.
When the basic functionality is packaged, I just need to create an asset package for each Unity version just to add the dependency package to asmdef.
I want to configure asmdef per Unity version.

For example:

Code (csharp):

1.  
2. {
3.     "name" : "MyAsset",
4.     "references" : [
5.         "MyAssetCore"
6.     ],
7.     "unity_2019_2_or_newer" : {
8.         "references": [ // Proposal 1 : Overwrite
9.             "MyAssetCore",
10.             "Unity.ugui"
11.         ]
12.         "add_references" : [ // Proposal 2 : Add to default settings
13.             "Unity.ugui"
14.         ]
15.     }
16. }
17.  

 

Hey @karl_jones, there should definitely be more documentation about this change and the manual work required.
I needed to add Unity.ugui as asmdef reference manually to all DLLs in my project that are referencing UnityEngine.UI.

(which, by the way, is harder than it should be because it seems assembly definition references can't be drag-dropped from a package (Unity UI) to a project DLL)

Isn't that something that you could at least try to auto-assign on import?

 

We have a plugin that references the UnityEngine.UI unity extension.

Is there any way to have a plugin reference a package?

 

I updated the editor to version 2019.2.0b1( last 2019.2a14):

Code (CSharp):

1. Assets\Scripts\UI\DialogController.cs(5,19): error CS0234: The type or namespace name 'UI' does not exist in the namespace 'UnityEngine' (are you missing an assembly reference?)

I can not find Ugui in the list of packages.

 

There is no such item in the list.

The package is not listed, but it is installed. I added it to the assembly definition and errors disappeared. But Unity UI did not appear on the list.

 

I'm having issues with using Unity Purchashing (IAP), stores.dll cannot find UnityEngine.UI because of the new package manager changes.

Could not load signature of UnityEngine.Purchasing.UIFakeStore:GetOkayButton due to: Could not load file or assembly 'UnityEngine.UI, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. assembly:UnityEngine.UI, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null type:<unknown type> member:(null) signature:<none>

Any way to fix this issue?

 

I guess you have to get the scripts to compile again before Package Manager updates itself. When upgrading to Unity 2019.1 I had this issue with VFX graph relying on Timeline which became a package and also for UNet stuff.

 

This change breaks every single DLL that has a dependency on UnityEngine.UI.dll. This means a lot of assets, including Rewired, now have to release a new branch for 2019.2 separate from 2019.1 to get around this. Leaving the dll name UnityEngine.UI.dll instead of changing it to Unity.ugui.dll would avoid this major breaking change.

 

Currently, built-in packaging affects many assets.
Could you add a parameter like

"plugins": true

to your Unity UI package so that it can be targeted by Auto Referenced?

 

OK, but the big question is: what do we need to do now in order to build our DLLs (that is, without relying on asmdefs) when they had a reference to the good old UnityEngine.UI.dll?

For Unity 2019.1 the references in my build script (which basically calls mcs to compile a pair of DLLs) are: <Unity-app>/Contents/Managed/UnityEngine.dll and <Unity-app-path>/Contents/UnityExtensions/Unity/
/GUISystem/UnityEngine.UI.dll but this no longer works for Unity 2019.2b1...

If I replace the problematic reference in my build script with <project-path>\Library\ScriptAssemblies\Unity.ugui.dll (as suggested by @guavaman) I get a lot of errors like:

• error CS0012: The type `UnityEngine.MonoBehaviour' is defined in an assembly that is not referenced. Consider adding a reference to assembly `UnityEngine.CoreModule, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'
• error CS0012: The type `UnityEngine.ICanvasRaycastFilter' is defined in an assembly that is not referenced. Consider adding a reference to assembly `UnityEngine.UIModule, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'
• error CS0012: The type `System.IEquatable`1<UnityEngine.UI.ColorBlock>' is defined in an assembly that is not referenced. Consider adding a reference to assembly `netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'
• error CS0012: The type `System.Enum' is defined in an assembly that is not referenced. Consider adding a reference to assembly `netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'
• etc...

And if I try adding a reference to the UnityEngine.CoreModule as suggested, then I get a lot of these:

• error CS0433: The imported type `UnityEngine.MonoBehaviour' is defined multiple times
• error CS0433: The imported type `UnityEngine.ScriptableObject' is defined multiple times
• error CS0433: The imported type `UnityEngine.Object' is defined multiple times
• etc...

Removing the original reference to UnityEngine.dll to avoid the re-definition? Nope, that means even more errors...

So, can you please explain how to do this? I need to build my own DLLs because that's how I distribute my editor extension since 2015.

 

Having the same issue with the SteamVR plugin after updating to this beta, all references to UnityEngine.UI break!

 

So i dont have answers for you right now. The DLL issue is defiantly something we overlooked. We realized our mistake and are working to come up with a solution that will minimize and issues though still unsure what that will look like. Once we have something we will let you know.

 

I hadn't actually tested it. I just assumed it work work. Good to know it doesn't.

 

You get the "defined multiple times" error because most probably you are referencing monolithic UnityEngine dll which is packed with all the modules. Unity moved to package-based dll's a while ago, you should remove the reference to the monolith, and include individual packages that you need.

Your initial approach was correct, just remove the reference to monolith.

 

Yes, that is exactly the reason.

I tried that but in my case (a large code base covering a lot of Unity modules) it is not as easy as manually adding the references to a few individual packages. That's why I was asking if there was a proper (and easier) way of doing this.

After some study -I confess I knew nothing about asmdefs- I found an apparently working solution to build the DLLs from a custom build script:

1. Add an assembly definition file to your source folder and configure the reference to the new UI package (Unity.ugui).
2. Let Unity create the corresponding .csproj file for the defined assembly (Assets > Open C# Project menu option).
3. This .csproj will contain every reference you need, so you can now call msbuild <csproj-file> from your build script to build the DLL.

The default output dir will be <project>/Temp/bin/Debug/ but this can be changed by adding -p:OutDir=<output-path> argument when invoking msbuild.

I hope this can be useful to someone else. In my case it matters because my project has some special build requirements. For "normal" projects you will probably be good just by relying on a properly configured asmdef and the generated DLL in <project>/Library/ScriptAssemblies.

 

So as promised about keeping you guys in the loop i'll tell you our current plan of action which is two step that will happen at the same time.

1) We will break our package naming consistency and rename the package to be UnityEngine.UI. This will allow unity to compile the package as UnityEngine.UI.dll so any prebuilt assemblies will continue to work.

2) For 19.2 we will automatically compile asmdefs with the UI reference. This way there shouldn't be a need to manually add the reference yourself. For 19.3+ we are hoping to have a more robust system in place but we are still unsure what this will look like.

For timing, we are hoping to get this completed end of next week (Holidays/ training for required team members has pushed the fix back) though that is if nothing else comes up in the mean time. i *think* this means it will land b3, maybe b4 for 19.2.

 

Thanks, phil!
Do you have n migration path for _xeleh_'s use case above? Building a plugin DLL referencing the UnityEngine.UI.dll package?
Up until 2019.2.0a14 I could build our plugin solution, referencing the monolithic UnityEngine.dll and the old UnityEngine.UI.dll (and my understanding was that plugin solutions /should/ in fact reference the monolithic DLL).

 

So i have heard back from one of our scripting guys about the proper process.

"The user should reference the .dll that Unity builds and the `UnityEngine.*Module.dll` that are are required, which I think are the same ones as the one the uGUI .asmdef depends on and you have to add to Unity package manager when referencing uGUI package. Unity .asmdefs are built against the `UnityEngine.*Module.dll` and any precompiled assembly that reference .asmdef built assemblies must also reference them."

`UnityEngine.*Module.dlls` reference modules like `UnityEngine.CoreModule.dll`, or `UnityEngine.AnimationModule.dll`, ect. They way _xeleh_'s did it where he let Unity set up the csproj might be the easiest to not miss any required.

 

Just in case you still need help with this, since I just had to go through the same thing and luckily found this thread straight away:

Go into SteamVR folder in your project asset browser
Click on SteamVR.asmdef
In the inspector, press the plus icon in the Assembly Definition References section
Now you have a new empty slot there, press the select icon next to it and choose Unity.ugui
Press the apply button
Various things should now compile and the SteamVR window appears.

Dont ask me if everything actually works after this step, or if I did everything correctly, I just got that far and thought I would let you know. Its been some years since I used the SteamVR plugin so I'm very rusty, just getting back into it now!

 

Is this fixed in b3? It's not obvious from the release notes.

 

No this did not land in b3. We are still working on getting the fix through the pipeline. We are looking at it being finalized end of the week and thus into release next week or the week after.

 

Thanks for this, as I'm a bit of an amateur programmer, sometimes something as simple as searching for an renaming references goes over my head. It sure isn't a long-term fix but fine for now, thanks

 

@phil-Unity - Is this issue fixed in beta 4?

 

Hey unfortunately no currently according to release management its on target for b6. Its later then i would have liked but got the other part of the fix from a colleague Monday and have hit some regressions in our test suite that needed resolved so missed the cut off which was Tuesday for b5.

 

@phil-Unity - When will the fix for precompiled assemblies get included in the 2019.3 alpha?

 

It has landed and is marked for the a6 release.

 

Fix confirmed? Does Rewired work now?

 

Hello,
It seems the problem is still there in b6, when will it be fixed for the beta releases?
Thanks
@phil-Unity

 

What seems to be the issue with b6? It should be fixed in that version

 

Thank you for fixing this. I've seen few some warnings/errors about it too but editor restarts + asmdef reimport/recompilation solved that.

 

Yeah there is one other fix on the way around first import of a dll. The validator is too aggressive and says a reference isnt there when it is (compilation order issue). Just ignoring it should also be ok but a reimport works as well. That fix will land at some point but no definite timeline yet.

 

Thanks for the quick replies. In fact I was in the situation that andrew-lukasik described, so there is no problems, sorry.

 

Dont be sorry if anything i should be sorry as I hadn't noticed the error due to it being already fixed in 19.3 so where i tested the fixes it was fine. When backporting i didnt do a new project just downgraded the other that has already built the UI dll. Glad it worked out. And yeah the initial error should go away "soon".

 

Got same problem with PUN 2 on 2019.2.0b7 had to downgrade project to 2019.1.

 

Try re-importing your manifest file in 19.2 we've not have any other reports of issues since the fix was released.

 

I am using Unity 2019.0a8. everything was great until I added the Facebook SDK 7.12.1 and then I got this: error CS0234: The type or namespace name 'UI' does not exist in the namespace 'UnityEngine'. I looked at the Package manager and the ugui package is in there. I then tried to remove the Facebook SDK and still getting the same error. What can I do?

 

Oh also tried using the bug reporting tool and it crashed?

 

I still have the issue described above with Unity 2019.2 final.

 

I was currently at the process of upgrading said project to Unity 2019.2 final just to see if this issue was fixed. Sad to see it wasn't.

 

I did reset all my packages, reimport all unity assets, upgrade 3rd party assets are and now it's gone.
Still not automated anyway and you may have an assets which is not updated yet for this. I had to upgrade dotween too for example.