How does C# run on other platforms?

Asked

Viewed 519 times

6

As a complement to this question, run C# on a system where . NET Framework is native, it is default to run the application executable. As far as I know, C# depends on the . NET Framework to be compiled and executed, and thus have all code functions running natively on your platform.

But what about Linux? I know that without . NET Core installed it will not be able to run an application natively from . NET, but this requires its installation in the machine.

When I run an application that was written in C# on a mobile phone, I install no dependency, the application runs natively and stably, and without the . NET Framework. How does that happen?

Is there a sub-platform . NET Framework on all . NET Core compatible devices? Or does . NET Core adapt on platforms? If yes, how does it do that? Is there any significant performance loss?

  • 1

    I do not have enough information to prepare a response, but mobile, the code is already compiled to target platform, will not be a program . net...

  • @Rovannlinhalis why it is not so on all platforms?

  • 2

    Rovannlinhalis is half right. For example: Xamarin.Android bundles IL code ( .NET platform code) together with the specific platform’s Jitter and its dependencies. Thus the code that is in the device is code . NET.

  • I do not know if I understood the purpose of the question well. But basically it is the same thing as qqr normal application, is generated "machine code". In the case of Android, IL code is generated that goes bundled with the VM (Mono, I think) and a Jiter. In the case of iOS is generated machine code from the IL code (it was so before, I can not say that it is still). I just don’t know how the issue of memory management works on iOS, since there is no way to have a Garbage Collector. I imagine that the IL -> machine code conversion has something to manage memory. I would need to give a read p/ understand.

3 answers

7


But what about Linux? I know that without . NET Core installed it won’t be able to run an application natively from . NET, but this requires its installation on the machine.

This is not true. The . NET Core is not . NET Framework precisely because of this. It does not need to be installed. It actually can’t even be installed. It’s an SDK that you use in your development environment and a library that goes along with your application. You can use part of the SDK to share the environment if you want.

When I run an application that was written in C# on a mobile phone, I install no dependency, the application runs natively and stably, and without the . NET Framework. How does this happen?

This is another case. It uses Mono (starting from .NET 5 Mono will no longer be used, what was called .NET Core can solve this in this version) which has the ability to generate native code directly, without needing a Jitter, even as required by the platform itself (iOS). It generates the executable as well as C or C++ generates.

Actually there is the . NET Native which also does this, but is only available for some types of application. Also it will no longer be used.

They use a normal compiler that generates native code. This is normal, strange is what . NET Framework does.

Is there a sub-platform . NET Framework on all . NET Core compatible devices? Or does . NET Core adapt on platforms? If yes, how does it do that? Is there any significant performance loss?

No, that doesn’t make any sense. O. NET Framework is part of the Windows operating system, so it tends to be little used, since today there is demand for something more standard.

The . NET Core has quite superior performance at various points, the . NET Native even more (in fact this has been reversed). Mono, and therefore Xamarin, performs worse at some points, but is improving, but when used with native code may be faster than . NET Framework.

The . NET Framework will tend to be used as legacy from next year when what is missing for Windows will be available to it. Even more than he died.

I would love for everything to be native, but it has technical limitations that some applications cannot accept. There is less control and less reflection capacity, which prevents a number of libraries from functioning. In some cases it may require duplication of content, which is not desirable.

The graph of the other answer is obsolete (actually the answer does not answer what was asked and speaks of the .NET Standard that was not asked), and now in my last issue here it is more obsolete yet.

  • @Williamjohnadamtrindade no, only the AP.

  • But the idea of using an intermediate language that would be run by a virtual machine (CLR in the case of .NET, equivalent to JVM for Java) was not the proposal for the same application to run on multiple platforms. It would be enough to create a VM for the platform and the application would run smoothly. That was not the promise, at least in 2002, when the . NET was released?

2

First keep in mind the image below:

inserir a descrição da imagem aqui

The . NET FRAMERWORK, . NET CORE and XAMARIN, they are all compliant with . NET STANDARD.

The . NET STANDARD is a specification and not a framework. "The . NET Standard is an interface, a kind of contract that defines the list of Apis that that particular version of . NET should support."

If you inspect the repository on github you will see a set of empty methods and/or null-returning functions. See System.Console.Writeline, for example:

public static void WriteLine(string value) { }

inserir a descrição da imagem aqui

Any developer can create their own framework for a specific platform (example .NET CORE for Z80 MSX), as long as they respect the . NET Standard.

Today you have XAMARIN (iOS, OS X and Android), . NET CORE (Windows, Linux and macOS) and . NET FRAMEWORK (Windows). Note that some assemblies of . NET Framework are not part of the Standard, example System.Windows.Forms, and will probably never be part of it.

That is, a Framework conforming to . NET Standard is allowed to add Assemblies that are not part of . NET Standard, but not allowed to modify or remove Assemblies that are already there.

To learn more I suggest the article of MVP Eduardo Pires: .NET Standard - You need to know!

  • 1

    "It is a set of empty methods and null return functions" That doesn’t sound right. The NET Standard contains the contract (just as we use interfaces in our codes) that needs to be followed by those who implement it.

  • 1

    @Linq agree. I wanted to simplify as much as possible and it got bad. I’ll rephrase.

0

The . Net derives from the ideas of JAVA.

Sun, which was struggling to cope with many platforms, developed the concept: "Write Once run Everywhere": "write once and run anywhere".

How would it be possible to run the same code on an embedded chip and an x64? The solution at the time (and java to this day is like this), was to abstract the programming language, the developer writes the program in a generic language, this code is compiled in an intermediate bytecode, and this bytecode is distributed.

When running a JAVA program, the java machine (jre, java Runtime Environment, which is platform-specific) converts the bytecode to native code, loads in memory, arrow the execution pointer and ready, you have your native code running on multiple platforms.

In the end you end up having:

1 JAVA compiler.

1 intermediate byte

n Runtime environments (one for each platform)

Instead of having n compilers for each platform.

I really don’t see much advantage in that, from an engineering point of view, compared to having n compilers. Actually there is a setback: programs take longer to start.

Microsoft followed this model, but adapted the content to several languages:

n compilers (one for each language).

1 intermediate language

m Runtime environments (one for each platform)

The advantage of this is having: n+m programs, if you had a compiler for each pair (language, platform) would result in n*m programs.

The one installed on Linux to run applications. Net Core is the Runtime environment, but it is possible to generate a program compiled with built-in Runtime (which generates a very large program).

The Runtime environment calls the native functions when needed and handles operating system pointers and handlers.

There is great anxiety on the part of developers to generate native code from . Net, and this is one of the decision factors when choosing a language/compiler.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.