Why C# is an open standard but .NET is not? - c#

Why C# is an open standard but .NET is not? What is the point in this? Why Microsoft decide to open only some part of their .NET?

Various parts of the .NET runtime are indeed standardised by ECMA just like C# - CIL, the CLI, the CLS.

.NET is the runtime and C# is the language. C# can be compiled and run on other runtimes, such as Mono. I am actually not aware of any other runtimes besides Mono, but since the spec for C# is open, you could read it and make your own runtime. ;)

C#, like Java, C, C++, etc. is just a language definition. In and of itself, it does nothing. It defines the means by which a user can define a program or procedure and interface with external libraries.
The .NET framework, on the other hand, is not a language. It's a class library and development framework.

Actually, there is an open standard (ECMA 335 for the runtime api instead of ECMA 334 for the language).
Going beyond this, the source code for Microsoft's implementation of .Net is available and there are multiple separate implementations (the most prominent of which by far is mono).
There is some additional concern about patent encumbrance. However, Microsoft has also issued a legally binding and irrevocable community promise on the .Net platform that covers both specifications (a lot of people miss the legally binding part).

I assume you mean the framework. I guess they want to maintain control over the library implementation on Windows. There is nothing stopping someone from implementing a call-compatible version of all or part of the framework based on their own source as was done by Mono.

Related

How to compile java code from a .net application?

I am creating a source code editor for Java using C# in .NET 4. I need to know how I can interact with the jre to compile the java code on my application editor interface from .net. I wish to display the user any errors on the code as well. Any ideas on how to accomplish this will be greatly appreciated.
Note that the JRE is the runtime, and as such doesn't come with the compiler. You will require the JDK to compile.
I think the simplest solution is to spawn off an instance of javac from within your .Net application. Perhaps a preferable solution (however) would be to write your app in Java itself, and you can then make use of the Java compiler API directly within your app.
Perhaps the most natural interoperability method is to run the Java code in a JVM, the .NET code in a CLR, and use a runtime bridge to manage the communications between them. In this scenario, the .NET code calls .NET classes and objects that act as proxies for the Java classes and objects. The proxies manage the communication; the calling .NET classes aren't even aware that they're ultimately calling Java classes. A runtime bridge provides interoperability for a wide variety of architectures, because the Java code and the .NET code can be on different machines, the Java code can run in a standalone JVM or in a Java EE application server, and the solution provides interoperability for any JDK version. As with bytecode translation solutions, you need only the Java bytecodes, not the source.
The code for this article uses JNBridgePro from JNBridge.

What elements of .NET are missing in Mono?

I mean library and syntax of C#.
For the class library, ask the Mono Class Library status page
C# 3.0 is supported fully.
C# 4.0 version works but considered 'preview' until MS compiler is finalized. There're even some language extensions, although I doubt if they will be ever backported to MS compiler.
You can view Mono's status updates (Like a Timeline, really), from their wiki.
Mono Status Report
There's a pretty in-depth analysis here from January of this year.
The Wikipedia article's "Current status and roadmap" looks helpful too.
There's no equivalent of VT fixup or anything related to unmanaged exports for that matter.
That's not surprising, though. Considering that you would have a hard time using something looking like a Windows DLL as .so or .dylib. ;-)
I am not sure, but mixed-mode hasn't been supported a few years ago when I wanted to use it.
Maybe they added it, but I don't think so. Might be the big fat mother of all worm cans to open for an X platform CLI implementation.
There are three aspects you need to consider.
Language
Framework
Runtime
Language:
Mono fully implements C# 2.0, and has almost complete support for 3.0. This means it supports all of the syntactical language features like generics, properties, anonymous methods/types, etc.
Mono supports Visual basic 8, but not 9.
Framework:
Mono fully implements ASP.NET and ADO.NET. Windows.Forms is mostly done.
WCF and WF are in progress.
WPF is not done, and is many years away from being done (if ever). I believe this is now a side project.
Linq-to-SQL is not yet finished.
Runtime:
The CLR has been almost fully implemented, including support for the DLR.
Your best two sources of information are probably the Mono home page (specifically the FAQ and the Status report), and the Wikipedia page on Mono.
Please have a look at the Mono Project Site or at the Wikipedia-Article.
But the last thing I heard is thet C# 3.0 is complete (except some LINQ-Features).

Is C# used anywhere besides .NET programming?

It's my understanding that C#, though created by Microsoft, is a programming language that can be used or implemented for things other than .NET programming. For example, I could create a compiler for C# to target native x86 or other processors or even a JVM. Is my understanding incorrect? Does anyone know if C# is used for anything besides .NET?
C# is used for an experimental operating system called 'Singularity' which is written in the managed level from the ground up. An interesting project to watch!
Edit: Thanks Jörg W Mittag for his comment - Helios is actually a modified form of Singularity to support satellite kernels, to quote from the paper I am reading right now 'Helios is an operating system designed to simplify the task of writing, deploying and tuning applications for heterogenous platforms. Helios introduces satellite kernels, which export a single uniform set of OS abstractions across CPUs of disparate architectures and performance characteristics. Satellite Kernels allows developer to write applications against familiar operating system APIs and abstractions.'...interesting...
Hope this helps,
Best regards,
Tom.
You are correct that it can be used for other things. It's a language specification...you can compile it into anything you like if you take the time, but it'd be a tremendous effort.
I don't know of any other uses besides Mono as jrcs3 said, but hopefully Eric Lippert will chime in and give you a compiler point of view on C#
C# itself is a specification specified by the ECMA that "specifies the form and establishes the interpretation of programs written in the C# programming language." as is the CLR. The most popular implementation of these is currently provided by Microsoft, which is the C#.net that you know. C# and the CLR are open standards, meaning that anyone can implement them themselves, hence the formation of mono, a C# compiler for mac/linux. Compare this to java, who's only implementation is provided by sun. It's not an open standard, so you can't create your own implementations.
from wikipedia:
Mono "An open source, cross-platform, implementation of C# and the CLR that is binary compatible with Microsoft.NET"
DotGNU "is a part of the GNU Project that aims to provide a free software replacement for Microsoft's .NET Framework"
Dot Net Anywhere is a .net CIL interpreter for targeting embedded systems.
As far as I'm aware, all currently existing implementations of C# build to CIL and run in the .NET CLR or compatible environment, and the only alternative to the .NET CLR I am aware of is Mono.
In other words, all current versions of C# build to run in .NET or Mono.
.NET and Mono use the same 'binaries', so effectively all current C# compilers have only one target.
Another area of use is for iPhone app development (and I believe iPad now as well) via MonoTouch.
What is MonoTouch?
MonoTouch allows developers to create C# and .NET based applications that run on Apple's iPhone and Apple's iPod Touch devices, while taking advantage of the iPhone APIs and reusing both code and libraries that have been built for .NET, as well as existing skills.
Roughly speaking, it goes like this:
MonoTouch -> MonoDevelop/C# -> write an iPhone app -> compiled to native code -> iPhone app.
Relevant links:
MonoTouch
Writing your First IPhone application in C# using MonoTouch
Note that Unity 3D also allows "C# Scripts", and compiles to target Mac, Windows, Web, Wii and iPhone (and therefore iPad).
There are indeed tools to convert a .NET assembly to a standalone executable or library, so that you don't need your clients to have the .NET framework. This also further protects your code against reverse-engineering to some degree -- you can't use Reflector to see the .NET source on a native binary.
See Remotesoft Salamander .NET Protector, for instance.
But, that isn't strictly C# -> native; Salamander converts the MSIL to native code.
On the other hand, there is at least one academic project on making a C# -> native compiler using LLVM, called LLVM#.
You can compile a C# program on Mono. But that probably doesn't count.
Mono is an alternative implementation of the Common Language Infrastructure (CLI) that runs on Linux and various other operating systems. As mentioned in other places, both C# and the CLI are ECMA standards and can be implemented by anyone who cares to do so.
Rotor is another non .NET implementation.
You can use it on iPod apps if you use MonoTouch.

IronPython vs. C# for small-scale projects

I currently use Python for most of my programming projects (mainly rapid development of small programs and prototypes). I'd like to invest time in learning a language that gives me the flexibility to use various Microsoft tools and APIs whenever the opportunity arises. I'm trying to decide between IronPython and C#. Since Python is my favorite programming language (mainly because of its conciseness and clean syntax), IronPython sounds like the ideal option. Yet after reading about it a little bit I have several questions.
For those of you who have used IronPython, does it ever become unclear where classic Python ends and .NET begins? For example, there appears to be significant overlap in functionality between the .NET libraries and the Python standard library, so when I need to do string operations or parse XML, I'm unclear which library I'm supposed to use. Also, I'm unclear when I'm supposed to use Python versus .NET data types in my code. For example, which of the following would I be using in my code?
d = {}
or
d = System.Collections.Hashtable()
(By the way, it seems that if I do a lot of things like the latter I might lose some of the conciseness, which is why I favor Python in the first place.)
Another issue is that a number of Microsoft's developer tools, such as .NET CF and Xbox XNA, are not available in IronPython. Are there more situations where IronPython wouldn't give me the full reach of C#?
I've built a large-scale application in IronPython bound with C#.
It's almost completely seamless. The only things missing in IronPython from the true "python" feel are the C-based libraries (gotta use .NET for those) and IDLE.
The language interacts with other .NET languages like a dream... Specifically if you embed the interpreter and bind variables by reference.
By the way, a hash in IronPython is declared:
d = {}
Just be aware that it's actually an IronPython.Dict object, and not a C# dictionary. That said, the conversions often work invisibly if you pass it to a .NET class, and if you need to convert explicitly, there are built-ins that do it just fine.
All in all, an awesome language to use with .NET, if you have reason to.
Just a word of advice: Avoid the Visual Studio IronPython IDE like the plague. I found the automatic line completions screwed up on indentation, between spaces and tabs. Now -that- is a difficult-to-trace bug inserted into code.
I'd suggest taking a look at Boo [http://boo.codehaus.org/], a .NET-based language with a syntax inspired by Python, but which provides the full range of .NET 3.5 functionality.
IronPython is great for using .NET-centric libraries -- but it isn't well-suited to creating them due to underlying differences in how the languages do typing. As Boo does inference-based typing at compile time except where duck typing is explicitly requested (or a specific type is given by the user), it lets you build .NET-centric libraries easily usable from C# (and other languages') code, which IronPython isn't suitable for; also, as it has to do less introspection at runtime, Boo compiles to faster code.

Reference Java DLL in C# Assembly?

There are instructions here to create a C# assembly using the SimMetrics library. The link they provided to this library is at SourceForge. It looks like the most recent version of the SimMetrics library was created in Java. Is it possibly to compile java code and then reference it in C# to be used as an assembly in SQL Server 2008?
The best you can do is
compile the java as J# (now obsolete and largely unsupported) with minimal code changes.
this is very dependent on how much of the libraries are used.
convert the code to c# (idiomatic or otherwise)
this can sometimes be fairly easy on highly mathematical code. As an advantage the java code likely assumes 16 bit unicode as well.
use something like IKVM to host the java byte code within the CLR
this may be outright impossible with the sql server hosted runtime, certainly I would think the performance would be poor (since you would have to 'thunk' across the hosting barrier on each call.
The SF page strongly implies that there is both a java and a .net release.
Here's the latest .net release and documentation
However based on the read me file in that
This is an updated version of the original .NET implementation and not a conversion of the newest Java Code.
The .Net implementation is largely c# so you could diff the recent changes in the java implementation then attempt to recreate them in the .Net code. Since the conversion to c# seems to be largely a direct copy with only basic consideration given to idiomatic c# (camel casing, properties and parameter names) you stand a good chance of being able to do this.
If you do consider submitting the changes as a patch, this would give you a chance of getting someone else to validate your changes and may jump start the .Net side of the project to be kept more closely in sync in future.

Categories

Resources