Related
I use Unity with Visual Studio and it's brilliant. But I'm confused about how exactly .NET, Mono and Unity are related to each other. Are these statements right or wrong?
.NET Framework was not designed to be cross-platform.
The goal of .NET Framework is to design programs in a unified way, and they must all run in a virtual machine.
Mono is an open source version of .NET Framework, designed to be cross-platform. Programs built with it can run wherever the Mono virtual machine is installed.
Programs built with Mono cannot run or are not fully compatible with the .NET virtual machine.
Unity only uses Mono for editing, building, and running games.
Games built with Unity have the Mono framework and/or virtual machine embedded in them.
I don't need to have .NET Framework installed for building or running Unity games.
The C# scripts I wrote in Unity are run by a Mono virtual machine, before and after build time. All the Unity engine public code library is C++ wrapped and not actually C#, thus it is running in a C++ side engine.
The Mono framework tools and library are run in-game with a Mono virtual machine.
DLL built with .NET Framework are not fully compatible with Mono.
.Net frameWork was not designed to be cross plateform.
Depends on whether you wish to include say Linux in that. If you are asking if .NET was originally designed to target Linux then, no. However there is the .NET Compact Framework which allowed .NET code to run the Xbox 360 and Windows Phone.
There is now .NET Core, a free and open source framework which is designed for cross platform, specifically Windows, Mac and Linux.
The .Net frameWork goal is to design programs in a unified way, and they must all run and a virtual machine.
Yes. The correct term is Execution Engine by the way not VM though they both are in the same class. Don't think of the EE as something akin to vmWare where CPU instructions are constantly emulated. .NET like Java and are a form of p-code however .NET assemblies are JIT'd to the current CPU so as to improve performance and run natively on the CPU. [1]
Mono is an open source version of .Net frameWork, designed to be cross plateform. Programs built with it can run wherever there is a mono virtual machine.
Yes. .NET Core has the same claims. [4]
Programs built with mono frameWork can not run, or are not fully compatible with .Net virtual machine.
The Mono Framework across it's many versions is not a 1:1 of the equivalent .NET Framework.
e.g.
Mono has no support for WPF in .NET 3.0 [2]
Mono has no support for WWF in .NET 3.0 [2]
Mono has no support for CodeContracts in .NET 4.0 [2]
Unity only use Mono frameWork, either in editing, building and running games.
Incorrect. Unity also uses Unity Script for composing a game.
However there is a big difference for runtime irrespective of your language choice. When targeting say a web browser via Unity Web Player, there is no .NET/Mono EE. The platform is the Unity Web Player. In this sense .NET/Mono is not required on the target platform. [3]
Games built with Unity have embeded mono framework and /or mono virtual machine.
Incorrect, see above
I don't need to have .Net frameWork for building or running Unity games.
Correct
The C# scripts i wrote in Unity are run by a mono virtual machine, before and after build time. All the Unity engine public code library is c++ wrapped and are not actually C#, thus they are running on c++ side engine.
Incorrect, there is no correlation between what language you choose to use to write your Unity game in and whether or not the .NET/Mono EE is present at runtime.
The mono frameWork tools and library are run in game with a mono virtual machine.
Depends.
On your desktop whilst running the Unity Editor? - Yes
Deployed at running on a smartdevice/browser? - no
Dll built with .Net frameWork are not fully compatible with mono.
Incorrect. It is Mono that may or may not be fully compatible with the equivalent .NET Framework. [2]
See also
1 "Is the CLR a Virtual Machine?", MSDN
2 Compatibility, Mono
3 How does the Unity Web Player work?, Quora
4
.NET Core Framework - Go Cross-Platform with the .NET Framework, MSDN
I'm a student and at the moment i'm doing an internship at a company. This internship is about analysing a project. For this project I have made a demo to show to the Marketing director. The demo I have made is a simple project created in Visual Studio 2010 in c# with Windows Forms and a connection to an Access database.
So now i have to show this demo to this director in a presentation but after this presentation the director wants the project on his computer so he can try and use it. The problem is now that the computers here in this company don't have .NET framework 4.0 and the computers are so protected over here that we can't install anything new. To install something you have to go through a procedure that takes weeks.
I have looked al over the internet but all i find is how to install the .NET framework.
Is there any possible way that I can create an standalone exe without the need to install .NET framework? Please help!
If you want to execute an application that is developed using Net Framework 4, you will need to have installed .Net Framework 4 on client computer.
Your application is compiled in CIL (Common Intermediate Language), so it needs to be interpreted by the framework engine.
It is the same if you want to execute a Java program. You will have to install the Java Machine.
The only way you don't need to install frameworks is programming native applications with C, C++.
C# now supports this with .NET Native.
Instead of compiling to intermediate language, it will compile to native code and run with statically linked .NET libraries. Therefore, there will be no .Net Runtime requirements for end-users.
https://msdn.microsoft.com/en-us/vstudio/dn642499.aspx
https://msdn.microsoft.com/en-us/library/dn584397(v=vs.110).aspx
Only works for Windows 10
You can't build a C# executable without .NET Framework. Even if some resources indicate that you can, that only works in theory.
But you could use an older version of .NET Framework like .NET 4.0. If this doesn't work for you, you have to choose a language like C++ which doesn't require CLR at all.
Update 2018:
Do not target .NET 2.0 or 3.5. It's not compatible with the 4.x version. However, .NET 4.0 targeted binaries work with .NET Framework 4.0, 4.5, 4.6, 4.7 and so on. So to reach maximum compatibility, compile with .NET 4.0. You will have to accept that some features will not be available, however, your binary will run virtually anywhere.
(2018: By now, .NET 2.0 - 3.5 has much lower distribution than 4.x)
Delphi is your solution, deploy native bin executables
YES, THIS IS POSSIBLE!
At least 3 ways exist:
1.you can check all OSes that you planning to run your app and build with such version of .NET. As Windows have a built-in framework libs.
Vista -.NET v3.0 -- All service packs
Windows 7 - .NET v3.5 -- All versions and service packs
Windows 8 - .NET v4.0 [Best choice if you are not sure]
Windows 8.1 - .Net v4.5
Windows 10 - .Net v4.6
as they are already pre-installed by default -- no extra install will be needed.
2.For windows 10 you can compile it into native code (but not into CIL) with ".NET Native". This is means that there are no .Net Framework will be needed for apps.
3.There is Turbo Studio (earlier Spoon and earlier XenoCode) that can wrap everything that your app needs and runs it in as a standalone.
From their site:
Turbo Studio
Run .NET Without .NET. Easily embed runtime dependencies such as .NET, Java, and SQL directly into virtual applications. Launch reliably on any desktop, regardless of underlying component installs.
You can use Mono and statically link you program, so your program don't need .NET CLR runtime and act as standalone program.
Mono Project
In more modern versions of .NET such as 5 and 6 and even with releases of .NET Core it had become a supported scenario to produce what is referred to as a single-file executable as well as a self-contained application.
As I understand it, these technologies take place of and build upon some of the capabilities that had been in the Mono development stack for a while now. Typically I've seen this feature used for applications which would be deployed to servers such as web sites and microservices however it could be used for scenarios such as the one that the original poster illustrates.
Using the .NET SDK publishing (producing the executable) for a single-file executable can be done using a command as the one below which comes directly from the documentation.
dotnet publish -r win-x64 -p:PublishSingleFile=true --self-contained true
For more details see Single file deployment and executable in the Microsoft .NET documentation site.
To be honest, it really isnt a problem nowadays. the .NET framework is found on almost every single computer nowadays, and you can even make a installer with Advanced Installer that silently install the .NET framework on your computer when you are installing the programme.
I'm a newbie to programming, and I'm considering using C# to write a VERY simple program that simply edits a text file.
Will it work on Macs and Linux? What will work?
I want to know what makes a program cross-platform?
C# can be compiled for and ran on multiple platforms (Windows, Linux, macOS) by using .NET Core.
Previously, cross-platform development using C# could only be done by using Mono which is a third-party implementation however it is now recommended to use .NET Core as it is developed by Microsoft.
Now C# is fully cross platform and has variety of frameworks and run times.
Java is a language + framework. But C# is just a modern language. C# language features are very powerful, easy to learn. No confusion between framework and language.
C# can be used in following frameworks
.Net core (Multi platform supports Linux, Windows and Mac), mostly used to develop restful services, web applications and enterprise systems
.Net Framework (Windows only), Same as .net core, but has more windows only features
Unity - One of most used game engine to develop games for PC, Sony, Xbox devices etc..
Xamarin - To develop native Mobile apps (Android, IOS, Mac)
.Net standard - Create a library in .net standard use in all above applications
Java - Code once, Ship same file to all platforms
C++, C, Rust - Code once, Compile for specific platform
C# - It is just a language, pick your framework according to requirement.
Most popular applications like Chrome, Firefox uses C++, Rust and they are compiled for each platform. But still they share the majority of code between these platforms. Some games use C++ to share the code between IOS and Android.
For new developers its good to start with NodeJS and C#. Both are easy and can do any type of applications.
It's hard to answer something like that to somebody, which states that he just starts programming, but I'll try to give you an (somewhat simplified) overview: C# is a language, which is compiled into an executable program. The language itself is portable between plattforms, as long as you have a compiler on each target plattform. On Windows you have the "default" .Net implementation and on Linux/Mac you have Mono. To do something useful - like editing files - you have to use some libraries. There is a standard library which is available on each plattform. As long as you use only that functionality, your program will be cross plattform. Obviously is will not be cross plattform, as soon as you use some library specific to a certain plattform. Editing files is part of the standard library, so you can implement such simple tools in a cross plattform way. When choosing a book, you should look for books which focus on the "raw" language and not on Visual Studio or other specific tools.
A new open source release from Microsoft called CoreCLR is cross-platform and can now be used for this
The CoreCLR repo contains the complete runtime implementation for .NET Core. It includes RyuJIT, the .NET GC, native interop and many other components. It is cross-platform, with multiple OS and CPU ports in progress.
-from the CoreCLR repo
I would not recommend c# as the top choice for multiplatform coding. I would recommend python instead it is very easy to run even as a script and works perfectly on all platforms. If you insist on c# be prepared to deal with the same problem explained by Justin Ethier. Python on the other hand, is the same for all platforms, it is super powerful fast and even has wrappers ready to connect to other languages.
C# is cross-platform thanks to .NET Core, but without a cross-platform User Interface library you can only make very basic console programs with it. In order to make cross-platform apps for Windows, Mac and Linux you need a cross-platform User Interface library like Nevron Open Vision
Yes, C# is fully cross-platform thanks to .NET Core.
.NET Core is a free and open-source, managed computer software framework for Windows, Linux, and macOS operating systems. It is the cross-platform successor to the .NET Framework which only run on Windows. The project is primarily developed and supported by Microsoft (through the .NET Foundation).
C# is cross platform and you can run your program in Windows/Linux and Mac. For Linux, though, you need to run it using mono
as jvm makes java as plateform independent is it possible with CLR to make .net framework supported languages like c# plateform independent on mobile
Yes, you can use the Mono CLR. Mono is the open source implementation of C#, .NET BCL and the CLR.
MonoTouch runs on the iPhone
MonoDroid runs on Android devices
Yes-ish. At the tooling level, see MonoDroid, MonoTouch or the WP7 tools. However, in each case you are using the language to target a specific mobile platform. You may need different UI code for each, even if the core code is shared.
.NET Compact Framework works on mobile devices (and has for about 8 years now). .NET is also cross-platform (kind of) through the Mono and MonoTouch projects.
Technically, yes, but each handset has it's own limitations that may not make it very feasible.
If you look at the mono-project, it's a portable implementation of the CLR which can target mobile architectures, but it's still an area of development and not very mature yet.
MonoDroid is the project targetting Android handsets, but it's in a beta stage at the moment.
MonoTouch can target iOS, but it cannot take full advantage of the framework. Apple's licensing prevents virtual machines from running on the iOS, so .NET applications need to be AOT (Ahead-of-time) compiled to run on it. This works, but you won't be able to use parts of the BCL like the reflection API.
There's some early development for mono to support WebOS (Palm) too.
I have used C# in Visual Studio with .NET, and I have played around a little with Mono on openSUSE Linux, but I don't really understand how it works.
If I write an app in Windows on .NET, how does this relate to Mono? I can't just execute an a Windows .exe file on Linux without Wine, so it doesn't help me execute apps developed in Windows.
Is the purpose purely to have a .NET library equivalent on Linux (and others) to make cross platform development easier? For example, if I was a business and wanted to reach Linux customers, but really wanted to use .NET, then Mono should be my choice? Or is there something more that I'm missing?
This is an old question (with an already selected answer) but I do not believe the question has really been answered well.
First, a little background...
How does .NET work?
A traditional Windows .EXE file is a binary file that represents a series of machine language instructions that your computer understands and that makes calls into the Win32 API which are parts of Windows that deliver services that applications can take advantage of. The machine language used is very specific to your kind of computer and the Win32 calls make the executable very dependent on Windows. A .NET executable is not like that.
It is important to realize that a .NET executable (.EXE file) is not actually a native Windows application. Windows itself does not understand how to run the code in a .NET executable. Your computer does not understand it either.
Much like Java, a .NET application is made up of instructions in a language called CIL (Common Intermediate Language) that you can think of as the machine language for an idealized computer that does not really exist. In .NET, the software implementation of this idealized machine is called the Common Language Runtime (CLR). The equivalent in the Java world is called the Java Virtual Machine (JVM). In Java, the equivalent to CIL is called Java bytecode. CIL is sometimes called MSIL (Microsoft Intermediate Language).
CIL is designed to run on the CLR (an idealized machine) but is otherwise platform independent, which means that the CIL does not care what kind of computer you have or what operating system you are running.
Just as you need a native version of the Java JVM on each platform on which you want to run Java, you need a native version of the CLR to run .NET CIL executables. The CLR is a native Windows application just like the traditional Win32 EXE files described above. The CLR itself is specific to the Windows implementation and computer architecture on which it was designed to run.
It does not matter what .NET language you start with (C#, VisualBasic, F#, IronPython, IronRuby, Boo, etc.), they all get compiled down to CIL bytecode. You can easily "disassemble" a CIL program into a form of object-oriented assembly language that is easily readable by humans. You can write a program in CIL directly yourself but few people do.
On Windows, the CLR compiles this CIL code Just-in-Time (JIT) right when you run the executable--just before the code is actually run. This means that the CIL bytecode is converted (compiled) to actual machine code that runs natively on your computer. This part of the CLR is called the JIT compiler or often just the JIT.
To date, Microsoft has released four versions of the CLR: 1.0, 1.1, 2.0, and 4.0. You need to have the right version of the CLR installed on your machine if you want to run .NET executables targeting that runtime. The CLR 2.0 supports .NET 2.0, 3.0, and 3.5 applications. For other versions of .NET, the .NET version maps cleanly to the CLR version.
In addition to the JIT/CLR, .NET provides a host of libraries (assemblies) that make up the rest of the .NET framework and that provide a host of capabilities and services that .NET applications can call upon. The great majority of these assemblies are pure CIL code which runs on the CLR. On Windows, a some make calls into the Win32 API as well. When you install .NET, you are installing the CLR, the class libraries (framework), and a bunch of development tools. Each version of the CLR generally requires a complete set of these "framework" assemblies. Some versions of .NET (eg. 3.0 and 3.5) added additional framework assemblies without updating the CLR or the existing assemblies associated with that CLR.
The Portable Executable (PE) file format that a Windows .EXE file is delivered in contains a header that describes the executable and identifies the file as a .NET file or a native Win32 file. When Windows tries to run a .NET file, it sees this header and automatically invokes the CLR on your behalf. This is why .NET EXE files appear to run natively on Windows.
Ok, so how does Mono work?
Mono implements the CLR on Linux, Mac, and other platforms. The Mono runtime (the CLR) is a native application written mostly in the C language and compiled down to machine language code for the computer system on which is designed to run. Like on Windows, the Mono runtime is specific to the Operating System and kind of machine you are using.
Just like on Windows, the Mono runtime (the CLR) compiles the CIL bytecode in your .NET executable Just-in-time to native code that your computer can understand and execute. In this way, a .NET file is just as "native" to Linux as it is to Windows.
To port Mono to a new architecture you need to port the JIT/CLR. This is just like porting any native application to a new platform.
How well .NET code runs on Linux or Mac is really just a question of how well the CLR is implemented on these systems. In theory, the Mono CLR could execute .NET code on these systems much better than the MS version of .NET does on Windows. In practice, the MS implementation is generally superior (though not in all cases).
In addition to the CLR, Mono provides most of the rest of the libraries (assemblies) that make up the .NET framework. Just as with the Microsoft version of .NET (in fact more so) the Mono assemblies are provided as CIL bytecode. This makes it possible to take a *.dll or *.exe file from Mono and run it unmodified on Windows, Mac, or Linux as CIL is the "native" language of the CLR implementations on these systems.
Just like on Windows, Mono supports multiple versions of the CLR and the associated assemblies:
Very early versions of Mono (before 1.2?) only supported CLR 1.0 or 1.1.
Mono did not support big chunks of the 2.0 framework until it's own 2.0 version.
Mono versions up to version 2.4 supported both CLR 1.1 and CLR 2.0 applications.
Starting with Mono 2.6, CLR 4.0 was added but CLR 2.0 was still the default.
Starting with Mono 2.8 the CLR 4.0 became the default and the CLR 1.1 is no longer supported.
Mono 2.10 continues to use the CLR 4.0 as default and also to support the CLR 2.0.
Just like the real .NET (but in far fewer cases) there are some Mono assemblies that call into native libraries. In order to make the System.Drawing assembly work on Mono, the Mono team wrote a Linux program to simulate the GDI+ portion of the Win32 API on Linux. This library is called 'libgdiplus'. If you compile Mono from source, you will notice that you need to build this 'libgdiplus' file before you can build 'mono'. You do not need 'libgdiplus' on Windows because the GDI+ portion of the Win32 API is already part of Windows. A full port of Mono to new platforms requires this 'libgdiplus' library to be ported as well.
In areas where the design of the .NET library is overly influenced by the design of Windows, and a poor fit for systems like Mac or Linux, the Mono team has written extensions to the .NET framework. The Mono extensions are also just CIL bytecode and generally work just fine on .NET.
Unlike on Windows, Linux generally does not detect .NET executables and launch the CLR by default. The user must usually run the CLR directly by typing 'mono appname.exe' or something similar. Here 'mono' is the application that implements the CLR and 'appname.exe' is the EXE file that contains the .NET code to be executed.
To make things easier for users, Mono applications are often wrapped in a shell script that launches the CLR. This hides the fact that the CLR is being used just as in Windows. It is also possible to tell Linux to launch the CLR when a file using the PE file format is encountered. This is usually not done as the PE file format is also used for native Win32 Windows executables which of course the CLR (Mono) does not support.
There is no technical reason why a PE launcher could not be used by Linux which then launches either a system that understands native Windows code (like Wine) or the CLR (Mono) as appropriate. This has simply not been done to my knowledge.
Back and forth
Any .NET code that sticks to "fully managed" code, which means it does not call into non-.NET code, should work fine on Mono on all platforms. I routinely use compiled .NET assemblies from Windows (for which I do not have the code) on Linux and Mac.
I can also take any code that I compile on Mono and run that on .NET on Windows. I can provide a client some code I compiled with Mono and not worry if he is on 32-bit or 64-bit Windows for example. The client does need to have the right version of .NET (the right CLR) installed fo course. CLR 2.0 has been around for a very long time and you can bet almost all Windows users have it installed. The Mono compilers and other code are also just CIL executables and so they run fine on Windows if you like.
Mono compatibility is good enough that large chunks of actual Microsoft code, like ASP.NET MVC, can be taken (where legal to do so) from the actual MS version of .NET and run on Mac or Linux. In general, the Mono team has done a great job of implementing both the CLR and the rest of the framework (class libraries/assemblies).
ASP.NET
On Windows, the Internet Information Server (IIS) knows how to call into the CLR to execute .NET as part of a web application. On Linux/Mac there is an Apache module (mod_mono) that provides similar capabilities to the Apache webserver. This application is written in C and must also be ported to new architectures.
Porting Mono
This discussion has identified parts of Mono that are built as "native" executables and must exist on a system on which you want to run .NET applications.
The CLR (including JIT compiler) - generally known as Mono
libgdiplus (for systems which do not natively support the GDI+ API [only Windows does])
mod_mono (to allow Apache to invoke the CLR for .NET web applications)
These three components, with the addition of the class libraries, provide a .NET environment that looks "native" to the .NET executable files you need to run.
That is how Mono works.
A Windows EXE contains multiple "parts". Simplified, the .net Code (=MSIL) is only a Part of the EXE, and there is also a "real" native Windows Part inside the EXE that serves as some sort of launcher for the .net Framework which then executes the MSIL.
Mono will just take the MSIL and execute it, ignoring the native Windows Launcher stuff.
Again, this is a simplified overview.
Edit: I fear my understanding of the deep deep details is not good enough for really much detail (I know roughly what a PE Header is, but not really the details), but i found these links helpful:
NET Assembly Structure – Part II
.NET Foundations - .NET assembly structure
You can in fact run a .NET .exe file with Mono on Linux. This does not require Wine. In fact, Mono compiles programs to .exe files, which can run either with Mono on Linux or as an executable on Windows.
Mono is an open-source implementation of Microsofts .NET CLR (Common Language Runtime). This is what runs part of .NET programs which are not in native code but in CIL (Common Intermediate Language), a language and machine-neutral intermediate language. The Runtime takes that intermediate code and translates it into machine code.
At the current state of Mono, you can take .NET programs that use the main parts of .NET (mscorlib.dll) and run them everywhere Mono runs, not just Windows.
But as it is mentioned that Mono is open source and you can't just rely that it will be the full .NET implementation, it has some controls that are not working, you must be also careful with P/Invokes that your application will use, for e.g your application will communicate with MCI (Multimedia Controller Interface) under win32. But I was using mono writing GTK# Applications also, but I've also used my Windows applications that worked without any recompilation as mentioned our fellow programmers above, that is, mono is an open source alternative of Microsoft's .NET, and by default if you are building either WinForms or Gtk# applications mono will compile and will create an .exe assembly for each file, and of course if you want it will create an Dynamic Link Library (DLL), almost as it is done in .NET. Just for suggestion try writing some Gtk# (with MonoDevelop IDE which has its built-in gui designer called stetic). And of course mono can be a great replacement for Web Services that you can create them on .NET and you can host them on Apache (because Linux hosting nowadays are more cheap than Windows ones) web services and other asp.net apps will work under apache with a mod_mono module that must be included in apache.
A little bit out of topic but I just wanted to tell you a sneak-peek from my experience.
Also you can take a look to MoMA (if your goal is to port applications from Win to Lin).
The Mono Migration Analyzer (MoMA)
tool helps you identify issues you may
have when porting your .Net
application to Mono. It helps pinpoint
platform specific calls (P/Invoke) and
areas that are not yet supported by
the Mono project.
MoMA
Here is a webapp that compares the types of the BCL already implemented by Mono and the .NET Framework 3.5
http://mono.ximian.com/class-status/2.0-vs-3.5/index.html
To further Michael's response, I believe you will have to recompile on Mono for the app to run on the Mono runtime. Exceptions may exist. I've only played around with Mono just a bit, and I've always re-compiled the source. I've never tried to run a .NET app directly on Mono.
Also, Mono 1.9 is supposed to be fully .NET 2.0 compliant. Mono Olive and Moonlight are supposed to add .NET 3.0 (less WPF) and Silverlight functionality.
It might help you, How does Mono's C# compiler work? and as well as Understanding Mono C# Compiler book.