I've recently had to some work in Unity that required classes only available in the later versions of .NET, which Unity does not yet support. I managed to download the very few scripts that I was missing and added it to my project and it seems to work fine. What I wanted to know is why can I not just take the entire .NET source and shove it into my projects? What are the implications of doing something like that?
EDIT: The scripts that I have added so far was the generic version of WeakReference as well as any dependencies that it needed (Contract in System.Diagnostics.Contract).
EDIT EDIT: I basically want to know why I can't simply just the C# class files found in the later versions of .NET to Unity, which uses an older version of .NET. Is it a software issue? Is it a hardware issue? Is it because Unity's system components were built in correspondence with the earlier version of .NET?
SHORT ANSWER:
Install the Visual Studio Tools for Unity (it should automatically get installed when you install Unity), when you do you can tell your .csproj in the "target framework" drop-down to target the special version of .NET Unity uses and you will only be able to compile dll's that have methods and types that Unity supports.
LONG ANSWER:
It is because Unity does not use the installed version of .NET on your computer. Unity uses Mono, and a very old version at that. This allows unity to be ran on multiple platforms and OSes. Because of that you can only use features that are in the supported version of Mono.
However, if you look at their roadmap the alpha build you will see
Scripting: C# Compiler Upgrade
Upgrade Mono C# compiler against our
current .Net 2.0 and 2.0 Subset profiles. Note that this is an upgrade
of the C# compiler only, not the full Mono runtime
Then further on in the "research" phase
Scripting: .NET Profile Upgrade
Upgrade .Net profile to 4.6 enabling access to the latest .Net functionality and APIs.
UPDATE:
You can get a experimental build that uses the 4.6 profile from the stickied post here.
Here are the notes for the 5.6.0b5 beta release
For this release, the Editor and the following players should be working:
Windows, OSX, Linux standalone
iOS with IL2CPP
Android with IL2CPP and Mono
Other platforms are known to not work yet, and are probably not worth installing.
Managed debugging via Visual Studio Tools for Unity or MonoDevelop is not supported in this release. If you want to use VSTU for
editing please use the special build linked at the bottom of this
post.
The compiler targets the C# 6 language.
The compiler by default will still target the .Net 4.6 framework profile.
Known issues
The Android/Mono build does not work properly with managed code stripping. Please disable managed code stripping for now.
For some projects, the Windows standalone player can crash on Windows 8.1. This is intermittent, so we would love to see any crash
reports or data about this
A similar question was answered before here. Like I described in your other question, you can "inject" newer stuff and use them, but sooner or later they'll backfire (e.g. can't compile to particular systems, can compile but cannot be published in whatever mobile store, surprisingly slow execution, huge builds, etc. Worst case your project will be compromised).
If you really cannot refactor the project you are working on and you feel you must use 'up-to-date technology', bear in mind the injected classes code must be data objects, means, not at all related to GameObjects.It is also adviced to derive from ScriptableObject when and where possible.EDIT: But I'd recommend what I told you earlier (refactor) or what the linked answer describes ('export' the code incompatible with mono/.net2.0 to an external dll and use it from there)
Related
A while back, I experimented with NuGets while I was working on some programs. Recently (especially when I learned how to make a Direct Linking Library, so two of my programs use any code that is identical), I noticed that there are NuGets made by Microsoft that have names, similar to those shown at the start of every cs file (example: System.IO). I recall that Microsoft was going to issue updates for .NET Framework through these, but I never found how to apply them. So, I'd like to ask the following questions:
Does Microsoft distributes .NET updates for programs written for Framework 4.6.x? If yes, how do I apply them to my program?
Do I need to distribute the DLL files as well when I release an update to a program?
In addition, what do NETCore and NETStandard Nugets do exactly? I tried to install a set of NETCore to a 4.6.2 program, but it couldn't install them due to a dependency error.
Thank you in advance.
.NET Framework itself is considered part of Windows, and Microsoft does provide periodical updates via its channels automatically. Usually you should do nothing, but if your apps depend on specific hot fixes, then you have to ship them in your installers.
Anything you added as NuGet packages becomes part of your apps, and you become responsible to keep them up-to-date. So with your own app updates, you should ship new assemblies from updated NuGet packages.
.NET Core apps bundle the runtime, so you are fully responsible to republish your apps with updated runtime frequently. Check Microsoft LTS/Current support policies at http://dot.net
I'm trying to use the Protobuf C# Port that was developed by Jon Skeet's on a Unity project, but I keep getting errors when I try to build and run a stand alone. I have copied over all the .dll files into the assets and things run smoothly while I'm running unity from developer environment, but as soon as I compile and build I get an error about a "filename unkown".
error image
I haven't managed to find a solution because it seems that most people run into similar issues using Marc Gravell's version of Protobuf. I'd like to stick to the version that I'm using now since I will be working with several languages for this project.
Any help is greatly appreciated.
-- Solution --
It turns out that I had to go into Edit > Project Settings > Player and change the NET version from 2.0 Subset into 2.0
I often find type initialization exceptions occurring because of project reference issues. The two most common causes:
Building your application against a newer version of .NET than the library being referenced (e.g. Protobuf library may have been compiled against .NET 4 while the application is being built against .NET 4.5). You could try resolving that by recompiling the Protobuf libs against the same .NET version as your project.
The compiler assumes a reference is present, but at run time it is not. You can fix this by adding a reference to the specific library (in this case the .NET library with the RegEx object, which is usually System.dll)
I am creating a fresh Mono for android application using http://xamarin.com/monoforandroid
I selected Mono for Android Application using Visual C# option.
My Android target version is :
I went to references of the project and tried adding my pre existing dlls (made in .NET 4 Framework)
and I got this error:
The strange stuff is there is no option to change the .NET Framework from project properties. Can you tell me what I am missing?
The problem here is that you're trying to reference a .NET 4 DLL from a project that isn't .NET 4. Mono for Android uses its own profile for .NET, which is very similar to that of Silverlight (but not exactly the same). While it's possible that adding a DLL compiled for a different profile will work, it's very risky as you will probably run into problems at runtime where your app will crash, due to something being missing from the Mono for Android profile.
The best answer right now is to create a Mono for Android class library, link in the appropriate files from the library you want to use, and reference that. This will give you compile-time checking that you're not using anything unsupported by the Mono for Android profile, and help keep you more sane in the long run. I have an old blog post up here that talks about how to link files across projects.
That said, in this case you're in luck because someone else has already done that last part for you! Check out this fork of Json.NET which provides versions for MonoTouch and Mono for Android.
The strange stuff is there is no option to change the .NET Framework from project properties. Can you tell me what I am missing?
It's not particularly strange - that dialog box was written by Microsoft, with its own project types in mind. It sounds like Mono for Android doesn't have the same options available.
I strongly suspect you'll just have to use a version of JSON.NET targeting .NET 3.5.
(Having said that, Mono for Android claims to support "dynamic language features" which sounds like it should be targeting .NET 4. Odd. I suspect the fix is the same though.)
I'm currently starting to create an application that would profit a lot from C# 5's async-await feature. But I'm not sure which version of VS and of the async runtime to use.
Looking at OS popularity charts, I'll need to support Windows XP for another three years or so. It looks like .net 4.5 runs only on newer versions of Windows, so I need to target .net 4.0. The development machines use Windows 7, so using a newer version of VS is not a problem.
Now I need to first choose a compiler for doing this:
VS2010 with AsyncCTP
VS2012 Preview (and final once it arrives), setting the target to .net 4.0
Mono (Looks like 2.12 has async-await, I prefer/am used to VS over MonoDevelop as IDE)
Which one has fewer code-gen bugs? Looking at Jon Skeet's blog the VS2012 Preview uses a never code-generator than the CTP.
And more importantly which runtime to use?
Does VS2012 contain a redistributable async runtime for use with .net 4?
I managed to compile code, with the preview, by referencing the AsyncCTP runtime. But since the CTP has strange licensing conditions, that doesn't look like a good long term solution.
Or should I use a third party implementation? Perhaps mono has one?
For distributing the library I prefer simply putting the dll in the same directory as the application, instead of some kind of installer.
I'd also like it if my binaries would work without changes on mono+Linux/MacOS. So the runtime should either be compatible with whatever mono (2.12 probably) has built in, or allow use on non windows OSs.
Microsoft released the Async Targeting Pack (Microsoft.Bcl.Async) through Nuget as a replacement for the AsyncCTP.
You can read more about it here: http://blogs.msdn.com/b/bclteam/archive/2013/04/17/microsoft-bcl-async-is-now-stable.aspx.
You can read about the previous version here: http://blogs.msdn.com/b/lucian/archive/2012/04/24/async-targeting-pack.aspx.
As this pack is officially supported, I now believe the best option for targeting XP + async would be using Visual Studio 2012 + C#5 + Async Targeting Pack.
If you feel the need to target .NET 3.5 though, you can still use (my) AsyncBridge for .NET 3.5.
If you are open to considering other .Net languages, F# can solve your problem. It has had the async{} computation expression for years, and is backwards compatible even with .Net 2.0. Minimum requirement is Windows XP SP3. The runtime can be downloaded here.
It's possible to use the VS 12 beta to target .NET 4.0 using async/await.
You need to copy some code into your project that provides the types that the compiler relies on.
Details here
Edit: we've taken this technique and turned it into a open source library called AsyncBridge:
https://nuget.org/packages/AsyncBridge
If you want to be able to distribute your software, I think that the Mono solution is really your only option right now. You also say that you want the end result to run on Mono over Linux and OS X. Targeting Mono to begin with seems like the natural solution.
Your next issue is the IDE. MonoDevelop would obviously work well but you say you prefer Visual Studio.
Greg Hurlman created a profile to code against Mono 2.8 from Visual Studio. If you follow-up with him, he might be able to point you in the right direction for developing against Mono 2.11/2.12 in Visual Studio.
Of course, there is also Mono Tools for Visual Studio which is a commercial product. I assume that it is still being offered by Xamarin.
You might also be able to run the required 4.5 profile assemblies from Mono on top of .NET but I have not tried that. The 4.5 profile is a strict super-set of the 4.0 API. Perhaps give it a shot and report back.
EDIT: It looks like perhaps you can use the Visual Studio Async CTP in production now
Here is what it says on the download page:
Includes a new EULA for production use. Note - This license does not
constitute encouragement for you to use the CTP for your production
code. The CTP remains an unsupported and use-at-your-own-risk
Technology Preview. However, we’ve received many requests from
developers to use the CTP for production code, and so have changed the
license to allow that.
If you want to start distributing your software after MS releases C# 5.0, then you can start developing using AsycnCTP.
Otherwise I wouldn't recommend you to use it, as it is just CTP, not even a beta. It can be changed a lot close to the beta stage and to the release. It may be unstable, etc.
If you want to introduce easy async operations in your application I would recommend you to use Reactive Extensions and stuff built on top (Reactive UI, etc), it is just beautiul.
As for VS2012, it also contains the same Async CTP as far as I remember from my //Build/ tablet MS gave me on that conference.
There's a program written entirely in C# that targets .NET Framework 2.0.
Is there a way I could somehow compile (translate) managed EXE to a native one so it could be .NET-agnostic? I know there are probably commercial products for that purpose... but they are a bit expensive.
The problem is that we are to deploy the program on computers running Windows XP with no .NET Framework installed. There's also a requirement that the program's size must not exceed 500Kb (1Mb maximum) for it is downloaded from the web server (now the size is 255Kb). That is why there's no way we could attach a full-fledged .NET FX (or even a reduced one) to the downloaded program's file.
Obviously it is a terrible software engineering error that should have been detected and avoided earlier so we could use native technologies like C++ instead.
We have tried for now Novell's Mono - an open-source implementation of .NET Framework for Linux, MAC and Windows. Mono consists of C# Compiler, IDE, runtime (CLR) and Class Library assemblies (like System.dll and mscorlib.dll - much like .NET's class library assemblies installed to GAC).
What we tried to do is to locate CLR files and ship those along with our program's file and a few assemblies. This way the program can be invoked by running "mono program.exe" (command prompt) on a user's computer.
In addition to the inconvenience of such a use for the end user CLR files (mono.exe and mono.dll) turned out to be about 2.5 Mb in total that is much greater than the desired 500 Kb or even 1 Mb.
So, we have left with no other option but to translate our .NET App to a native one by a compiler, however the question remains - what compiler should we use and where could we find one...
For now I have stumbled upon a Singularity OS Project by Microsoft Research. It is an open-source research OS that is written in managed code (in part at least). The Singularity OS includes a Bartok compiler that the OS uses in order to translate a managed program to a native one (x86 32 bit). It should be noted that Bartok can't translate all the aspects of .NET 2.0 to a native code, but most of them. However I haven't yet learnt how to use the Singularity...
I would be really grateful to you if you could provide me with some useful tips and advice regarding the problem, your own experience with Singularity OS and Bartok Compiler or another approaches to the problem that I have overlooked and ways of solving it.
Thank you very much in advance!
Finally, using Mono's Full AOT feature (on Callum Rogers' advice) I've managed to produce a program.exe.dll that lacks a CLI header.
So it looks to me like a native dll. However I can't figure out how to convert that dll into exe or make it operational.
Also this dll doesn't seem to expose any functions of interest such as main function.
Check out AOT (Ahead Of Time) Compilation from the Mono project. This compiles your managed project into a native exe or an elf executable (depending on which system you target) that does not need the JIT. This is the technique used to get mono apps onto the iPhone (where the JIT/Framework are not allowed) and also has the added benefits of faster startup times, lower memory usage and it makes it harder for people to decompile your code. You said you were already using Mono, so it should be compatible.
Read up about it at the mono-project.com website and at Miguel de Icaza's blog (and iPhone info).
Note that you cannot use dynamic code or generic interfaces like
interface IFoo<T> {
...
void SomeMethod ();
}
And you will have to compile the DLLs of all the libraries you use.
PS: Make sure to use "Full" AOT for your problem.
2018 Update
At Build 2018, Microsoft announced .Net Core 3.0 roadmap that support Windows desktop applications (Winform & WPF)
2017 Update
For console apps, you can use .net core Self-contained deployments (SCD). Even for a hello world app, your package will 50MB+. You still need to install VC runtime though.
Update
As #jenix's comment, .NET Native is only for Windows Store Apps(UWP). After 3 years of it's announcement, this is still true, .net native for desktop may be dropped by microsoft . So this answer is not applicable anymore.
========
Microsoft Announced .NET Native Preview on Build 2014
With the .NET Native Developer Preview, apps will get deployed on end-user devices as fully self-contained natively compiled code, and will not have a dependency on the .NET Framework on the target device/machine. So, no .NET framework required on the target machine with .NET Native.
Announcing .NET Native Preview
Microsoft .NET Native
There is a project called CrossNet that parses .Net Assemblies and generates unmanaged C++ code, that can be compiled in any standard compiler.
Not really a solution for .NET to native conversion, but maybe this helps: http://www.yoda.arachsys.com/csharp/faq/#framework.required
Not quite sure that there is much you can do besides painstakingly rewrite the application. To ease the already burdening process, you could disassemble the .NET application using something like Reflector (into Microsoft C++), and use that as a base to start and just replace managed C++ references with native ones.