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.
Related
Can a C#/.NET application be compiled to native binaries using .NET Native without being a UWP application? For example, a 4.5 console app? I've watched over 2 hours of video on .NET Native and also read docs but they did not clearly answer this question.
There are not a perfect solution for this but serveral alternatives:
Native AOT, formerly called 'Core RT', which supports full native compilation from managed dlls to binary executables on the target platform(OS and CPU Arch), but it is still marked as 'experimental' (Update: merged into the mainline since .NET 7 preview) with a lot of features missing.
IL2CPP, which is developed and used only by Unity.
CrossGen, which is a part of CoreCLR and could generate .ni.dll files which contains precompiled (native code on specific platform) code rather than IL code in normal managed dll, making it faster loading. But it still requires the runtime because it is basically still a managed dll with JIT compilation already done (AOT).
Note that .NET Framework is going to be obsolete with .NET Core becoming the unified .NET, and you can easily hear from some news about native compilation support if you keep watching .NET Core things
My goal is to play an audio clip (any format really) in a .NET Core 1.1 Console App for C#.
I've tried different libraries like IrrKlang, PortAudioSharp and neither of them work. They either requires an external DLL like mscorlib.dll, or simply isn't compatible.
What choices are there, that isn't too low-level? I need a simple and easy "Play Audio" - "Stop Audio".
I appreciate all the help that I can get!
There is a discussion about this in the official repo.
https://github.com/dotnet/core/issues/74#issuecomment-232456726
Looks like there is no easy and ready to go solution for this yet. .NET core was written from scratch. So any library to be compatible with .NET Core, it has to be rewritten from scratch too or at least modified to be compatible with .NET Core. ManagedBass library could be useful to you. But as described in the forum, it is still a P/Invoke binding to low level library.
Unity uses Mono in order to achieve multi-platform compatibility.
Because of that it wouldn't make sense to use .NET 4.0 or higher, since Mono does not support them either.
However Mono does support 3.5, in fact it supports most of its features , so I wonder, why does Unity still use version of .NET that is almost a decade old.
I understand that most if not all developers prefer stability and familiarity over cutting edge. I would just like to know what are possible reasons for this decision. Especially since later .NET versions introduced several very nice features.
Compatibility reference for Unity.
According to this site it has to do with the support of other computers. Most computers will be able to run .NET 2.0 but not 3.5. It also runs C# 4, I believe, 5, but definitely not C# 6. For some reason, they're kind of behind on things. I think its because there's little benefit of doing upgrading everything.
.net 2.0 and it's subset is there for apiCompatiblilty that being said it's for using of 3rd party libraries but you can use .net 3.5 features in your code as you have stated that mono supports it for example system.linq, although there is some limitations on it for example some namespaces are not available for example :
system.data , also linq has some constraints on mobile platforms http://forum.unity3d.com/threads/to-linq-or-not-to-linq.223887/
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.
Two Questions:
Is there any way to write cross platform programs on Microsoft Visual Studio?
If there isn't then could I write a C# application on VS2008 and recompile it with MonoDevelop and have it work?
1 - I dont' think so. Not without something like Mono.
2 - Yes you can, but Mono doesn't cover all the framework - they are working on it.
The best thing to do is check with the Mono Migration Analyzer. The Mono Migration Analyzer (MoMA) tool helps you identify issues you may have on Mono - http://mono-project.com/MoMA.
I have found most of my .NET 2.0 applications can be converted, but you may need some tweaks.
You can always use C++ and QT. Soon QT will be released on LGPL license (from version 4.5) that will give some more freedom.
The only limit of using free QT license is that you don't get integration with VS. However this can be handled by using eg. CMake (which will generate VS solution files).
Yes, Write your code, compile and run on another platform using Mono. When you compile you generate IL, which Mono can use. Note: Some functions aren't available on Mono. Delphi Prism, is an add on for Visual Studio which allows you to code to Linux and Mac from VS albeit in the object Pascal language though.
Yes, see same issues as in 1
I agree with Joe90, just one thing he left out: MonoDevelop can compile .sln and .csproj files because it has a MSBuild implementation.
So point MoMA at your code and if you get a green light it should compile as-is in MonoDevelop.
As a MSCLR junkie I have to admit that Mono has a few 'better' implementations of certain critical functions (mostly to do with encryption). You will get more usability power from these.
Another thing to watch out for is subtle logic errors. If a class is implemented in Mono it does not mean that it will behave the same the MSCLR one (Mono is a cold-room implementation and as such they DO NOT use the original source code). This is really where you will get good results from a well unit-tested code base.
For a good indication of what you should expect, I remember seeing a large amount of #if MONO in the AgsXMPP repository.
You could ideally write a C# application and have it run on the Mono platform. BUT, that will depend on the libraries of MS .NET that has been ported yet to Mono.
Just in case, there is no language constraint, you could consider using other languages like Java, Python, Ruby and the like..
Good Luck!
As many others mention your success will depend on the libraries you use. Mono does have Winforms but I would suggest that you also look at GTK# http://www.mono-project.com/GtkSharp as your windowing library. If you use GTK# you will use a library which is not reverse engineered (as Winforms is in Mono).
My understanding is that "non-gui" .NET 2.0 stuff is pretty much in place with the newest versions of Mono
You don't need mono develop, the whole idea of mono is you can develop for .net and have the same assemblies work on both mono and .net, provided you only use stuff which has been implemented in mono.
Stuff which won't work:
pinvoke,
wpf,
linq to SQL
Stuff which will work:
.net 2.0,
c# 3.0 (including linq to objects and linq to xml),
winforms
If you write your application in Silverlight, anyone with a web browser and the Silverlight plugin can access your app. This is as cross-platform as you're going to get with .NET.