CLR via C# (3rd Edition) (Developer Reference)

We are generally not meant to create new thread directly. Only in a few circumstances it is acceptable.

So if you do use new Thread() especially in UI , that would be frowned upon.

It is encouraged to use BackgroundWorker or Task<T> which encapsulates thread exception handling so no exception handling in terms of catch block would be necessary.

These 4 scenarios are acceptable cases where you want your own thread (From CLR via C#):

I highly recommend that you use the thread pool to execute asynchronous compute-bound operations whenever possible. However, there are some occasions when you might want to explicitly create a thread dedicated to executing a particular compute-bound operation. Typically, you'd want to create a dedicated thread if you're going to execute code that requires the thread to be in a particular state that is not normal for a thread pool thread. For example, I'd create a dedicated thread if I wanted the thread to run at a special priority (all thread pool threads run at normal priority, and you should not alter a thread pool thread's priority). I would also consider creating and using my own thread if I wanted to make the thread a foreground thread (all thread pool threads are background threads), thereby preventing the application from dying until my thread has completed its task. I'd also use a dedicated thread if the compute-bound task were extremely long running; this way, I would not be taxing the thread pool's logic as it tries to figure out whether to create an additional thread. Finally, I'd use a dedicated thread if I wanted to start a thread and possibly abort it prematurely by calling Thread's Abort method (discussed in Chapter 21, "CLR Hosting and AppDomains").

Have a look at this one "CLR via C# (Dev-Pro)" by Jeffrey Richter http://www.amazon.com/CLR-via-Dev-Pro-Jeffrey-Richter/dp/0735627045/ref=pd_sim_b_1 When i started with .NET it was the first book I've read, it is really helps to understand the core of .NET and how it is works. Pdf version should be here: http://www.google.com/search?client=opera&rls=en&q=CLR+via+C%23+pdf&sourceid=opera&ie=utf-8&oe=utf-8

Whilst I'm sure someone will come up with a good literal explanation for this, I'd recommend reading the following book which covers everything nicely:

http://www.amazon.com/dp/0735627045/ (CLR via C#, Jeffrey Richter).

Yes. The code for specific type is generated at the runtime by CLR and keeps a hashtable (or similar) of implementations.

Page 372 of CLR via C#:

When a method that uses generic type parameters is JIT-compiled, the CLR takes the method's IL, substitutes the specified type arguments, and then creates native code that is specific to that method operating on the specified data types. This is exactly what you want and is one of the main features of generics. However, there is a downside to this: the CLR keeps generating native code for every method/type combination. This is referred to as code explosion. This can end up increasing the application's working set substantially, thereby hurting performance. Fortunately, the CLR has some optimizations built into it to reduce code explosion. First, if a method is called for a particular type argument, and later, the method is called again using the same type argument, the CLR will compile the code for this method/type combination just once. So if one assembly uses List, and a completely different assembly (loaded in the same AppDomain) also uses List, the CLR will compile the methods for List just once. This reduces code explosion substantially.

For .Net Frmework

http://www.amazon.com/CLR-via-Dev-Pro-Jeffrey-Richter/dp/0735627045/ref=sr_1_1?ie=UTF8&s=books&qid=1274297492&sr=8-1

then get to Silverlight http://www.silverlight.net/getstarted/

Short answer: No.

Longer Answer: You don't really need to in most cases. You can give hints by changing the logic in your statements. This is easier to do with a performance tool, like the one built into the higher (and more expensive) versions of Visual Studio, since you can capture the mispredicted branches counter. I realize this is for academic purposes, but it's good to know that the JITer is very good at optimizing your code for you. As an example (taken pretty much verbatim from CLR via C#)

This code:

public static void Main() {
    Int32[] a = new Int32[5];
    for(Int32 index = 0; index < a.Length; index++) {
        // Do something with a[index]
    }
}

may seem to be inefficient, since a.Length is a property and as we know in C#, a property is actually a set of two methods (get_Length and set_Length in this case). However, the JIT knows that it's a property and either stores the length in a local variable for you, or inlines the method, to prevent the overhead.

...some developers have underestimated the abilities of the JIT compiler and have tried to write “clever code” in an attempt to help the JIT compiler. However, any clever attempts that you come up with will almost certainly impact performance negatively and make your code harder to read, reducing its maintainability.

Among other things, it actually goes further and does the bounds checking once outside of the loop instead of inside the loop, which would degrade performance.

I realize it has little to do directly with your question, but I guess the point that I'm trying to make is that micro-optimizations like this don't really help you much in C#, because the JIT generally does it better, as it was designed exactly for this. (Fun fact, the x86 JIT compiler performs more aggressive optimizations than the x64 counterpart)

This article explains some of the optimizations that were added in .NET 3.5 SP1, among them being improvements to straightening branches to improve prediction and cache locality.

All of that being said, if you want to read a great book that goes into what the compiler generates and performance of the CLR, I recommend the book that I quoted from above, CLR via C#.

EDIT: I should mention that if this were currently possible in .NET, you could find the information in either the EMCA-335 standard or working draft. There is no standard that supports this, and viewing the metadata in something like IlDasm or CFF Explorer show no signs of any special metadata that can hint at branch predictions.

I would recommend to read the Jefrey Richter's book CLR via C#. It provides very clear explanation what is going on under the hood :)

Also yoг may find this question helpful: Why is an assembly .exe file?

For each of your projects create a netmodule or an assembly and compile/merge them all into a single assembly.

First alternative. This was proposed by Jay R. Wren:

This is a cute hack, but with the CSC and VBC both supporting the /target:module and /addmodule options, you could actually do this without ILMerge just by using a shell script or make file.

Visual Studio doesn't support the "netmodule" type, but MSBuild does.

Add the VB project to your solution. Unload the project and edit the project file.

Change OutputType to module:

<OutputType>module</OutputType>

Instead of adding a reference to the desired project, we add a module. Sadly, again VStudio fails here, but MSBUILD works just fine. Unload the project and edit the project file. Add an item group with AddModules include directives.

<ItemGroup><AddModules Include="..\VbXml\bin\Debug\VbXml.netmodule" /></ItemGroup>

This will tell msbuild to tell CSC to use /addmodule directives, just like the Reference Item Group which Studio does manage.

Major Drawback: No Visual Studio Intellisense for the added module. We already have references, it is too bad we don't have modules. [UPDATE: As @Ark-kun pointed out elsewhere, Visual Studio can reference .netmodule projects and have Intellisense. Just add the project reference BEFORE changing the output type.]

SharpDevelop has the first step, but the second step, an "Add Module" gui has been open as a low priority item since SD 2.0.

Second way. This great article (by Scott Hanselman) describes how to megre assemblies automatically if you're using Visual Studio. It does give you IntelliSense support , unlike the first alternative.

Third way. Do it manually with scs.
Example how to create several modules and link theme into a single dll:

csc /t:module RarelyUsedTypes.cs
csc /out:AllTypes.dll /t:library /addmodule:RarelyUsedTypes.netmodule AllTypes.cs

For more information see Richter's book CLR via C#.

I guess I could rattle off some exams, like the MCP exams, or BrainBench, but you have to pay lots of money for those.

If you were really sold on taking an exam to gauge your competency, you could get a one of the MCP exam prep guides for ASP.NET, C#, and SQL Server and see how well you comprehend and take in that material. I'm not sure that it's the most accurate way of measuring competency though.

You can get a good qualitative evaluation of your SQL Server skills by simply reading Itzik's or Kalen's books and seeing how you comprehend them. For .NET, read Richter and critically evaluate yourself against the concepts you find in that book. Do those concepts make sense?

Probably the most valuable way to get feedback is to ask your senior developers for a frank evaluation of your skills.

If you're asking how I evaluate my junior developers, it's pretty easy once I see their code and they get a track record for a few months, but I don't believe quantitative analysis is the best way. Instead, I ask questions like:

• Can they deliver?
• Are they writing good code?
• Are they taking the initiative to learn more?
• What have they brought to the table?
• Do they understand the software development lifecycle?
• Do they break builds?
• Are they good team players, or do they code in solitude?
• Do they make suggestions?
• Are they open to others' suggestions?
• Do their design decisions make sense for the projects they've been on?

Ask yourself how your leaders would answer these questions about you. If you are seriously confident that they will respond positively, you will have an easier time "grading yourself".

FromAsync provides a convenient mechanism which uses the BeginXxx and EndXxx methods of the Asynchronous Programming Model (APM) to create a Task.

The resulting Task will, by default, be executed on a thread pool thread (and your subsequent call to SomeCode1() will indeed execute on the current thread, in parallel to the Task).

The ContinueWith method on Task does indeed act rather like a callback, i.e. the delegate provided to this method will execute after the task has finished, also on some thread pool thread. It does not block the current thread.

Indeed, you should set up this continuation when creating the task, e.g.

var task1 = Task<int>.Factory.FromAsync(Foo1, ...).ContinueWith(Foo2,...);

For more general and detailed info on threading in .NET I thoroughly recommend reading a good text such as part V of CLR via C#.

If you're interested in a book on the topic of IL and the lower-level stuff in .NET, I would suggest looking at CLR via C#.

IDisposable must be used when you want to use some native resource like file stream in your code. For all other purposes, the .Net garbage collector does a good job.

Simply implmenting the IDisposable does not force a garbage collection. The Dispose method needs to be called explicitly to clean up any native resource.

Edit: I will advise you to go through the Garbage Collection chapter in ClR via C# by Jeff Richter.