Forums | NoesisGUI

Hi,

I have just started converting my projects to v1.2 of NoesisGUI again (this time in the trunk and not an extra branch) but I stumbled about a big problem I'm not able to solve right now.

Because I have several projects that facilitate NoesisGUI I've created a library containing the core, proxy and mvvm classes. This library is used by my other small library that contains various helper classes, base user controls, behaviors, etc.

Both of these libraries are used within each of my WPF solutions that I use to edit everything in Visual Studio. The final unity projects only contain directory links to each of the source folders. I don't have any problems within Unity.

The problem I have now with v1.2 are various classes such as ICommand, ObservableCollection, certain panels, ItemsControl, etc. that persist in the same namespace as the proper ones from WPF, e.g. they claim to be located in the System.xxx namespace but in different Assemblies.

Unfortunately I don't know what to do about these collisions in my WPF project as I can't remove neither the basic WPF assemblies such as PresentationCore, PresentationFramework or WindowsBase nor can I remove the specific classes from NoesisGUI as various other basic classes depend on those, e.g. there are several classes that depend on ICommand.

What is the suggested solution to this?

I have already started creating a second library where I removed the problematic code files and added the WPF assemblies instead. This also resulted in various errors but I will try to pursue this way this evening. Maybe this is a possible solution.

Another solution that comes to my mind is that you introduce defines that change the namespace to a different one outside of Unity to avoid these collisions.

Do you have any other ideas?

The conflicting classes you mention are probably those contained in the following files:

• NetCoreAdapter.cs
• NetControlsAdapter.cs
• Plugins\NoesisGUI\Scripts\MVVM folder

As you probably know, in Unity, Windows Store/Phone scripts are compiled using .NET instead of Mono. Because those APIs are not exactly the same, we created the mentioned files to unify the APIs. We are using the preprocessor macro NETFX_CORE to detect one platform or another. I suppose that we should extend those #ifdefs to handle more scenarios.

We could invent a new define that you could set in your projects to disable those paths.. Anyway this needs time to be analyzed because with the preprocessor macros we not only include things but also exclude, for example in WindowsPhone HandleRef no longer exists. We had to create a dummy class.

Hi,

By the way, is there any define we can use to distinguish between NoesisGUI 1.1 and 1.2? It would be very useful for migration period, since we were able to keep the NoesisGUI-version-dependant code under #if/#else/#endif and avoid the creation of different branches for 1.1 and 1.2 code.

In particular, we plan to refactor C# code of our recently released app to extract some pieces for further reuse in other projects while porting that app to Windows Phone. And the merge of the C# code migrated to NoesisGUI 1.2 for WP8-compatibility into the refactored code that's based on NoesisGUI 1.1 would be simply impossible (it means we will need to refactor C# code migrated to NoesisGUI 1.2 anew, doing the same work once again). So not creating a branch for NoesisGUI 1.2-migrated code is much better solution for us at this time.

If you have no version defines, what defines would you suggest?

Okay, I've got it working with another library. That means I've two versions of each library for now. It would be nice to find a better solution in the future. Is it okay to create a ticket for it?

Hi,
If you have no version defines, what defines would you suggest?

Yes, we though about it and would like to do it in the c++ SDK. Problem is how to do it in c#? Because there is no concept of including in this language. In Unity you can add a text file with the extra directives to the “Assets/” folder as explained in the Platform Dependent Compilation manual.

I think that doing that and adding #ifdefs to your code could probably work. That or I am missing something. Do you have a better idea?

Okay, I've got it working with another library. That means I've two versions of each library for now. It would be nice to find a better solution in the future. Is it okay to create a ticket for it?

Everything would be easier if we could detect Unity by using preprocessor directives. But, I don't know why, Unity does not provide it directly, you have to do:
Which is a nightmare to maintain...

I think that we have to detect 3 platforms:

1. Unity Version of Mono (detected using the code above)
2. WinRT platforms (this is always compiled with .net compiler even on Unity) (#if NETFX_CORE)
3. Standard .net (rest)

Do you think this would work?

I'm also interested in this subject to be able to use for example OxyPlot in Unity.

Could Noesis have its own version of the PresentationCore, PresentationFramework and WindowsBase DLLs?

- Unity Version of Mono: Put the Noesis version of the DLLs in the Plugins folder. The DLLs contain dummy classes that map System.Windows etc. to the real classes in the Noesis namespace.

- Unity WinRT platforms: Noesis dummy classes are stripped out with #if NETFX_CORE

- Standard .net (rest): Change the reference in the project file to Microsoft's DLLs.

Could Noesis have its own version of the PresentationCore, PresentationFramework and WindowsBase DLLs?

Do you mean that instead of using the Noesis namespace go directly to WPF namespace (System.Windows.Control.Button instead of Noesis.Button)?

What if I want to use Noesis in a standard .NET project?

Everything would be easier if we could detect Unity by using preprocessor directives. But, I don't know why, Unity does not provide it directly, you have to do:

Code: Select all

#if UNITY_4_0 || UNITY_4_1 || UNITY_4_2 || UNITY_4_3 || UNITY_4_5
#endif

Which is a nightmare to maintain...

At least there should now be a major UNITY_5 for all versions of Unity 5: http://forum.unity3d.com/threads/reques ... ne.298298/

Another workaround is adding 3 .rsp files with a custom UNITY symbol.
http://docs.unity3d.com/Manual/Platform ... ation.html

Could Noesis have its own version of the PresentationCore, PresentationFramework and WindowsBase DLLs?

Do you mean that instead of using the Noesis namespace go directly to WPF namespace (System.Windows.Control.Button instead of Noesis.Button)?

What if I want to use Noesis in a standard .NET project?

I was thinking about 3 DLLs that only consist of classes that map the original namespaces to the Noesis namespace through inheritance. Then you can swap DLLs from the .csproj file whenever you want to compile with the Microsoft DLLs or with Noesis.

In practice it won't be so easy to create dummy classes, because there is a huge number of classes in those 3 DLLs, some without default constructors. And then there are the non-classes such as delegates and events and so on...

Actually, what are the problems when the proxies classes are moved from the Noesis namespace to the original namespace? For example now you have
which could be changed to
Then you may get a clash when building for WindowsRT and .NET.

Possible solutions for WindowsRT:

- Wrap the classes in the proxies folder with #if NETFX_CORE
- Unity: force Mono compiler with compilation overrides setting http://docs.unity3d.com/Manual/wp8-1-faq.html

Possible solutions for .NET:

- Wrap the classes in the proxies folder with the platform define #if UNITY
- Remove the PresentationCore, PresentationFramework and WindowsBase DLLs from the .cjproj if you want to use NoesisGUI
- Remove the proxies folder from the Noesis folder if you want to use Microsoft's classes.