I want to be able to call C# code from JavaScript. The mono project used to have a WASM SDK that you could download from their old Jenkins server, but that is no longer public. Existing docs tend to point toward those builds. The Azure Devops builds do not include this SDK. A few messages I've seen on their Github account indicate that they are now focusing on the .NET 6 for WASM. I do not wish to use the Blazor components. Is there a way in .NET 6 to build a minimally sized WASM binary without the Blazor UI?
Yes it's absolutely possible. Blazor does not have a monopoly on C#/WASM and it's far from clear that it's going to wind up being the best long term option (and a lot of evidence it's not).
I recommend starting with the Uno WASM Bootstrap. https://github.com/unoplatform/Uno.Wasm.Bootstrap
2022-06-30 Edit -
More evidence Blazor is not the only game in town nor even at the forefront of innovation here:
https://visualstudiomagazine.com/articles/2022/06/29/uno-platform-4-4.aspx
The Mono WASM SDK is continued in the dotnet/runtime repo. The tooling based on old Packager.exe has evolved into a MSBuild/csproj based solution:
https://github.com/dotnet/runtime/tree/main/src/mono/wasm
samples:
https://github.com/dotnet/runtime/tree/main/src/mono/sample/wasm
The key issue when I trying to use code in a custom project (not within the sample) is that we need to reference a private assembly System.Private.Runtime.InteropServices.JavaScript.dll which is included in Microsoft.NETCore.App.Runtime.browser-wasm. The code is almost the same as WebAssembly.Bindings.dll in old mono wasm sdk.
Here is a screenshot of a WebGL page I created, based on dotnet/runtime/mono/wasm:
BTW there is a viewpoint that the performance of implementing WebGL via calling JavaScript functions from C#, is bad: https://marcoscobena.com/?i=wave-engine-web-performance
NativeAOT-LLVM, an experimental c# compiler not official supported by Microsoft, (https://github.com/dotnet/runtimelab/tree/feature/NativeAOT-LLVM) can also compile C# to Wasm without any UI framework requirements. There's a similar question about libraries at Compiling C# project to WebAssembly
It seems that dotnet 7 has improved WASM support. More information is provided in https://devblogs.microsoft.com/dotnet/dotnet-7-wasm/
Related
I'm developing a Blazor PWA project where the WASM client needs to generate PDFs. My employer had already purchased an Xfinium license, thus I have been using it in our project. I have just recently ported the project from .NET Core 3.1 to .NET5 and have begun encountering issues with the Xfinium library. First of all, I am using the Xfinium.Pdf.NET library, as it supposedly supports .NET5. Upon attempting to initialize any object from this library (i.e. PdfFlowDocument test = new();) I am immediately greeted with the following error: Assertion at /__w/1/s/src/mono/mono/mini/interp/transform.c:3592, condition <disabled> not met, which causes my application to crash. To further pinpoint this issue, I created two separate Blazor PWA WASM projects, one with .NET5 and one with .NET6, installed the Xfinium.Pdf.NET library, and attempted to use it. Both resulted in the exact same error as above. I then recreated this on a separate machine as well.
I have reached out to Xfinium support in regards to this issue, and have yet to hear back. Wondering if anyone else has experience a problem similar to this one. For the time being I will simply keep the project on .NET Core 3.1 (the upgrade was to fix another issue where we couldn't read more than 2mb at a time from indexed db database).
Any help is much appreciated!
Upon receiving a helpful workaround from the Microsoft Forums and a response from the Xfinium support team, I can answer my own question.
The Xfinium support team was able to recreate my issue with the obfuscated NET version of their Xfinium.Pdf library. Upon testing the non-obfuscated assemblies of the same library, the problem was non-existant. Therefore, they believe the obfuscation tool is the source of the problem and have notified me that they have reached out to their obfuscation tool vendor. I will be alerted by their support team when the issue is fixed.
As for a workaround, a user named Bruce on the Microsoft Q&A Forums suggested I try the NetStandard version of the library in my NET5 project. This solved my problem. I then alerted the Xfinium support of this solution and they told me that the NetStandard assemblies for this library are in fact obfuscated using a separate tool.
Thus, for the time being, I will be going forward using the NetStandard version of the library. I will update this post when Xfinium support alerts me that a fix has been shipped.
I'm trying to use MongoDB C# driver (2.8.1) in a UWP app built for Hololens using Unity 2019.1.13f1. I read that this driver (which targets .NET 4.x if I'm correct) was fully compatible with UWP apps since Windows SDK 16299. However, even if it works like a charm in Unity Editor, it is not the case when deployed to Hololens (I cannot connect to my database).
I tried to build the project using .NET 4.x API compatibility level and I have granted the app all the necessary capabilities (*InternetClient*, *InternetClientServer*, *PrivateNetworkClientServer*).
This triggered this exception on runtime : Unsupported internal call for IL2CPP:Module::GetPEKind
Then, I tried to change the API compatibility level to .NET Standard 2.0.
This made the above exception disappear but it still does not work...
Do you have any ideas? I might think that this driver is not compatible with Hololens after all...
Thanks in advance
EDIT
After many attempts, I finally got to this conclusion:
MongoDB C# Driver is currently (as of Unity 2019.1.13f1) not compatible with IL2CPP on Hololens because it tries to make an icall not supported by the latter (very specifically when trying to call new MongoClient()).
I was unable to compile my project on Unity 2018.4 using .NET backend (apparently there are huge compatibility problems with this backend and this is why Unity is dropping it).
Honestly, I am not an expert on UWP at all, but as other people have managed to make this driver work as expected with IL2CPP on "normal" UWP devices, I am guessing that this could be related to Hololens software (I know it uses a special build of Windows 10).
After a lot of tinkering I found a way to make the MongoDB C# Driver work with Unity IL2CPP builds (I tested it on PC and UWP builds, but I guess it works for others too)
For it to work I had to make a custom build of the driver, plus pay some attention to other details.
But before I go into a bit of detail of my findings, here's a link to an example project that I uploaded: MongoDB IL2CPP Example Project (don't forget to change the MongoDBTester.cs to use your instance of MongoDB)
So here's what I did:
MongoDB Driver:
In ClientDocumentHelper.cs of the driver source is a function CreateOSDocument() which contains a section #if NET452 - I just removed that whole section and tried it out in Unity with the IL2CPP build and it solved the OPs NotSupportedException
Unity - Assembly Stripping:
The stripping process removed some code that is actually needed, which I fixed with a linker file - link.xml in the Plugins Folder of my example project.
Unity - AOT and Reflections:
The MongoDB Driver uses reflections for some things, like getting the right serializer for a collection. The AOT nature of C++ builds and the way IL2CPP works don't mix well with that (see Unity Docs - Scripting Restrictions).
Fortunately this is easy enough to work around: If you use generic classes (like Dictionary) you need to specify the Serializer with the BsonSerializerAttribute
For constructors the same issue happens when using constructors with arguments - I just ensure that an zero argument public constructor is available for all classes that are used with MongoDB.
Unity - IPv4:
I'm not sure if this has anything to do with Unity or the MongoDB Driver, or maybe just the server why my instance of MongoDB was hosted, but I encountered a problem that my address protocol was not supported. So I wrote a workaround to use IPv4 instead.
Additional Note:
I noticed that auto-mapping of my classes did not always work. I haven't quite figured out when and why it doesn't work but if this happens just manually map the class with BsonClassMap.RegisterClassMap
Hope this helps, let me know if it works for you or if you encounter any other problems.
I am just getting my feets wet with the new Roslyn compiler platform and i am not quite sure how its auto-compilation feature work (the save file and refresh your browser). As i understand it, it is the Roslyn compiler service that make it possible to auto-compile code just by saving the file. Is this feature exclusively for asp.net 5 ? if so, how comes? I mean, asp.net 4.6 utilizes the Roslyn compiler as well.
And a quick bonus question on the subject. Does the "auto-compile" recompile the hole assembly or is it smart enough to just change the altered parts?
That feature is exclusively for ASP.NET Core as it requires many other building blocks, not only Roslyn.
Yes, ASP.NET 4.6 uses Roslyn, but it only replaces the old compilers and CodeDOM in order to be backward compatible, nothing more.
I am working on a game using Unity3D version 5. The game should use strict business rules already programmed in a C# .NET4.5 engine. Using Xamarin/Mono, we hope to make this usable on windows, android, others...
I tried building the engine into a dll and use it as a managed plugin in Unity. But Unity uses an old version of Mono to compile the whole game and refuses to use .NET 4.5 dlls.
I really need to use this code, I looked into downgrading it to .NET 3.5 but it is not an acceptable solution given the work already done on the engine.
Concerning android, I think to use Xamarin to get native android code and use it as a native plugin in Unity. Now I need a solution for Windows. I am looking into ways to use the C# code in C++ to make an unmanaged dll but I am struggling understanding which way is applicable here between COM interop, C++/CLI or other methods.
Does any one knows a way to include code from .NET 4.5 in Unity with no/little effort ?
Looks like Unity is upgrading to 4.6+ and is available in beta now
https://forum.unity3d.com/threads/upgraded-mono-net-in-editor-on-5-5-0b4.433541/
Using a visual studio plugin: unmanaged exports, I have been able to export the C# .NET 4.5 to an unmanaged/native dll which I can use in Unity Engine.
This forces to call only simple functions, but with little work, it was possible for me to wrap the core of my engine.
Short answer is no.
Unity has ".NET 2.0/3.5 era functionality," according to an official blog post.
According to the same post, a future version of Unity will be upgraded to "a modern version of .NET," with no timeline given for this major undertaking.
NOTE: This answer was written in response to the original version of the question, which was simply whether the .NET 4.5 library could be used directly in Unity.
Is there an API to access Subversion from C#?
SharpSvn is a new Subversion wrapper library for .Net/C# that hides all interopand memory management for you and includes a staticly compiled Subversion library for easy integration. It is probably the only Subversion binding designed to perform well in a multithreaded environment.
SharpSvn is not platform independent, but it makes it really easy to use Subversion from your .Net applications. Several projects switched from other libraries to using SharpSvn in the last year. (AnkhSVN, Collabnet desktop for Visual Studio, SharpForge, to name a few)
Svn.NET is a continuation (fork) of SubversionSharp mentioned in CMS's answer. SubversionSharp is limited to the .NET 1.1 platform.
Svn.NET supports the following platforms:
.NET 2.0 on Windows Platforms
Mono on Win32 (2.0 framework)
Mono on Linux (2.0 framework)
Check SubversionSharp, its basically a C# wrapper library that fully covers the client API of Subversion.
I tried Svn.NET at one point and remember that it didn't do everything that I was looking for. If Svn.NET works for you I'd definitely recommend that route, but if you have problems like I did you can get wild and try using http://www.ikvm.net/ to convert http://svnkit.com/ to a .NET assembly. I definitely got this to work and was experimenting with it in my project when we decided to move away from SVN after all and I shelved the whole thing.