View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001079||NoesisGUI||C# SDK||public||2017-05-12 07:23||2019-03-15 00:07|
|Target Version||2.2.0||Fixed in Version||2.2.0|
|Summary||0001079: Noesis Application Framework|
|Description||After completing "1078: C# SDK with namespaces compatible with WPF/UWP" http://bugs.noesisengine.com/view.php?id=1078 and fixing most of the reported differences with WPF it will allow us to start an open-source project "Noesis Application framework".|
Ideally, it should be distributed via Nuget as following packages:
* Noesis.GUI.Core.MSCompatible (that's it, C# SDK compiled with MS_API_COMPATIBILITY flag)
* Noesis.GUI.Platforms.Windows (only Windows x86 and x86_64 native DLL)
* Noesis.GUI.Platforms.Linux (only Linux x86 and x86_64 native DLL)
* Noesis.GUI.Platforms.Mac (only Mac x86 and x86_64 native DLL)
... (and other platforms)
* Noesis.ApplicationFramework.Core (crossplatform, include nuget reference on Noesis.GUI.Core.MSCompatible )
* Noesis.ApplicationFramework.Platforms.WindowsD3D11 (include nuget references on Core+Platform and SharpDX)
* Noesis.ApplicationFramework.Platforms.WindowsOpenGL (include nuget references on Core and C# OpenGL)
* Noesis.ApplicationFramework.Platforms.LinuxOpenGL (include nuget references on Core and C# OpenGL)
* Noesis.ApplicationFramework.Platforms.MacOpenGL (include nuget references on Core and C# OpenGL)
... (and other platforms)
It should also include custom MSBuild target which will automatically copy all the XAML files into the application build folder (to be able to load them in Runtime) during the build phase.
It will allow developers to easily port their WPF/UWP applications to NoesisGUI for Windows by following these steps:
1. Create a new C# project (executable).
2. Add nuget reference for Noesis.ApplicationFramework.Platforms.WindowsD3D11.
It will automatically add dependent nuget references:
3. Link items from already existing C# WPF/UWP project:
with VS2017 it could be done very easily with wildcards in Projects file:
<Compile Include="\..\WPFProjectPath\**\*.xaml" />
<Compile Include="\..\WPFProjectPath\**\*.cs" />
4. Fix found API differences.
If developer need to port application to multiple platforms, it could be done this way:
1. Core C# project with reference only to Noesis.ApplicationFramework.Core (it will automatically reference Noesis.GUI.Core.MSCompatible). It should include the XAML and XAML.CS files.
2. C# executable projects for each target platform (referencing according Noesis.ApplicationFramework.Platforms.* nuget which will automatically include according Noesis.GUI.Platforms.* nuget). They're basically empty projects referencing core C# project and serving as entry point to the application on according platforms.
Executable files could be run with Mono/CoreCLR on Linux and Mac. Mono or CoreCLR could be embedded with the application (as it's already done for many games on these platforms, for example https://github.com/flibitijibibo/MonoKickstart but it will even easier for CoreCLR).
I think this is not really hard and this opensource project could be started with only some platforms but grow to full-fledged framework.
|Tags||No tags attached.|
We just published the first 2.1 beta for C#. It also includes a first approach to the application framework, for now only windows is included. The architecture is very similar to C++, in fact we are reusing things we already have in C++ (like the renderers) instead of adding extra dependencies to SharpDX and things like that. There are *a lot* of things to do here.
Step by step : )
I will take a look when I will have time.
Now we're crunching hard to finish the game for open alpha.
The game is great and so far we have high hopes for sales figures, despite the delay!
Hi, we are working on moving our C# code to NuGet and we are facing some problems with the native libraries that maybe you can help with.
We decided the following structure of packages:
Noesis.GUI ---------------------> Wrappers and proxies for Noesis core, includes all native libraries
Noesis.App ---------------------> Pure C# Noesis application framework
Noesis.App.Platforms.* ---> Pure C# implementation of RenderContext and Displays for each platform
An application will depend on the desired platform packages to get all the dependencies.
The problem we are having is that native libraries in Noesis.GUI package are not copied to output folders when building the application, only managed assemblies are.
Native libraries are included in Noesis.GUI package inside 'runtimes' folder:
<Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <TargetFramework>netstandard2.0</TargetFramework> ... </PropertyGroup> <ItemGroup> <None Update="runtimes\**" Pack="true" PackagePath="" /> </ItemGroup> </Project>
runtimes/android-arm/native/libNoesis.so runtimes/win-x86/native/Noesis.dll runtimes/win-x64/native/Noesis.dll ...
Have you faced this problem and know how to solve it? Documentation is bit of a mess considering the differences between old and new SDK csproj files.
I've never deployed native libraries with NuGet for our apps but I'm aware that there is much pain with their distribution in NuGet packages. Previously (mostly for Xamarin apps) people were writing custom MSbuild targets to copy all the necessary native libraries (and I think this is still possible though quite verbose and hard to properly setup). However, it has a limitation - native libraries are copied only into the project output folder which directly references the NuGet. If another project references this project, it will not copy native libraries (a direct link from the final C# project to NuGet package containing the native libraries is required). Probably, NuGet still has such an issue so keep this in mind!
I see you're using the new approach with "runtimes". The format (RID mapping) is looking properly so it should work fine. There are some known problems though:
1. You need to ensure the runtimes are actually copied into the resulting package file (.nupkg).
2. If the application is built for .NET Framework (I suppose this is the case), you need to reference Microsoft.NETCore.Platforms for this application project so the RID fallback mapping will be provided (see https://stackoverflow.com/a/52459363/4778700 ).
If you still cannot make it work you can drop me the sample project and I will check it ASAP. I have some experience with debugging issues with MSBuild.
We followed all the indications and still are unable to get the native libraries deployed.
You can download the solution with all the projects here: https://drive.google.com/open?id=1E5r1t_B7jBy4gUy1b4zer6MQChRAigmh
The Buttons sample is the one we are using for these tests.
Pleasse let me know if you find something unusual or that can be improved.
|As a quick note. I've looked into this and it does copy Noesis.dll in case I'm building Button project for 64-bit platform (Src\Samples\Buttons\Projects\windows_x86_64\Bin\x64\Debug).|
|I tried so many things that I can't assure I already tried that before, but the fact it is working for me too selecting x64 platform in the Buttons sample :)|
Ok, I've figured out what's going on.
You're using NuGet custom sources (configured in VS NuGet settings) and NuGet client in VS/MSBuild is caching every package.
So every time you're trying to build the Buttons project it does not pull the actual packages and continue using their cached version.
You can force NuGet to clean the caches by running this command in VS Package Manager Console:
nuget locals all -clear
After that it started working fine when I did any changes with runtimes. Otherwise it always used the cached packages (even after deleting runtimes folder and repacking the NuGet package, it still copied Noesis.dll from the cached package).
Also, it's not recommended to reference NuGet projects via PackageReference. Just use a Project reference instead. So, for example, in case of Noesis.App.csproj, replace:
<PackageReference Include="Noesis.GUI" Version="2.2.0" />
<ProjectReference Include="..\..\Noesis\Noesis.GUI.csproj" />
It will still generate a proper NuGet package (basically, there are no differences in output, it still will reference the same NuGet package of the referenced project).
However, it will not work with Buttons project as this project must reference NuGet packages (not project references) in order to use the NuGet runtimes copy feature. I'm really not sure what to do in that case. The documentation is severely lacking as you have noticed.
The best idea is to look how other multi-targeting projects are organized on Github. I don't have an immediate suggestion as most projects (such as Xenko game engine) are too bloated and have custom MSBuild tooling which is overkill for your case.
It's definitely working here - I've tried x86 and x64 and it does work properly.
But it's very annoying. If I change something in Noesis.GUI C# project, I have to build it, then use use
nuget locals all -clearand only then build Buttons C# project. But it works fine.
Hi, we uploaded our first version of NuGet packages: https://www.nuget.org/profiles/NoesisTechnologies
Could you please try them and give us your opinion if anything can be improved?
We also published the code in our GitHub: https://github.com/Noesis/Managed, so anyone can download it and modify anything they want.
|This doesn't make sense without any example Sergio. Could you upload one of the examples to github?|
We updated the Buttons sample to use our NuGet packages, you can download it from here:
Hi guys. Sorry for the delay. I'm on a short vacation now and will have a detailed look in the next 24 hours as I will have access to VS.
From the first look on Github source and samples and NuGet packages list, all is just great.
BTW, I think that NoesisGUIExtensions.cs should be a part of a separate NuGet package or even integrated into the primary (Noesis.GUI) package.
|UPD. Re: NoesisGUIExtensions.cs - I remember now that it's required only for WPF to ensure there are no XAML compilation issues... so probably it should be a part of a separate NuGet package - so the recommended way of "flavoring" a WPF project with NoesisGUI extensions will be via NuGet - even though it will not give any practical benefits for WPF project itself.|
It is a great idea, we'll do it.
Thanks a lot for the feedback.
1. As a very minor notice, the samples repo is quite heavy (179 MB, most of which SourceHanSans-Regular.ttf (46 MB) and several *.uasset and *.asset files (over 100 MB). It seems rounded-mgenplus-1c-regular.asset is mirroring rounded-mgenplus-1c-regular.ttf (both are 9.1 MB). Not a problem, but keep this in mind for the future changes as you might easily remove or replacing several files with lighter alternatives without actually affecting the samples.
It's a misleading sample as it will never work on Linux (targets .NET Framework; also it doesn't work in Windows for me for some strange NuGet-related error ("Your project file doesn't list 'win-x86' as a "RuntimeIdentifier". You should add 'win-x86' to the "RuntimeIdentifiers"" even though it does)). It's also referencing both RuntimeIdentifiers - win-x64 and linux-x64 which doesn't make sense for a Linux sample.
If you intend to use it as a sample for OpenGL for Windows, you should probably redo it as "Samples/C#/Projects/windows-opengl".
I would love to see a proper sample targeting .NET Core 2.1, eventually! :-)
Alas, I cannot tell anything regarding other samples (uwp, android, ios) as I don't have the environment to try them here.
3. NoesisGUI sample for Windows doesn't play sounds for me. Audio files are included and the same XAML is used. So, either PlaySoundAction doesn't work, or sound library failing to work for me here.
In WPF buttons sample, audio does work fine.
I assume NoesisGUI now includes basic audio support otherwise I don't see a good reason for linking *.mp3 files in the NoesisGUI C# sample...
UPD. I see it's not implemented for Win32Display now https://github.com/Noesis/Managed/blob/e165da7e5f7183036c59b54d145818d71f41033a/Src/NoesisApp/Displays/Win32/Src/Win32Display.cs#L288 probably it would better if you either implement it (either there or as a C# event which is hooked for C# Windows sample to plays the requested sound via Windows API or any other NuGet-delivered library). Otherwise, again, I don't see a good reason for linking *.mp3 files in this project while user cannot hear them.
4. "App.xaml.g.cs" (at Tutorials-master\Samples\Buttons\C#\Src)
It's very confusing. It's assumed that the generated C# files (*.g.cs) should never be a part of the solution. And in this particular case, this is NOT a generated C# file. It's a handmade C# file - actually, it's multiple C# files for each platform, with a lot of horrible conditional compilation.
It makes perfect sense to split this file into multiple files - each one for each platform.
I would prefer to make it this way:
(so corresponding App.cs will be available in each platform's sample project folder)
or this way:
(so each C# sample project will link according App.<platform>.cs file from shared Src folder)
This way you can also get rid of the unnecessary conditional compilation.
Thanks for your time!
1. Thanks for commenting about this. We take care about it (unfortunately that 46MB of font corresponds to one of the first commits and I think there is no way to delete that from the history right?).
2. Linux is still not finished. We have issues copying the binaries to the destination folder. But it is working fine with '.NET Framework' target. @sfernandez can give more details about it
3. Yeahs, sounds are not implemented yet. They are in C++, that's the reason we have the sounds there.
4. Thanks for this suggestion. We are going to reorganize things that way. Effectively those *.g.cs should be generated automatically with a plugin in Visual Studio, but we didn't find time to do it.
So, regarding 4)
We have two kind of files here:
- The code doing the bootstraping (creating the propery display and renderer). As you suggest, this should go in <platform>\App.cs
- The automatically generated code (.g.cs) that will implement the LoadInitializeCompoennt, FindNames, Events, etc. This file is the same for all platforms, where do you suggest putting this file?
I'm glad to help.
1. You could try git rebase (though it's quite dangerous) or this special Github tool for removing "sensitive" files https://help.github.com/en/articles/removing-sensitive-data-from-a-repository If you do this, I believe you will need to re-download the whole repo from Github as otherwise you will be unable to push the new commits due to the commits history hashcodes mismatch.
Probably having this file in the repo history is not a big deal - I always download the repo as a Zip archive to try it out (as I did this time). I download the full git repo only if I definitely want to have the ability to experiment with some changes and commit/revert them after that - and in that case I expect that downloading will take a while.
2. Are you actually experimenting with .NET Core 2.1 for Linux? Have you tried to raise the issue in https://github.com/nuget/home/issues ? This is the place to look for certain help regarding this problem.
3. I see. So there are two options - either remove links to MP3-sounds from C# demo projects to avoid confusion or implement support for audio playback... but after a quick research I don't see a reasonable way to do this now: for example NAudio has a NuGet package however it's Windows-only; there is still no proper .NET audio library for .NET Core with Linux support; there are also no well-tested OpenAL wrappers for .NET Core; and if you have an audio player in native Noesis.dll now (I remember you've posted something about it in Twitter) adding a C# API for it will create a lot of confusion :-)
4. >> The automatically generated code (.g.cs) that will implement the LoadInitializeCompoennt, FindNames, Events, etc. This file is the same for all platforms, where do you suggest putting this file?
Same as in WPF, of course. All XAML files should have corresponding .g.cs files (including App.g.cs) and these files should always go into obj project folder -- so they're not visible and not editable.
The VS/MSBuild plugin is very much expected... I know developing it is a painful experience -- though, it's way easier if you already have a CMD tool performing the task; adding required VS SDK targets to make generator (which is using the CMD tool) to work automatically is not that hard.
If you certainly don't want to implement VS/MSBuild plugin in the closest future, you have to write the required "generated" code manually as a temporary solution. There are two options where you could put that code:
1. conditional compilation with #if NOESIS (like you do for MainWindow.xaml.cs and similar files to call LoadComponent(...) or locate controls via find by name). In the case of App.xaml.cs file it's usually just a few lines of code so no problem with code duplication in every App.cs file as I've suggested above.
2. OR write corresponding *.xaml.noesis.cs files and link them into each C# demo project
In the both cases, it would be great to have a readme file clarifying the problem and the temporary solution -- until you implement the plugin. You can even link this single readme file into all C# demo projects to make it obvious.
|2017-05-12 07:23||ai_enabled||New Issue|
|2017-05-12 07:24||ai_enabled||Summary||NoesisGUI Application framework => Noesis Application framework|
|2017-05-12 07:24||ai_enabled||Summary||Noesis Application framework => Noesis Application Framework|
|2017-05-12 07:27||ai_enabled||Description Updated||View Revisions|
|2017-05-12 07:28||ai_enabled||Description Updated||View Revisions|
|2017-05-12 07:29||ai_enabled||Description Updated||View Revisions|
|2017-05-12 07:30||ai_enabled||Description Updated||View Revisions|
|2017-12-20 03:45||jsantos||Assigned To||=> sfernandez|
|2017-12-20 03:45||jsantos||Status||new => assigned|
|2017-12-20 03:50||jsantos||Note Added: 0004947|
|2017-12-20 08:48||ai_enabled||Note Added: 0004951|
|2018-11-01 02:14||jsantos||View Status||public => private|
|2019-02-12 23:12||sfernandez||Target Version||=> 2.2.0|
|2019-02-12 23:12||sfernandez||Platform||=> Any|
|2019-02-14 16:33||sfernandez||Status||assigned => feedback|
|2019-02-14 16:33||sfernandez||Note Added: 0005439|
|2019-02-14 16:34||sfernandez||Note Edited: 0005439||View Revisions|
|2019-02-14 17:14||ai_enabled||Note Added: 0005440|
|2019-02-14 17:14||ai_enabled||Status||feedback => assigned|
|2019-02-18 12:03||sfernandez||Status||assigned => feedback|
|2019-02-18 12:03||sfernandez||Note Added: 0005441|
|2019-02-18 12:05||sfernandez||Note Edited: 0005441||View Revisions|
|2019-02-18 12:51||ai_enabled||Note Added: 0005442|
|2019-02-18 12:51||ai_enabled||Status||feedback => assigned|
|2019-02-18 14:06||sfernandez||Note Added: 0005443|
|2019-02-18 14:10||ai_enabled||Note Added: 0005444|
|2019-02-18 14:11||ai_enabled||Note Edited: 0005444||View Revisions|
|2019-02-18 14:29||ai_enabled||Note Added: 0005445|
|2019-03-04 09:47||sfernandez||Status||assigned => feedback|
|2019-03-04 09:47||sfernandez||Note Added: 0005492|
|2019-03-04 09:48||sfernandez||Note Edited: 0005492||View Revisions|
|2019-03-04 11:19||jsantos||Note Added: 0005493|
|2019-03-04 11:24||sfernandez||Note Added: 0005494|
|2019-03-05 01:34||ai_enabled||Note Added: 0005497|
|2019-03-05 01:34||ai_enabled||Status||feedback => assigned|
|2019-03-05 01:34||ai_enabled||Note Edited: 0005497||View Revisions|
|2019-03-05 01:49||ai_enabled||Note Added: 0005498|
|2019-03-05 14:12||sfernandez||Note Added: 0005499|
|2019-03-06 00:48||ai_enabled||Note Added: 0005500|
|2019-03-06 00:49||ai_enabled||Note Edited: 0005500||View Revisions|
|2019-03-06 00:51||ai_enabled||Note Edited: 0005500||View Revisions|
|2019-03-06 00:54||ai_enabled||Note Edited: 0005500||View Revisions|
|2019-03-06 00:55||ai_enabled||Note Edited: 0005500||View Revisions|
|2019-03-06 00:56||ai_enabled||Note Edited: 0005500||View Revisions|
|2019-03-06 00:56||ai_enabled||Note Edited: 0005500||View Revisions|
|2019-03-06 00:57||ai_enabled||Note Edited: 0005500||View Revisions|
|2019-03-06 17:15||jsantos||Note Added: 0005503|
|2019-03-06 17:19||jsantos||Note Added: 0005504|
|2019-03-06 17:19||jsantos||Status||assigned => feedback|
|2019-03-06 17:20||jsantos||View Status||private => public|
|2019-03-06 23:53||ai_enabled||Note Added: 0005506|
|2019-03-06 23:53||ai_enabled||Status||feedback => assigned|
|2019-03-06 23:54||ai_enabled||Note Edited: 0005506||View Revisions|
|2019-03-06 23:57||ai_enabled||Note Edited: 0005506||View Revisions|
|2019-03-15 00:07||sfernandez||Status||assigned => resolved|
|2019-03-15 00:07||sfernandez||Resolution||open => fixed|
|2019-03-15 00:07||sfernandez||Fixed in Version||=> 2.2.0|