Develop Reference

A few questions about the DLR

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.

Where could I get the information about the in-memory layout info of .NET Object Model?

I want to know the in-memory representation of .NET constructs such as "interface", "class", "struct", etc. There's an excellent book for C++ object model - <Inside the C++ Object Model> by Stanley. Lippman, I want a similar book for .NET and C#.
I have read some books about .NET, but they are mostly about the logical usage of .NET. None of them talks about the physical in-memory layout info. I think it's necessary to know at least one implementation of .NET.
I have read about the "Drill Into .NET Framework Internals to See How the CLR Creates Runtime Objects" Could someone provide some hints about more in-depth books and articles?
If this info is not publicly avaialble. Shared source one like Mono or Shared Source CLI could be an option.
Many thanks.

As already mentioned, CLR Via C# is a really good source of information. And if you want to get into the nitty gritty details you can take a look at the SSCLI (Shared Source Common Language Infrastructure), which is a early branch of the initial .NET Framework implementation from the MS source. The current version of SSCLI covers a significant number of framework 2.0 feature set.
http://www.microsoft.com/downloads/details.aspx?FamilyID=8c09fd61-3f26-4555-ae17-3121b4f51d4d
There was also a book that covered the SSCLI, but that was for version 1, but might still be of use.
http://www.amazon.com/Shared-Source-Essentials-David-Stutz/dp/059600351X/ref=sr_1_1?ie=UTF8&s=books&qid=1271220840&sr=8-1

The reason this information is not easily available is almost certainly deliberate on Microsofts behalf.
Microsoft created the .NET Framework and the CLR so you do not have to (unduly) worry yourself about where/how your objects are stored in memory (implmentation details). This "ignorance" is actually one of the biggest benefits of using .NET; you do not need to worry about issues such as manual memory allocation, processor/memory models etc.
The other benefit of this is that it improves security, ie it makes writing malicious code that much harder, although not impossible of course.
CLR Via C# by Jeff Richter is probably the best current book for "under the hood" type .NET information. Chapters 4, 5, 20 and 21 would probably be of most interest regarding layout of .NET types, although, as explained above, you will not find the same level of detail as the C++ object model.

There is another reason that much of this CLI info may be hard to get at - much of it may be implementation details, which could vary between (for example) MS .NET, CF, MF, Silverlight, Mono (regular), Mono (iPhone), etc. And certainly from a language perspective (C# etc) it is well off topic.
You'd have to check the CLI spec (ECMA 335). Either the info is in there (in which case you're sorted) or it isn't (in which case it is an implementation detail).

If you really want to see them, learn about WinDbg and SOS.dll. If you can dive into the live debugging or dump analysis lands, almost nothing is invisible to you.
Regards,

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

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.

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).

What are the differences between C#.net and Visual Basic.net?

I have a small experience in VB.net and I would like to learn C#.net
What are the differences between VB.net and C#.net?
Is there any difference in performance between these two?
Apart from the syntactical differences, are there any major changes that I have to keep in mind?

The Language Features section of the Wikipedia article offers a good overview. Performance is essentially equivalent in almost every aspect, from what I understand.

Performance is equivalent if you write equivalent code, but VB.NET has constructs that are in there for "backward compatibility" which should NEVER be used. C# doesn't have some of these things. I'm thinking specifically of:
Functions which are in the Microsoft.VisualBasic namespace which are members of other standard .NET classes like Trim(). The .NET classes are often faster.
Redim and Redim Preserve. Never to be used in .NET, but there they are in VB.
On Error ... instead of exceptions. Yuck!
Late binding (sometimes derisively called "Option Slow"). Not a good idea in a non-dynamic .NET language from a performance perspective.
VB is also missing things like automatic properties which makes it pretty undesirable for me. Not a performance issue, but worth keeping in mind.

I think you will find the answers to your question in this articles:
http://en.wikipedia.org/wiki/Comparison_of_C_sharp_and_Visual_Basic_.NET
and
Link
edit: Noldorin was faster :x

The first thing to know about learning C# is that it is not pronounced "C#.net", it is just C#. Microsoft tacked on ".NET" to VB, because there was a previous version of VB that didn't work on the .NET Framework. C# was created specifically with the .NET Framework in mind, so the ".net" is implied and unnecessary. Also as a side note putting "C#.NET" on your resume really tips off a knowledgeable manager to your skill level, or lack there of, regarding C#.
Also this Wikipedia article is really good for showing the pros and cons as well as the differences between C# and VB.NET at a high level.

Follow following links which give detailed differences
http://www.harding.edu/fmccown/vbnet_csharp_comparison.html
http://www.codeproject.com/KB/dotnet/vbnet_c__difference.aspx
http://support.microsoft.com/kb/308470
In spite of differences as mentioned at http://support.microsoft.com/kb/308470 both C# and VB.Net are first class citizens of .Net world
Although there are differences between
Visual Basic .NET and Visual C# .NET,
both are first-class programming
languages that are based on the
Microsoft .NET Framework, and they are
equally powerful. Visual Basic .NET is
a true object-oriented programming
language that includes new and
improved features such as inheritance,
polymorphism, interfaces, and
overloading. Both Visual Basic .NET
and Visual C# .NET use the common
language runtime. There are almost no
performance issues between Visual
Basic .NET and Visual C# .NET. Visual
C# .NET may have a few more "power"
features such as handling unmanaged
code, and Visual Basic .NET may be
skewed a little toward ease of use by
providing features such as late
binding. However, the differences
between Visual Basic .NET and Visual
C# .NET are very small compared to
what they were in earlier versions.

No matter which language you select based on your personal preference
and past experience, both languages are powerful developer tools and
first-class programming languages that share the common language
runtime in the .NET Framework.
Says by Microsoft
https://web.archive.org/web/20061027230435/http://support.microsoft.com/kb/308470