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.
Related
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.
I am a trainee software engineer, I did self study on collection and generics and reported to my TL. He suggested me to study these things also.
Specially in generics how memory is defined for generic type, how IL and CLR works for generic?
Performance of generic over collection, or over boxing unboxing?
I googled but getting confined answer. Can please anybody explain or give any matter(Link) on that to study.
Thanks.
Design and Implementation of Generics for the .NET Common Language Runtime by Andrew Kennedy and Don Syme talks about the theory behind implementing generics on the CLR.
http://research.microsoft.com/pubs/64031/designandimplementationofgenerics.pdf
The source code is available for the .NET Framework, which allows you to debug through System.Collections.Generic.
http://weblogs.asp.net/scottgu/archive/2008/01/16/net-framework-library-source-code-now-available.aspx
If you want deeper information, you can read the Rotor (aka Shared Source Common Language Infrastructure) source code, which is the "source available" part of the .NET Framework.
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=8c09fd61-3f26-4555-ae17-3121b4f51d4d&displaylang=en
Another implementation is the Mono project. They have an implementation of generic collections and the Mono codebase is open source.
http://www.mono-project.com/Main_Page
A very nice tool for looking at .NET internals is Reflector. It shows the full C# (or VB, or IL) code of many .NET classes, including the collections.
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.
I recently got excited by the idea of statically check design by contract in .net 4.0 / Visual Studio 2010.
However I was saddened to find out that it will only be available in Visual Studio Team System. http://msdn.microsoft.com/en-us/devlabs/dd491992.aspx
Are there any alternatives which give statically checked design by contract for c#?
Will the mono project be adding this functaionality to there compiler?
He's referring to the theorem prover.
There's nothing stopping the open-source or commercial community from implementing their own. The Contracts classes are part of the BCL and trivially easy to add to, say, Mono. "We'll" need to make a theorem prover if we want to statically check things.
The prover is not part of the compiler. It basically runs as follows:
Compile a version of the binary with CONTRACTS_FULL defined. This emits all Contract attributes and calls to the Contract class static methods.
Load the assembly "for reflection only," and parse all the method's byte code. A detailed flow analysis with state information will allow certain contracts to be shown "always true." Some will be "known false at some point." Others will be "unable to statically prove the contract."
As the tool gets better, it will go from giving warnings about every contract to eventually offering similar proving results to the Microsoft version.
Edit: Man, if Reflector was open sourced it would be great for this. A first-pass implementation could certainly operate as a plugin. That way the prover logic can be designed without worrying about how the binaries are loaded. Once it proves functional (get it?), the logic could be extracted and built to operate on the syntax trees produced by another assembly loader (one that is open source). The important/novel thing here is the prover logic - the assembly loader has been done multiple times and nothing changes spectacularly for this use.
Code contracts do not require the C# compiler as they are implemented as classes in the .NET Framework 4.0. Any .NET compiler that can emit a managed assembly is usable, although C++/CLI will likely emit an incompatible assembly when mixing managed and native code.
There are additional tools executed by the IDE to rewrite the resulting IL so that the contracts appear in the correct location, and thus the Mono project authors would need to write similar tools for contracts to work on the Mono platform.
See this post for more information.
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.