Forums | NoesisGUI

Has anyone tried to share code with an existing WPF app?

Also, maybe I don't "get" Unity yet, but I have always tried to avoid having loose C# files everywhere, or from having to touch MonoDevelop. So I'm trying to go with DLLs and Visual Studio.

• Create a dummy Unity project that you will use as reference. Extract the NoesisGUI unity package to it.
• Take the Assets/Plugins/NoesisGUI/* directory and turn it into a C# DLL for Windows standalone (set define flags: UNITY_STANDALONE;UNITY_STANDALONE_WIN)
• Take the Assets/Editor/NoesisGUI directory AND all of the same above files, and turn it into a DLL. (set define flags: UNITY_EDITOR.
• Pro-tip: edit a .csproj file, and add the line <Compile Include="**\*.cs" /> to grab all files in a tree.
• On Windows, I use the Link Shell Extension program to clone a tree of hard links for all the C# files. (Soft-links don't seem to work in Visual Studio.) This can save some disk space.
• In the Unity project, in the Assets directory, import the Editor/Plugins stuff, except delete (or don't import) all of the Noesis .cs files out of the above two directories that are already in the DLL.
• I gave both DLLs the same name! My post-build event creates an empty marker file (and deletes other marker files) so I can tell which file is in there. (You could also look at the DLL size.)
• Swap the DLLs depending on what you want to do: When doing a build from Unity, make sure the Windows standalone DLL is in your Unity project's Assets/ folder. When hitting play button from Unity editor, make sure the Editor dll is in there. (But don't do a copy local on UnityEditor.dll, or Bad Things(TM) will happen.)
• For some reason, to get editor working, I had to put the Assets/Editor/NoesisGUI dir into my system environment path so it could find tbb.dll, etc. I'm hoping to find another fix for this.
• My code-behind lives in a separate DLL. Reference either one the above DLLs. (Only a few things were different from my proof-of-concept WPF codebase: Points use float instead of double, good idea. And Matrix4.Transform is missing..hmmm, not sure yet what to do about that.)
• I created a simple MonoBehaviour file to take a WPF-style code-behind file (with a few ifdefs), use reflection to look for event handlers: e.g. if void MyButton_Click(object sender, RoutedEventArgs e) {...} exists, it will try to find MyButton, and its Click event, and add a delegate. (Check out the gist: https://gist.github.com/jaredthirsk/38d ... 2df41e4718)

Am I crazy, or is this a cool idea? Has anyone else gone down this road?

[[UPDATE]]: Whether I'm crazy may still be TBD, but this works! (On Windows and Windows editor at least, with some DLL juggling. I'm going to try more platforms later.) Cooool!

Hello!
We've done it in the our project (game VoidExpanse) and I can say it's a very complicated solution.
You have to separate NoesisGUI code from Plugins and from Editor/NoesisGUI folders to two .NET 3.5 projects ("NoesisGUI.Wrapper" and "NoesisGUI.Wrapper.Editor"), then you need to write post-build scripts for these projects to copy NoesisGUI libraries (I mean native NoesisGUI libraries for different platforms) and the built DLL's back to Plugins and Editor/NoesisGUI.
Also you need to write a Unity post-build script to build "NoesisGUI.Wrapper" for release configuration with flags for actual platform (UNITY_STANDALONE_WINDOWS, UNITY_STANDALONE_OSX, UNITY_STANDALONE_LINUX for desktop platforms accordingly) and replace actual "NoesisGUI.Wrapper" into the game build directory with it.
So... it's very complicated! And upgrading NoesisGUI to the new version is also not so easy - you need to repeat copying of the files (native libraries and C# code from Plugins and Editor/NoesisGUI folders) and make sure that new files included into the "wrapper" projects.
Of course it give you some nice advantages every experienced programmer dreaming about. We've separated "core" UI library - it depends on the "NoesisGUI.Wrapper" project and includes reusable code like base classes, primitive controls (Windows, DialogWindows, custom ViewBox'es), services (localizations, custom tooltips, sounds), etc. We can reuse it in the other games easily.
Regards!

Awesome! Thanks for sharing how you did it!

If a lot of people are going to want this (and it seems more likely than the average game developer, since many of us come from WPF land), it would be nice if Noesis Technologies did this for us to save us from this trouble every time a new version comes out!

BTW, ai_enabled, how did you handle the dependencies from the Editor DLL to the main Wrapper DLL? 1) I tried a DLL reference, but many things in the main DLL are marked internal. (Could change them to public, or maybe use a InternalsVisibleTo attribute.) 2) I also wondered about including another copy of all of these things in the Editor DLL, and wondering if they somehow won't conflict. 3) I also wondered about trying to exclude the Editor DLL altogether -- not sure if that's possible or what I'd be missing.

Hmm, ai_enabled went down the route that I started but I found way too cumbersome, especially when you're trying to support multiple platforms. Then I tried going a similar but still different way and started using filesystem links under Unity.

So I use normal assemblies and proper C# projects (WPF projects for the NoesisGUI stuff) for everything but Unity, where I only link to the source directories of my various c# projects.

Unfortunately I have a similar problem to ai_enabled, meaning upgrading to a new NoesisGUI version takes some time as I have to install the UnityPackage into a clean Unity project and then copy and compare all files back to my own NoesisGui.dll that I use in my various projects.

The other downside is that with the introduction of NoesisGUI v1.2 and some MVVM stuff it gets a bit more difficult as NoesisGUI provides the same classes that already exists in the same namespace. I got around this creating two NoesisGUI-Core libraries. One that doesn't have these files and one that contains all files that I can use as a link target from Unity.

It's still not the optimal solution but it works good enough and I got even on my build server running without much trouble.

... I updated my how-to work-in-progress in my original post.

Amazing thread!

Just a few observations:

• Originally, we wanted to distribute the C# layer as a DLL. But, things got more complicated that it seemed because we had to split in two DLLs (editor and standalone) and we needed different binaries for each platform. We tried avoiding using #ifs in our managed code but that was not easy. Basically, all the problems you are trying to solve here. But at the end we think that distributing directly the .cs has provided advantages as the users can tweak the source and apply fixes without having to wait for a new release from us. Anyway, it would be great if we could add to the documentation a standard way to build the DLLs from the source.
• Regarding events and automatic subscription to code-behind methods. This is something in our TODO list. It will work exactly the same way as WPF. In fact, this feature is already implemented in C++
• Regarding the issues with Point, Matrix, Transform... we should use the .NET implementation instead of having our own classes. This is in the TODO list also.

This thread is also related to this one: viewtopic.php?f=3&t=606

[*] For some reason, to get editor working, I had to put the Assets/Editor/NoesisGUI dir into my system environment path so it could find tbb.dll, etc. I'm hoping to find another fix for this.

If this a problem related only to tbb.dll, we have plans to eliminate this dependency. Imminent plans (in v1.2.3 probably).

[*] For some reason, to get editor working, I had to put the Assets/Editor/NoesisGUI dir into my system environment path so it could find tbb.dll, etc. I'm hoping to find another fix for this.

If this a problem related only to tbb.dll, we have plans to eliminate this dependency. Imminent plans (in v1.2.3 probably).

I am getting errors for multiple DLLs, I think. I used SysInternals ProcMon to see what it was up to.

Has anyone tried to share code with an existing WPF app?

Thanks for this but I feel I must tell you this. I share your feelings about the loose C# files but I've tried the DLL approach with a project and I can only recommend you do not do that. it is a major pain. Most asset store stuff comes as c# with no chance to get them as DLLs, especially the GUIs since they require the compiler flags to remain platform independent. Getting the dependencies cleared up or using references to external stuff becomes even more of a pain. Trust me, get UnityVS which is not free, use the generated solution and let Unity compile it all. It's a MAJOR pain otherwise, it just doesn't work. This is the Unity way and I failed miserable trying to do it any other way.

Has anyone tried to share code with an existing WPF app?

Thanks for this but I feel I must tell you this. I share your feelings about the loose C# files but I've tried the DLL approach with a project and I can only recommend you do not do that. it is a major pain. Most asset store stuff comes as c# with no chance to get them as DLLs, especially the GUIs since they require the compiler flags to remain platform independent. Getting the dependencies cleared up or using references to external stuff becomes even more of a pain. Trust me, get UnityVS which is not free, use the generated solution and let Unity compile it all. It's a MAJOR pain otherwise, it just doesn't work. This is the Unity way and I failed miserable trying to do it any other way.

Thanks for sharing your experience. I will take it under advisement
BTW, UnityVS was acquired by Microsoft and I believe it is now free. I'm going to give it a try. (http://unityvs.com/)