KeldorKatarn
Posts: 86
Joined: 30 May 2014, 10:26

Re: UnityPackage 1.3 BETA5

21 Feb 2017, 23:09

Btw, just a quick interlude. Would it be possible for the Noesis package upon being added to the project to automatically add a flag to Edit > ProjectSettings > Player > Scripting Define Symbols?
A flag like NOESIS or something? I'm currently writing some stuff that works against several XAML platforms and right now I have to use the Unity flag to test whether I'm working against Noesis. it would be cooler (and also potentially work better against the C#SDK for example) if there was a compiler flag. I mean I can add that myself but it would be neat if the package could do that opon being added to the project (if that's even possible)
 
MissingAFew
Posts: 1
Joined: 21 Feb 2017, 23:37

Re: UnityPackage 1.3 BETA5

21 Feb 2017, 23:48

Hi, this is good news. What platforms do you plan to support with the final 1.3 Unity version?
  • windows: x86 x86_64 OpenGL D3D11
  • macOS: x86 x86_64 OpenGL
  • linux: x86 x86_64 OpenGL
  • iOS: arm arm64 OpenGL ES Metal
  • android: arm x86 OpenGL ES
  • UWP: D3D11
  • Xbox One
  • PS4
We plan to add more platforms after 1.3.0 like D3D12, Metal on macOS, Vulkan...
Is there currently PS4 support in the new BETA or will it be released in the next update? Thanks!
 
User avatar
sfernandez
Site Admin
Posts: 1451
Joined: 22 Dec 2011, 19:20

Re: UnityPackage 1.3 BETA5

22 Feb 2017, 00:51

So just to confirm this, I opened a completely empty UnityProject, added the Noesis UnityPackage, then went in Unity on Assets->Open C# Project.
VS opens up, loads the project. I hit "Attach to Unity", and I get an message about build errors.
So I don't know how this works on your end but on mine this is unusable out of the box.
I don't know what could be happening in your project different from what we are testing here.

Anyway, as having all these Intellisense errors in VS is not desirable, I think it is safe if we use ENABLE_MONO and ENABLE_IL2CPP defines.
We will add them in the next release like this:
#if __MonoCS__ || ENABLE_MONO || ENABLE_IL2CPP

namespace System.Collections.Specialized
{
    /// <summary>
    /// A collection implementing this interface will notify listeners of dynamic changes,
    /// e.g. when items get added and removed or the whole list is refreshed.
    /// </summary>
    public interface INotifyCollectionChanged { ... }
}

#endif
 
KeldorKatarn
Posts: 86
Joined: 30 May 2014, 10:26

Re: UnityPackage 1.3 BETA5

22 Feb 2017, 10:17

I don't know what could be happening in your project different from what we are testing here.

Anyway, as having all these Intellisense errors in VS is not desirable, I think it is safe if we use ENABLE_MONO and ENABLE_IL2CPP defines.
We will add them in the next release like this:
#if __MonoCS__ || ENABLE_MONO || ENABLE_IL2CPP

namespace System.Collections.Specialized
{
    /// <summary>
    /// A collection implementing this interface will notify listeners of dynamic changes,
    /// e.g. when items get added and removed or the whole list is refreshed.
    /// </summary>
    public interface INotifyCollectionChanged { ... }
}

#endif
Thank you. I checked again in VS, the errors I'm getting are not intellisense errors. They are clearly build errors. On "Attach to Unity" VS is starting a build process. It's probably not really building an assembly, but it's checking whether the code compiles anyway. And it reports build errors. I filtered all Intellisense errors out of the output window, since you can filter intellisense and build errors there. All the 'missing type' errors and such are Build output errors. I don't know WHY VS is doing it on my end and not on yours, but quite honestly I like my version a lot better. It SHOULD report errors if the code doesn't work. And without the flag it clearly doesn't work. It's weird that there are different flags set in the VS project and in the Unity compiler but the __MonoCS__ flag is probably set by the Mono Runtime, not by Unity. So I think adding the ENABLE_MONO check is the safer bet for unity. That seems to be the flag they support for the IDE code projects.

As I said I have no idea what could be different. I literally tested it with a clean Unity project, just adding your package, nothing else, then telling Unity to open VS. So there's NO other code than yours in the project and VS cannot attach.

For adding the __MonoCS__ flag manually in the Unity project generation settings to fixes the problem, just in case someone else needs the workaround for now.

Btw, sometimes it IS desirable to build the code in VS, just to be able to run a separate unit test project against the output assembly. Yes one could also use the one Unity produces, but some people precompile DLLs and put those into the assets folder. I've seen people discuss this workflow in the forums, even though it seems not the desirable way to do things in Unity. If anybody every did that including the Noesis code, that wouldn't work without the flag. So it's definitly a thing that needs to be fixed like this.

Looking forward to the next version.
 
movra
Posts: 70
Joined: 02 Apr 2014, 20:35

Re: UnityPackage 1.3 BETA5

22 Feb 2017, 13:37

For Unity with .NET 4.6 you need to add !NET_4_6 :
#if !NET_4_6 && ( __MonoCS__ || ENABLE_MONO || ENABLE_IL2CPP)
Otherwise you will get 80 warnings in Unity with .NET 4.6:
warnings.png
For Windows Store/Phone/Universal platforms the NETFX_CORE symbol seems to have been removed since Unity 5.3 - contrary to the Unity 5.5 docs. As far as I know those platforms now have a fixed WSA Subset API without the ObservableCollection et al. classes.

If you set the Scripting Backend to .NET, none of the __MonoCS__ || ENABLE_MONO || ENABLE_IL2CPP are in the DefineConstants. So you will need to add one of the red symbols:
standalone_wsa_defines.png
We'd finally get the following ifdef :
#if !NET_4_6 && ( __MonoCS__ || ENABLE_MONO || ENABLE_IL2CPP || UNITY_WSA)
Would be nice if someone could validate what I just said because I'm on Windows 7 and Unity employees still say you have to use NETFX_CORE instead of UNITY_WSA for .NET differences.
 
movra
Posts: 70
Joined: 02 Apr 2014, 20:35

Re: UnityPackage 1.3 BETA5

22 Feb 2017, 14:30

By the way, UniRx solved it the other way around.
But I think our method should work too, as long as we get the defines right.
 
KeldorKatarn
Posts: 86
Joined: 30 May 2014, 10:26

Re: UnityPackage 1.3 BETA5

22 Feb 2017, 15:55

Not sure about that since Rx only used the types internally right? The Noesis types are meant to be used by the user of the library, so having the same type in different namespaces for different platforms might not really work in this case.
 
movra
Posts: 70
Joined: 02 Apr 2014, 20:35

Re: UnityPackage 1.3 BETA5

22 Feb 2017, 16:34

Not sure about that since Rx only used the types internally right?
IObservable is the glue that makes the whole thing work both internally and in userland. It's the Reactive counterpart to plain C# events. Here's an example:
// Uses UniRx.IObservable<T> in the editor and System.IObservable<T> when compiling with NETFX / .NET 4.6
using System;

using UnityEngine;
using UniRx;

public class SomeController : MonoBehaviour
{
    public IObservable<bool> SomeProperty { get; set; }
}
 
KeldorKatarn
Posts: 86
Joined: 30 May 2014, 10:26

Re: UnityPackage 1.3 BETA5

22 Feb 2017, 16:45

IObservable is the glue that makes the whole thing work both internally and in userland. It's the Reactive counterpart to plain C# events. Here's an example:
Yeah but that falls appart if the user actually references the IObservable by its fully qualified name and then switches platforms. Anyway, not the time and place for that. We need the solution for Noesis.
 
User avatar
jsantos
Site Admin
Topic Author
Posts: 2350
Joined: 20 Jan 2012, 17:18
Contact:

Re: UnityPackage 1.3 BETA5

22 Feb 2017, 20:10

Hmm... adding it to the Noesis Settings worked. but I still think this is a bit weird. If it's referenced or loaded from the resources, why do I reference the path to the XAML file still in the LoadComponent call? I mean I'm not actually loading the xaml text file, I'm loading the asset file instead, aren't i? How does LoadComponent even do that lookup? After all the asset file could be somewhere completely different from the xaml file couldn't it? Also I don't really like having to hardcode a path since that breaks everything if I reorganize my project structure for some reason, like changing folders around or such. I guess this works for now but it would be cool if somehow it would be possible to implement an automatic lookup to link code behind and XAML. I mean the xaml contains the x:class attribute specifiying the type doesn't it? If I add it to the settings file as preloaded XAML could that type be used in a lookup table? Like when the code behind wants to load it, the Noesis framework looks in the preloaded stuff for a XAML that was stored under the correct type key?
Just an idea. For now that works thanks. once I added it to settings list (which I didn't even know existed :D) it works fine.
In our samples it works without registering the asset because the XAML is being referenced in the camera component. The problem is when you need to load an asset that is only being referenced by code. This is the same problem you have in Unity if you try to load a texture by code for example. For that to work you need to put the texture in the /Resources/ folder or just have a reference somewhere in a Monobehaviour.

With user controls you have exactly this problem, the asset resource is requested by code. That's the reason we added a list of preloaded assets in the settings. Assets found in that list will automatically register its source path (saved when the XAML is imported) to work whenever you use LoadXaml or LoadComponent. Note that you can move the asset after importing and everything will work but you need to always use the original path when doing LoadXaml.

We allow loading from string to be 100% compatible with WPF. But if you don't care about that you can use Unity API to load resources. For example, something like this will work:
NoesisXaml xaml = Resource.Load("Resources/button.xaml") as NoesisXaml;
Button button = xaml.Load() as Button;
By the way, LoadComponent is missing from NoesisXaml, we will add it in the next release.

In future versions (not 1.3.0) we plan to automatically generate this code (the InitializeComponent() function) in the same way Visual Studio is doing. That's the reason it seems a bit verbose right now...

Who is online

Users browsing this forum: No registered users and 1 guest