I have a little library which relies hugely on Emitting classes and methods.
I want to migrate it to .Net Standard because it doesn't use any unmanaged things so can be easily running on whatever OS. But when I ran Portability checker on my solution, it showed that everything is OK with my Expression generator part, but it is whining on Emit usages.
Here is analysis for net452,netstandard1.6 and netstandard2.0.
My question is if there is some modern and recommended way to generate classes at runtime which is supported by .Net Standard or I can just forget about porting my library to it?
Well, I found that nowadays in .Net Standard we have expression trees to generate standalone delegates and old fashioned Emit (available with System.Reflection.Emit and System.Reflection.Emit.Lightweight namespaces) for the rest. Unfortunly, we lost bridge between the former and the latter (I mean LambdaExpression.CompileToMethod, see question).
So generaly there is almost same code generation power as in full desktop .Net until you don't need to generate types at runtime (implement some interface on the fly, for example). In this case you are forced to emit IL manually.
Related
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.
Is it true that all operations on the dynamic type are dispatched to the DLR? From this video, it looks like but they don't say it in so many words and I just want to be sure that the statement is right as I was about to write it in some communication.
They also say that the DLR is currently in System.Core.dll.
I want to know if the DLR has its own assembly or namespace.
I am browsing through the DLR source and it looks like it does have it resides in Microsoft.Scripting.dll but I can't be sure. Did the DLR also ship with .NET 3.5?
Yes, dynamic operations are implemented by the DLR.
The DLR did not ship with .NET 3.5.
The old namespace was for versions of the CLR which did not include the DLR, like 3.5 SP 1. Also for new DLR features not included in .NET 4.
No, the DLR Codeplex source is not what's in the .NET 4.0 framework. Not directly anyway. I'm seeing big chunks of it back in the System.Core.dll assembly, System.Dynamic namespace. To what degree that moved code is identical to the DLR source is hard to guestimate. It looks identical at a cursory glance but you'd need a fine-toothed comb to be sure. The 4.0 source code is available from the Reference Source, just not in a format that makes it easy to run a diff on the source code files. A spot-check on ExpandoClass.cs shows they are very nearly identical with just an added (unnecessary) using directive in the 4.0 version. Given the amount of work done on the DLR previously, I would estimate the changes to be relatively minor.
Note that there is an intermediary layer between the calls generated by the compiler and the DLR. It goes through the classes in the Microsoft.CSharp.dll assembly first, the binder for the C# language. Exactly where that binder ends and the DLR begins is very hard to reverse engineer. The binder code is not easy to read and does a lot of work. Calls to methods in the System.Dynamic namespace are interwoven. And its source code is not available from the Reference Source.
Given the amount of code in the binder, my answer to your question "are all operations on the dynamic type dispatched to the DLR" would be: no, probably not all of them.
When you're using C# with "dynamic", one important player is the C# runtime binder. This component is not part of the DLR, though its functionality depends entirely on the DLR infrastructure. It is located in the assembly Microsoft.CSharp.dll.
I'd recommend to start with MSDN: http://msdn.microsoft.com/en-us/library/dd233052.aspx
Basically, DLR exists in two versions: one ships with .NET 4, another one is open-source version on codeplex.
The DLR in .NET is a part of the System.Core. However, languages and frameworks need their own binders to work with the DLR. In case of C#, this is C# runtime binder, which is in Microsoft.CSharp.dll. So, whatever you declare "dynamic" in C# is first processed by the C# runtime binder and then goes to DLR.
The DLR on codeplex obviously needed its own DLL (which is now Microsoft.Scripting). Basically, DLR started when IronPython guys realized that what they did can be used in more places than just IronPython. So they refactored the code and created a separate DLR layer. This DLR layer was later incorporated into .NET and this is there the two versions forked.
The .NET version is in fact has fewer features than the open-source one. So, if you want to let's say develop your own dynamic langauge on .NET, use the open-source version. If some MS team decides to support dynamic features (like Silverlight did), they usually have to work with the one that is in the .NET Framework.
If you just use C# dynamic features, you basically don't need to worry about DLR at all (the only interesting thing for you might be the System.Dynamic namespace that provides some nice classes such as ExpandoObject and DynamicObject). One more namespace heavily used by DLR (but not strictly a part of it) is System.LINQ.Expressions that is used for operations with expression trees. It was extended for the DLR in this release and you can find it in both the DLR open-source version and .NET Framework.
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.
Something I'm not to clear about, I understand there are differences between C# and VB.NET (mainly in the use of pointers) but why if both have a Common CLR, does XNA (for example) only work with C# and not VB.NET, or is it that the add ins to visual studio have been aimed at C# rather than VB.Net, and infact the language extensions work in both
Sorry if it's a obvious question, thought I'd ask
It's the tool set that defines the language support. XNA, for example, simply did all their work with C# and only shipped support for it. You could still write an app in VB.NET and manually compile it from the command line. As long as your app didn't compile down to any illegal IL (opcodes that XNA doesn't support) it will still run. The primary issue is resources - they don't have the manpower to do full development and testing of all of the languages, so they picked one.
The CLR has been ported to various platforms, not all of which are equal. The XBox 360 CLR, for instance, does not have Reflection.Emit or even all of the IL ops that the full CLR does. Hence, a different compiler may emit IL codes that are legal on the full CLR, but illegal on the Compact CLR.
The other issue is the availability of class libraries. The full BCL includes the Microsoft.VisualBasic namespace, which is automatically referenced by the VB.NET compiler. This contains VB6 compatibility functions, the My namespace features, as well as some compiler helper functions, and is commonly referred to as the VB.NET runtime.
Whenever the CLR is ported, certain assemblies are ported - and others are not. For the XBox, Microsoft.VisualBasic was not ported. This means that you cannot reference anything from that namespace. While it's fairly easy to not reference the compatibility or My namespaces, the compiler services can be inserted into the compiled IL without you explicitly calling them.
In VB.NET 8, you could pass an undocumented and unsupported -novbruntimeref switch to vbc.exe to keep it from referencing Microsoft.VisualBasic.dll. Unfortunately, this would sometimes cause odd compiler errors. In VB.NET 9, it's become documented and supported and renamed to /vbruntime.
The 3rd case is addins and Visual Studio support. This is up to the individual packages, as to whether they support templates, code gen, etc. for each language. I believe some 3rd parties have released VB.NET templates for XNA, though it's not officially supported.
Bottom line, I guess, is that it's a mix of technical concerns (CLR ports, BCL availability, compiler IL output) and support (testing, funding, and addins for other languages).
From all accounts VB.NET and C# are 99.9999 equivalent when it comes to the CLR. But there are some slight differences that may bite you. In addtion I remember reading on some microsoft blog that there are some things the CLR can do that are not (yet) programmable by either VB.NET or C# and have to be done by IL. Interesting indeed.
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.