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 : )

Great news!
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

...

Hi,
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

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 -clear

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:

https://github.com/Noesis/Tutorials/tree/master/Samples/Buttons/C%23

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.

2. Buttons-linux.csproj
   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:
   

   Samples\Buttons\C#\Projects\<platform>\App.cs

   
   (so corresponding App.cs will be available in each platform's sample project folder)

or this way:

Samples\Buttons\C#\Src\App.<platform>.cs

This way you can also get rid of the unnecessary conditional compilation.

Regards!

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.

Regards!