CLR Via C#

Jeffrey Richter

Mentioned 82

Your essential guide to developing applications with the common language runtime (CLR) and Micrsoft.NET Framework4.0, with examles in Microsoft Visual C # 2010.

More on Amazon.com

Mentioned in questions and answers.

I frequently hear/read the following advice:

Always make a copy of an event before you check it for null and fire it. This will eliminate a potential problem with threading where the event becomes null at the location right between where you check for null and where you fire the event:

// Copy the event delegate before checking/calling
EventHandler copy = TheEvent;

if (copy != null)
    copy(this, EventArgs.Empty); // Call any handlers on the copied list

Updated: I thought from reading about optimizations that this might also require the event member to be volatile, but Jon Skeet states in his answer that the CLR doesn't optimize away the copy.

But meanwhile, in order for this issue to even occur, another thread must have done something like this:

// Better delist from event - don't want our handler called from now on:
otherObject.TheEvent -= OnTheEvent;
// Good, now we can be certain that OnTheEvent will not run...

The actual sequence might be this mixture:

// Copy the event delegate before checking/calling
EventHandler copy = TheEvent;

// Better delist from event - don't want our handler called from now on:
otherObject.TheEvent -= OnTheEvent;    
// Good, now we can be certain that OnTheEvent will not run...

if (copy != null)
    copy(this, EventArgs.Empty); // Call any handlers on the copied list

The point being that OnTheEvent runs after the author has unsubscribed, and yet they just unsubscribed specifically to avoid that happening. Surely what is really needed is a custom event implementation with appropriate synchronisation in the add and remove accessors. And in addition there is the problem of possible deadlocks if a lock is held while an event is fired.

So is this Cargo Cult Programming? It seems that way - a lot of people must be taking this step to protect their code from multiple threads, when in reality it seems to me that events require much more care than this before they can be used as part of a multi-threaded design. Consequently, people who are not taking that additional care might as well ignore this advice - it simply isn't an issue for single-threaded programs, and in fact, given the absence of volatile in most online example code, the advice may be having no effect at all.

(And isn't it a lot simpler to just assign the empty delegate { } on the member declaration so that you never need to check for null in the first place?)

Updated: In case it wasn't clear, I did grasp the intention of the advice - to avoid a null reference exception under all circumstances. My point is that this particular null reference exception can only occur if another thread is delisting from the event, and the only reason for doing that is to ensure that no further calls will be received via that event, which clearly is NOT achieved by this technique. You'd be concealing a race condition - it would be better to reveal it! That null exception helps to detect an abuse of your component. If you want your component to be protected from abuse, you could follow the example of WPF - store the thread ID in your constructor and then throw an exception if another thread tries to interact directly with your component. Or else implement a truly thread-safe component (not an easy task).

So I contend that merely doing this copy/check idiom is cargo cult programming, adding mess and noise to your code. To actually protect against other threads requires a lot more work.

Update in response to Eric Lippert's blog posts:

So there's a major thing I'd missed about event handlers: "event handlers are required to be robust in the face of being called even after the event has been unsubscribed", and obviously therefore we only need to care about the possibility of the event delegate being null. Is that requirement on event handlers documented anywhere?

And so: "There are other ways to solve this problem; for example, initializing the handler to have an empty action that is never removed. But doing a null check is the standard pattern."

So the one remaining fragment of my question is, why is explicit-null-check the "standard pattern"? The alternative, assigning the empty delegate, requires only = delegate {} to be added to the event declaration, and this eliminates those little piles of stinky ceremony from every place where the event is raised. It would be easy to make sure that the empty delegate is cheap to instantiate. Or am I still missing something?

Surely it must be that (as Jon Skeet suggested) this is just .NET 1.x advice that hasn't died out, as it should have done in 2005?

According to Jeffrey Richter in the book CLR via C#, the correct method is:

// Copy a reference to the delegate field now into a temporary field for thread safety
EventHandler<EventArgs> temp =
Interlocked.CompareExchange(ref NewMail, null, null);
// If any methods registered interest with our event, notify them
if (temp != null) temp(this, e);

Because it forces a reference copy. For more information, see his Event section in the book.

I'm new to .NET C# programming. I'm following few books. It is said that instead of compiling it directly to binary code (Native code). High level code is converted into intermediate language (called MSIL aka CIL). But when I compile, I get an exe/Dll file.

  1. Is this MSIL/CIL containted in these exe/dll file?
  2. I want to see that intermediate language code. Just to get feel of its existence. How to view it?
  3. They are calling this exe/dll file an assembly. Are they using this "fancy word" just to differentiate these from the exe/dll files that contain binary code (native code)?
  1. Yes it is in assembly.
  2. You need .NET Reflector or ILDasm.
  3. More details on assembly check HERE.

P.S As you are following some books I will highly recommend you CLR via C#.

I am trying to do operator overloads for +=, but I can't. I can only make an operator overload for +.

How come?

Edit

The reason this is not working is that I have a Vector class (with an X and Y field). Consider the following example.

vector1 += vector2;

If my operator overload is set to:

public static Vector operator +(Vector left, Vector right)
{
    return new Vector(right.x + left.x, right.y + left.y);
}

Then the result won't be added to vector1, but instead, vector1 will become a brand new Vector by reference as well.

Overloadable Operators, from MSDN:

Assignment operators cannot be overloaded, but +=, for example, is evaluated using +, which can be overloaded.

Even more, none of assignment operators can be overloaded. I think this is because there will be an effect for the Garbage collection and memory management, which is a potential security hole in CLR strong typed world.

Nevertheless, let's see what exactly an operator is. According to the famous Jeffrey Richter's book, each programming language has its own operators list, which are compiled in a special method calls, and CLR itself doesn't know anything about operators. So let's see what exactly stays behind the + and += operators.

See this simple code:

Decimal d = 10M;
d = d + 10M;
Console.WriteLine(d);

Let view the IL-code for this instructions:

  IL_0000:  nop
  IL_0001:  ldc.i4.s   10
  IL_0003:  newobj     instance void [mscorlib]System.Decimal::.ctor(int32)
  IL_0008:  stloc.0
  IL_0009:  ldloc.0
  IL_000a:  ldc.i4.s   10
  IL_000c:  newobj     instance void [mscorlib]System.Decimal::.ctor(int32)
  IL_0011:  call       valuetype [mscorlib]System.Decimal [mscorlib]System.Decimal::op_Addition(valuetype [mscorlib]System.Decimal,
                                                                                                valuetype [mscorlib]System.Decimal)
  IL_0016:  stloc.0

Now lets see this code:

Decimal d1 = 10M;
d1 += 10M;
Console.WriteLine(d1);

And IL-code for this:

  IL_0000:  nop
  IL_0001:  ldc.i4.s   10
  IL_0003:  newobj     instance void [mscorlib]System.Decimal::.ctor(int32)
  IL_0008:  stloc.0
  IL_0009:  ldloc.0
  IL_000a:  ldc.i4.s   10
  IL_000c:  newobj     instance void [mscorlib]System.Decimal::.ctor(int32)
  IL_0011:  call       valuetype [mscorlib]System.Decimal [mscorlib]System.Decimal::op_Addition(valuetype [mscorlib]System.Decimal,
                                                                                                valuetype [mscorlib]System.Decimal)
  IL_0016:  stloc.0

They are equal! So the += operator is just syntactic sugar for your program in C#, and you can simply overload + operator.

For example:

class Foo
{
    private int c1;

    public Foo(int c11)
    {
        c1 = c11;
    }

    public static Foo operator +(Foo c1, Foo x)
    {
        return new Foo(c1.c1 + x.c1);
    }
}

static void Main(string[] args)
{
    Foo d1 =  new Foo (10);
    Foo d2 = new Foo(11);
    d2 += d1;
}

This code will be compiled and successfully run as:

  IL_0000:  nop
  IL_0001:  ldc.i4.s   10
  IL_0003:  newobj     instance void ConsoleApplication2.Program/Foo::.ctor(int32)
  IL_0008:  stloc.0
  IL_0009:  ldc.i4.s   11
  IL_000b:  newobj     instance void ConsoleApplication2.Program/Foo::.ctor(int32)
  IL_0010:  stloc.1
  IL_0011:  ldloc.1
  IL_0012:  ldloc.0
  IL_0013:  call       class ConsoleApplication2.Program/Foo ConsoleApplication2.Program/Foo::op_Addition(class ConsoleApplication2.Program/Foo,
                                                                                                          class ConsoleApplication2.Program/Foo)
  IL_0018:  stloc.1

Update:

According to your Update - as the @EricLippert says, you really should have the vectors as an immutable object. Result of adding of the two vectors is a new vector, not the first one with different sizes.

If, for some reason you need to change first vector, you can use this overload (but as for me, this is very strange behaviour):

public static Vector operator +(Vector left, Vector right)
{
    left.x += right.x;
    left.y += right.y;
    return left;
}

Ignoring unsafe code, .NET cannot have memory leaks. I've read this endlessly from many experts and I believe it. However, I do not understand why this is so.

It is my understanding that the framework itself is written in C++ and C++ is susceptible to memory leaks.

  • Is the underlying framework so well-written, that it absolutely does not have any possibility of internal memory leaks?
  • Is there something within the framework's code that self-manages and even cures its own would-be memory leaks?
  • Is the answer something else that I haven't considered?

.NET can have memory leaks but it does a lot to help you avoid them. All reference type objects are allocated from a managed heap which tracks what objects are currently being used (value types are usually allocated on the stack). Whenever a new reference type object is created in .NET, it is allocated from this managed heap. The garbage collector is responsible for periodically running and freeing up any object that is no longer used (no longer being referenced by anything else in the application).

Jeffrey Richter's book CLR via C# has a good chapter on how memory is managed in .NET.

I've become a bit confused about the details of how the JIT compiler works. I know that C# compiles down to IL. The first time it is run it is JIT'd. Does this involve it getting translated into native code? Is the .NET runtime (as a Virtual Machine?) interact with the JIT'd code? I know this is naive, but I've really confused myself. My impression has always been that the assemblies are not interpreted by the .NET Runtime but I don't understand the details of the interaction.

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

A .NET program is first compiled into MSIL code. When it is executed, the JIT compiler will compile it into native machine code.

I am wondering:

Where is these JIT-compiled machine code stored? Is it only stored in address space of the process? But since the second startup of the program is much faster than the first time, I think this native code must have been stored on disk somewhere even after the execution has finished. But where?

In short, the IL is JIT-compiled for each invocation of the program and is maintained in code pages of the process address space. See Chapter 1 of Richter for great coverage of the .NET execution model.

What is the difference between the JIT compiler and CLR? If you compile your code to il and CLR runs that code then what is the JIT doing? How has JIT compilation changed with the addition of generics to the CLR?

I know the thread is pretty old, but I thought I might put in the picture that made me understand JIT. It's from the excellent book CLR via C# by Jeffrey Ritcher. In the picture, the metadata he is talking about is the metadata emitted in the assembly header where all information about types in the assembly is stored:

JIT image from CLR via C#

I know this question could be similar to others but really I'm looking for reasons why VB6 developers should switch to C#.

My company recently approved project to be written in C#, so we have a lot of VB.Net programmers, however, we have some legacy app developers as well that are in VB6. We have a time frame to re-write those apps into .Net web apps. So no matter what they will have to learn new stuff.

One of the developers today specifically asked "why should we switch to C#?"

I responded that the community largely has decided that C# is the way to go with about 80% of the examples in C#. I am a VB.Net programmer and I am excited to finally cut my teeth on C#, however, being that I'm so new I'm not sure I can answer the "why?" question. My reasons are more because I want to learn it.

So without descending into a VB verses C# I really am curious if there are any resources that I can send to these developers to calm their nerves.

Looking forward to your input!

As far as the migration over to .NET goes, better late than never! As far as my advice goes, your mileage may vary, it's worth every penny you're paying for it!

I personally believe you are making the correct choice. The first instinct for VB developers is to switch to VB.NET. That sounds entirely reasonable, but in my opinion, it's the wrong choice. You really have to break down the reasons for the switch into two categories: Why switch to .NET, and why switch to C#?

Why switch to .NET over VB6:

  • Multithreading in VB6 is technically possible from a programming perspective, but just about impossible if you want to use the IDE.

  • I do not believe you can create a 64-bit native application in VB6. That rules out a lot.

  • No new enhancements are being made to VB6.

  • OK, there are so many reasons I can think of, I'll probably just stop there.

Why switch to C# instead of VB.NET

  • Developers may be lulled into a false sense of familiarity with VB.NET - treating resources like they did in VB6 without understanding the full concepts. An example: you often see new converts to VB.NET setting objects to Nothing, believing that it's a magical way to release resources. It is not.

  • It's true that most examples are now in C#. More importantly, Jeff Richter's book is only in C# now. If you want to understand how .NET really works, IMO his book is pretty much mandatory.

  • In .NET, you'll find that you will use lambda expressions all of the time, especially when operating with Linq. IMO VB's verbosity really becomes a barrier to comprehension and readability here, in ways where it simply wasn't before: foo.Select(x => x > 50) is, by just about any standard, much more fluent and readable than foo.Select(Function(x) x > 50). It gets worse as the expressions get more complex.

  • Some of the worst practices with VB6 are impossible or at least much less accessible in C# (such as ReDim Preserve and On Error Resume Next).

  • VB is saddled with some syntax which makes it pretty cumbersome and confusing to use when creating general-purpose CLR libraries. For example, in C#, you use indexers with brackets[]. In VB, you use parens. That makes it pretty difficult for the user of a subroutine to tell if it's an indexer or a function. If someone tried to use your library outside of VB, the difference would be important, but a VB developer might be inclined to create subroutines which should be indexers as functions, since they look similar.

  • I don't have any data on this, but if you are trying to hire a good set of programmers, the best ones will generally be less inclined to work in a shop which writes VB.NET over C#. They usually fear that the code their colleagues will be generating is likely to be substandard .NET code, and let's be frank here -- there's a stigma against VB.NET developers and the quality of their code in the community. There. I said it. Let the flames begin...

As a footnote, from my perspective, VB.NET was a real missed opportunity for MS. What it should have been was a way to seamlessly convert your old VB6 code to the .NET world - with dynamic invocation and high-quality COM interop from the start. What it ended up being was a near-clone of C#'s feature set with a more verbose syntax and little to no backward compatibility. Sad, really. It locked a lot of organizations out of .NET for a long time. Then again, maybe it forced a "cold-turkey" clean break from the past...

I'm interesting in how CLR implementes the calls like this:

abstract class A {
    public abstract void Foo<T, U, V>();
}

A a = ...
a.Foo<int, string, decimal>(); // <=== ?

Is this call cause an some kind of hash map lookup by type parameters tokens as the keys and compiled generic method specialization (one for all reference types and the different code for all the value types) as the values?

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.

According to the CLI standard (Partition IIA, chapter 18) and the MSDN reference page for the System.Reflection.ExceptionHandlingClauseOptions enum, there are four different kinds of exception handler blocks:

  • catch clauses: "Catch all objects of the specified type."
  • filter clauses: "Enter handler only if filter succeeds."
  • finally clauses: "Handle all exceptions and normal exit."
  • fault clauses: "Handle all exceptions but not normal exit."

Given these brief explanations (cited from the CLI Standard, btw.), these should map to C# as follows:

  • catchcatch (FooException) { … }
  • filter — not available in C# (but in VB.NET as Catch FooException When booleanExpression)
  • finallyfinally { … }
  • faultcatch { … }

Experiment:

A simple experiment shows that this mapping is not what .NET's C# compiler really does:

// using System.Linq;
// using System.Reflection;

static bool IsCatchWithoutTypeSpecificationEmittedAsFaultClause()
{
    try
    {
        return MethodBase
               .GetCurrentMethod()
               .GetMethodBody()
               .ExceptionHandlingClauses
               .Any(clause => clause.Flags == ExceptionHandlingClauseOptions.Fault);
    }
    catch // <-- this is what the above code is inspecting
    {
        throw;
    }
}

This method returns false. That is, catch { … } has not been emitted as a fault clause.

A similar experiment shows that in fact, a catch clause was emitted (clause.Flags == ExceptionHandlingClauseOptions.Clause), even though no exception type has been specified.

Questions:

  1. If catch { … } really is a catch clause, then how are fault clauses different from catch clauses?
  2. Does the C# compiler ever output fault clauses at all?

1. If catch { … } really is a catch clause, then how are fault clauses different from catch clauses?

The C# compiler (at least the one that ships with .NET) actually appears to compile catch { … } as if it were really catch (object) { … }. This can be shown with the code below.

// using System;
// using System.Linq;
// using System.Reflection;

static Type GetCaughtTypeOfCatchClauseWithoutTypeSpecification()
{
    try
    {
        return MethodBase
               .GetCurrentMethod()
               .GetMethodBody()
               .ExceptionHandlingClauses
               .Where(clause => clause.Flags == ExceptionHandlingClauseOptions.Clause)
               .Select(clause => clause.CatchType)
               .Single();
    }
    catch // <-- this is what the above code is inspecting
    {
        throw;
    }
}

That method returns typeof(object).

So conceptually, a fault handler  is  is similar to a catch { … }; however, the C# compiler never generates code for that exact construct but pretends that it is a catch (object) { … }, which is conceptually a catch clause. Thus a catch clause gets emitted.

Side note: Jeffrey Richter's book "CLR via C#" has some related information (on pp. 472–474): Namely that the CLR allows any value to be thrown, not just Exception objects. However, starting with CLR version 2, non-Exception values are automatically wrapped in a RuntimeWrappedException object. So it seems somewhat surprising that C# would transform catch into catch (object) instead of catch (Exception). There is however a reason for this: The CLR can be told not to wrap non-Exception values by applying a [assembly: RuntimeCompatibility(WrapNonExceptionThrows = false)] attribute.

By the way, the VB.NET compiler, unlike the C# compiler, translates Catch to Catch anonymousVariable As Exception.


2. Does the C# compiler ever output fault clauses at all?

It obviously doesn't emit fault clauses for catch { … }. However, Bart de Smet's blog post "Reader challenge – fault handlers in C#" suggests that the C# compiler does produce fault clauses in certain circumstances.

For example, I know it is defined for gcc and used in the Linux kernel as:

#define likely(x)       __builtin_expect((x),1)
#define unlikely(x)     __builtin_expect((x),0)

If nothing like this is possible in C#, is the best alternative to manually reorder if-statements, putting the most likely case first? Are there any other ways to optimize based on this type of external knowledge?

On a related note, the CLR knows how to identify guard clauses and assumes that the alternate branch will be taken, making this optimization inappropriate to use on guard clases, correct?

(Note that I realize this may be a micro-optimization; I'm only interested for academic purposes.)

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 am trying to get something clarified.

  1. When a .NET console application is run, does mscorlib.dll/mscoree.dll get loaded in the process's virtual address space?

  2. mscorlib.dll and mscoree.dll (CLR) are not managed dlls. Is that correct?

Also, what is a good resource to understand more about how a .NET program is executed?

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?

I have a class that should delete some file when disposed or finalized. Inside finalizers I can't use other objects because they could have been garbage-collected already.

Am I missing some point regarding finalizers and strings could be used?

UPD: Something like that:

public class TempFileStream : FileStream
{
    private string _filename;

    public TempFileStream(string filename)
        :base(filename, FileMode.Open, FileAccess.Read, FileShare.Read)
    {
        _filename = filename;
    }

    protected override void Dispose(bool disposing)
    {
        base.Dispose(disposing);
        if (_filename == null) return;

        try
        {
            File.Delete(_filename); // <-- oops! _filename could be gc-ed already
            _filename = null;
        }
        catch (Exception e)
        {
            ...
        }
    }
}

Yes, you can most certainly use strings from within a finalizer, and many other object types.

For the definitive source of all this, I would go pick up the book CLR via C#, 3rd edition, written by Jeffrey Richter. In chapter 21 this is all described in detail.

Anyway, here's what is really happening...

During garbage collection, any objects that have a finalizer that still wants to be called are placed on a special list, called the freachable list.

This list is considered a root, just as static variables and live local variables are. Therefore, any objects those objects refer to, and so on recursively is removed from the garbage collection cycle this time. They will survive the current garbage collection cycle as though they weren't eligible to collect to begin with.

Note that this includes strings, which was your question, but it also involves all other object types

Then, at some later point in time, the finalizer thread picks up the object from that list, and runs the finalizer on those objects, and then takes those objects off that list.

Then, the next time garbage collection runs, it finds the same objects once more, but this time the finalizer no longer wants to run, it has already been executed, and so the objects are collected as normal.

Let me illustrate with an example before I tell you what doesn't work.

Let's say you have objects A through Z, and each object references the next one, so you have object A referencing object B, B references C, C references D, and so on until Z.

Some of these objects implement finalizers, and they all implement IDisposable. Let's assume that A does not implement a finalizer but B does, and then some of the rest does as well, it's not important for this example which does beyond A and B.

Your program holds onto a reference to A, and only A.

In an ordinary, and correct, usage pattern you would dispose of A, which would dispose of B, which would dispose of C, etc. but you have a bug, so this doesn't happen. At some point, all of these objects are eligible for collection.

At this point GC will find all of these objects, but then notice that B has a finalizer, and it has not yet run. GC will therefore put B on the freachable list, and recursively take C, D, E, etc. up to Z, off of the GC list, because since B suddenly became in- eligible for collection, so does the rest. Note that some of these objects are also placed on the freachable list themselves, because they have finalizers on their own, but all the objects they refer to will survive GC.

A, however, is collected.

Let me make the above paragraph clear. At this point, A has been collected, but B, C, D, etc. up to Z are still alive as though nothing has happened. Though your code no longer has a reference to any of them, the freachable list has.

Then, the finalizer thread runs, and finalizes all of the objects in the freachable list, and takes the objects off of the list.

The next time GC is run, those objects are now collected.

So that certainly works, so what is the big bruaha about?

The problem is with the finalizer thread. This thread makes no assumptions about the order in which it should finalize those objects. It doesn't do this because in many cases it would be impossible for it to do so.

As I said above, in an ordinary world you would call dispose on A, which disposes B, which disposes C, etc. If one of these objects is a stream, the object referencing the stream might, in its call to Dispose, say "I'll just go ahead and flush my buffers before disposing the stream." This is perfectly legal and lots of existing code do this.

However, in the finalization thread, this order is no longer used, and thus if the stream was placed on the list before the objects that referenced it, the stream is finalized, and thus closed, before the object referencing it.

In other words, what you cannot do is summarized as follows:

You can not access any objects your object refer to, that has finalizers, as you have no guarantee that these objects will be in a usable state when your finalizer runs. The objects will still be there, in memory, and not collected, but they may be closed, terminated, finalized, etc. already.

So, back to your question:

Q. Can I use strings in finalizer method?
A. Yes, because strings do not implement a finalizer, and does not rely on other objects that has a finalizer, and will thus be alive and kicking at the time your finalizer runs.

The assumption that made you take the wrong path is the second sentence of the qustion:

Inside finalizers I can't use other objects because they could have been garbage-collected already.

The correct sentence would be:

Inside finalizer I can't use other objects that have finalizers, because they could have been finalized already.


For an example of something the finalizer would have no way of knowing the order in which to correctly finalize two objects, consider two objects that refer to each other and that both have finalizers. The finalizer thread would have to analyze the code to determine in which order they would normally be disposed, which might be a "dance" between the two objects. The finalizer thread does not do this, it just finalizes one before the other, and you have no guarantee which is first.


So, is there any time it is safe to access objects that also have a finalizer, from my own finalizer?

The only guaranteed safe scenario is when your program/class library/source code owns both objects so that you know that it is.

Before I explain this, this is not really good programming practices, so you probably shouldn't do it.

Example:

You have an object, Cache, that writes data to a file, this file is never kept open, and is thus only open when the object needs to write data to it.

You have another object, CacheManager, that uses the first one, and calls into the first object to give it data to write to the file.

CacheManager has a finalizer. The semantics here is that if the manager class is collected, but not disposed, it should delete the caches as it cannot guarantee their state.

However, the filename of the cache object is retrievable from a property of the cache object.

So the question is, do I need to make a copy of that filename into the manager object, to avoid problems during finalization?

Nope, you don't. When the manager is finalized, the cache object is still in memory, as is the filename string it refers to. What you cannot guarantee, however, is that any finalizer on the cache object hasn't already run.

However, in this case, if you know that the finalizer of the cache object either doesn't exist, or doesn't touch the file, your manager can read the filename property of the cache object, and delete the file.

However, since you now have a pretty strange dependency going on here, I would certainly advice against it.

I would really appreciate if someone could tell me whether I understand it well:

class X
{
   A a1=new A(); // reference on the stack, object value on the heap
   a1.VarA=5;    // on the stack - value type
   A a2=a1;      // reference on the stack, object value on the heap
   a2.VarA=10;   // on the stack - value type         
}

Also both a1 and a2 references are on the stack, while their "object" values are on the heap. But what about VarA variable, its still pure value type?

class A
{
   int VarA;
}

Read Jeff Richter's CLR via C# for a complete understanding of this topic.

As a ASP.NET developer with 5+ year experience. I like to measure my competency level in ASP.NET & SQL Server. Basically my goal is to raise my competency level and skill-set in ASP.NET; before that I need to know what is my level considering current ASP.NET and related technologies...

So, please provide some pointers...

  • Is there are any skill-set measuring Quiz or exam, which account experience and technology ?
  • How do you measure your or your junior developers skills or competency?

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

I am trying to sign an assembly with a strong name by following the guide from here: http://msdn.microsoft.com/en-us/library/xc31ft41.aspx

The key instruction is:

al /out:<assembly name> <module name> /keyfile:<file name>

And it says

module name is the name of the code module used to create the assembly

I don't understand what this means. In the literal sense I would interpret the above as some component of csc.exe (i.e., it created the assembly) but obviously this is nonsensical in this context.

So firstly what does this refer to, and secondly (in order to aid my meta-learning) how would one go about reasoning what it is? I get the impression given the terseness of the documentation that it should be obvious or intuitive to me, but it currently is not.

I tried specifying some random names (e.g. blah.blah) but get this error:

ALINK: error AL1047: Error importing file 'c:\path\to\proj\bin\Debug\blah.blah' -- The system cannot find the file specified.

Edit: Upon further reading I get the impression the module name is the name of the code, but I have not had any luck specifying the .cs files either - I am told Database file is corrupt and may not be usable.

An assembly is made up of modules (.netmodule files), which are produced by compiling sources (.cs files). The assembly linker is responsible for packaging modules into assemblies. So if you have two source files class1.cs and class2.cs:

csc /t:module class1.cs
csc /t:module class2.cs
al /out:assembly.dll /t:library class1.netmodule class2.netmodule

For the best treatment of how the CLR deals with modules, manifests and assemblies, see Richter.

I need to capture video from a webcam. Are there any classes in C#/.NET that can help me with this. I am only interested in real time data.

And are there any good C#/.NET books that I can study to gain deep knowledge on the language and the platform?

I would recommend you to use 3rd party library. It would be the best solution instead of inventing your own bicycle. Here, I used AForge.Net. Though it has some problems concerning performance, but I tweaked the library myself when performance became a critical issue for me. The AForge.Net code is open source and you can tweak it to your needs.

As for books you definitely should look at Jeffrey Richter's "CLR via C#" and John Skeet's "C# in Depth".

What is different between this two variable definitions?

object oVar;
dynamic dVar;

Performance? Memory allocation ? Benefits?

The dynamic keyword also adds some overhead to your execution time, due to all the extra logic used - so if you don't need the dynamic runtime or interop and can get away with using object your code will be more efficient.

More information on the dynamic keyword can be found in Jeff Richter's book: CLR via C#, 3rd Edition

Sam Gentile did a couple of posts about the details too:

Why should I use IEnumerable<T> when I can make do with...say List<T>? What's the advantage of the former over the latter?

On this point Jeffrey-Richter writes:

When declaring a method’s parameter types, you should specify the weakest type possible, preferring interfaces over base classes. For example, if you are writing a method that manipulates a collection of items, it would be best to declare the method’s parameter by using an interface such as IEnumerable<T> rather than using a strong data type such as List<T> or even a stronger interface type such as ICollection<T> or IList<T>:

// Desired: This method uses a weak parameter type   
public void ManipulateItems<T>(IEnumerable<T> collection) { ... }  

// Undesired: This method uses a strong parameter type   
public void ManipulateItems<T>(List<T> collection) { ... }

The reason, of course, is that someone can call the first method passing in an array object, a List<T> object, a String object, and so on — any object whose type implements IEnumerable<T>. The second method allows only List<T> objects to be passed in; it will not accept an array or a String object. Obviously, the first method is better because it is much more flexible and can be used in a much wider range of scenarios.

Naturally, if you are writing a method that requires a list (not just any enumerable object), then you should declare the parameter type as an IList<T>. You should still avoid declaring the parameter type as List<T>. Using IList<T> allows the caller to pass arrays and any other objects whose type implements IList<T>.

On the flip side, it is usually best to declare a method’s return type by using the strongest type possible (trying not to commit yourself to a specific type).

Everything is ultimately JITed into native machine code, so ultimately, we have a native stack in .NET which the GC needs to scan for object pointers whenever it does a garbage collection.

Now, the question is: How does the .NET garbage collector figure out if a pointer to an object inside the GC heap is actually a managed pointer or a random integer that happens to have a value that corresponds to a valid address?

Obviously, if it can't distinguish the two, then there can be memory leaks, so I'm wondering how it works. Or -- dare I say it -- does .NET have the potential to leak memory? :O

Remember that all managed memory is managed by the CLR. Any actual managed reference was created by the CLR. It knows what it created and what it didn't.

If you really feel you must know the details of the implementation, then you should read CLR via C# by Jeffrey Richter. The answer is not simple - it's quote a bit more than can be answered on SO.

I am wondering what's the way to call a c# class method from C++(Native, not C++ CLI) code? Need simple and elegant way

You can embed any CLR assembly (C#, VB.NET, F#, ...) in a native C++ program using what's called "CLR Hosting". This is how native programs (such as SQL Server) support .NET code extensions. E.g. SQL CLR in SQL Server.

You load the CLR into a native process using CorBindToRuntimeEx() for .NET 2.0 and CLRCreateInstance() in .NET 4.

Details can be found on MSDN, or Jeff Richter's book CLR via C#.

I've been programming in C and C++ in Linux for around 3 years, and recently have been interested in developing commercial software for businesses. Let's say I've found a niche where I think I could be successful, but that they only use Windows. I have no experience whatsoever with the Windows API, however. I have a few questions:

Should I learn .NET?

Do I need to learn C# in order to use .NET, or can I stick with C++?

What is the sentiment about compiling using GCC under Cygwin with the --no-cygwin option? I'm interested in portability, and I'm worried that if I start writing for VC++, I might get bound to Windows.

Where is a good place to do my essential reading?

What else can you tell me about transitioning from Linux to Windows programming?

no. dont learn .NET - learn C#.. its like the anything goes playground. once you get the hang of it.. you will be able to finish projects in 1/10th the time..

but with C#/.NET you learn bad habits. i am now back in C++. i had C++ 12years, then C# 5 years, now C++ 6 months.

although it does take around 6 times longer to complete projects... (6 months vs 1 month) , i feel that the C++ code has an artistic feel.. while the C# code is generic. like BestBuy.

i am totally anti C++/CLI or whatever its called. if you need to get down to the CLR level.. run, dont walk back to C++.. or you'll end up spending all your time working around some arbitrary C# design "feature" like event synchronization..

my next destination may be .NET Powershell to manage my C++ server applications.

I did Unix to Windows move around 10 years ago.. i tried going back to FreeBSD or Linux... I used to love vi.. but VS is by far the best IDE by far. just get vs2010 pro + reshaper and read these 2 books. the first one is core C# but its .NET 2.0 , which is good.. because its easiest to start writing C++ style code anyways. the next book will last you years.

http://www.amazon.com/2-0-Practical-Guide-Programmers-Guides/dp/0121674517

http://www.amazon.com/gp/reader/0735627045/ref=sib_dp_pt#reader-link

hope this helps.

also. no reason NOT to write portal c++ code in the year 2012. cmake + VS2010 + boost + crossroads-io

I faced exactly the same questions and I am so happy I tried .NET. I hope this info can help you:

Should I learn .NET?

I would highly recomment it.

Do I need to learn C# in order to use .NET, or can I stick with C++?

You can stick with C++ but I am sure you will love to learn C#, please try it. You will be able to mix them too. The main challenge with .NET is to learn all the libraries that are out there to help you out (so you do not need to reinvent the wheel). Use msdn often and try to get a map of the fundamental classes and assemblies.

It is a fun experience if you come from C++ you should not have major problems.

Where is a good place to do my essential reading?

I would start with something light, check the free Visual Studio tools, software and examples here, go to the MSDN documentation and compile some of the examples in MSDN (how to access files,...). As you can see you will find C# and C++ examples side by side.

Then of course books like C# via CLR will eventually need to be read.

Portability

Be sure you run your code in Mono and multiple platforms.

Future investment

Investing on learning the .NET framework will pay back. Today is costly to learn all the new tools out there, with .NET you know you can evolve. New features and languages appear but the fundamental classes remain so your time/effort investment is more under control.

what book would you recommend to improve one's c# style of writing? I know Code Complete has a few tips on style and organizing code but it's not specific to c#.

I would also recommend Clean Code by Robert Martin. Yes, it's not C#-specific, and yes, it will improve one's C# style of writing. It might be a good idea to continue with Agile Software Development, Principles, Patterns, and Practices book by the same author.

And here is 1 hour video from uncle Bob at Øredev conference Clean Code III: Functions

PS: Shameless plug. I developed a site which answers exactly this question: "Which book is of higher importance in given area?". I get the data from Amazon, and draw a network of books. The more links one book has the higher its importance. Thanks to this site I also found "Agile Principles, Patterns, and Practices in C#", again by Robert Martin, but I prefer the original book.

CLR Via C# by Jeffrey Richter contains all the 2.0 patterns you need to follow in order to produce good code. Helped me immensely.

Effective C# by Bill Wagner, as well as the sequel, More Effective C#.

Elements of C# Style is a good primer.

While it may not go into as much detail as other books that are available but I've definetly got my moneys worth from it - highly recommended.

C# Concisely very thorough

Yes, I am using a profiler (ANTS). But at the micro-level it cannot tell you how to fix your problem. And I'm at a microoptimization stage right now. For example, I was profiling this:

for (int x = 0; x < Width; x++)
{
    for (int y = 0; y < Height; y++)
    {
        packedCells.Add(Data[x, y].HasCar);
        packedCells.Add(Data[x, y].RoadState);
        packedCells.Add(Data[x, y].Population);
    }
}

ANTS showed that the y-loop-line was taking a lot of time. I thought it was because it has to constantly call the Height getter. So I created a local int height = Height; before the loops, and made the inner loop check for y < height. That actually made the performance worse! ANTS now told me the x-loop-line was a problem. Huh? That's supposed to be insignificant, it's the outer loop!

Eventually I had a revelation - maybe using a property for the outer-loop-bound and a local for the inner-loop-bound made CLR jump often between a "locals" cache and a "this-pointer" cache (I'm used to thinking in terms of CPU cache). So I made a local for Width as well, and that fixed it.

From there, it was clear that I should make a local for Data as well - even though Data was not even a property (it was a field). And indeed that bought me some more performance.

Bafflingly, though, reordering the x and y loops (to improve cache usage) made zero difference, even though the array is huge (3000x3000).

Now, I want to learn why the stuff I did improved the performance. What book do you suggest I read?

CLR via C# by Jeffrey Richter.

It is such a great book that someone stolen it in my library together with C# in depth.

I have spent hours on a debugging problem only to have a more experienced guy look at the IL (something like 00400089 mov dword ptr [ebp-8],edx ) and point out the problem. Honestly, this looks like Hebrew to me - I have no idea what the heck it's saying.

Where can I learn more about this stuff and impress everyone around me? My goal is to read stuff like the following and make a comment like: Yeh, you are having a race condition.

.maxstack 2
.entrypoint
.locals init (valuetype [MathLib]HangamaHouse.MathClass mclass) 

ldloca mclass
ldc.i4 5

I can give you an answer that runs both ways.

On the one hand, there's nothing like good assembly language skills to teach you how a computer really operates. MSIL is, to some extent, an assembly-like language. On the down side, there are very few opportunities to do this kind of development any more.

On the other hand, resorting to looking at the MSIL to fix a problem is not necessarily the most direct or educational way to understand a problem. In five years of .NET programming, I've never felt the need to go there. Only once has a co-worker (who had worked at Microsoft on compiler testing) gone there with a problem that I was trying to solve, and in the end, his answer was misleading, because the real issue was based in CLR design and constraints. Better knowledge of the CLR and C# would have led to a better understanding and a real solution.

(In case you're wondering, the problem was that I wanted to use "as" for safe casting with a generic. "as" didn't work, but "is" did. My co-worker noted that "is" and "as" use the same MSIL. The real problem is that "as" only works for casting classes, and without the proper constraint on the generic declaration, C# doesn't know whether your generic type will be a class. In fact, the types I was using with generics were value types; "as" couldn't work for those at all.)

Rather than going for MSIL skills, I highly recommend Jeffrey Richter's book CLR via C#. Even after years of digging hard at into C#, this book is still full of revelations - I learn something from every page.

Just out of curiosity I would like to know how many processor cores the .NET task scheduler supports.

Windows Server 2012 supports up to 640 cores. Was (is) .NET limited to 64 or would it use all available cores?

According to CLR via C#, 3rd ed., chapter 25 Thread Basics:

Today, the CLR […] can only use up to 64 cores when running on 64-bit Windows. [… M]anaged applications can use up to 32 cores when running on a 32-bit version of Windows.

The book was written in 2010, so it contains information relevant to .Net 4.0 and Windows Server 2008 R2, but I don't think .Net 4.5 changed anything in this regard. EDIT: It seems .Net 4.5 did actually change this, see Peter Meinl's answer quoting Stephen Toub.

UPDATE: There is now an accepted answer that "works". You should never, ever, ever, ever use it. Ever.


First let me preface my question by stating that I'm a game developer. There's a legitimate - if highly unusual - performance-related reason for wanting to do this.


Say I have a C# class like this:

class Foo
{
    public int a, b, c;
    public void MyMethod(int d) { a = d; b = d; c = a + b; }
}

Nothing fancy. Note that it is a reference type that contains only value types.

In managed code I'd like to have something like this:

Foo foo;
foo = Voodoo.NewInUnmanagedMemory<Foo>(); // <- ???
foo.MyMethod(1);

What would the function NewInUnmanagedMemory look like? If it can't be done in C#, could it be done in IL? (Or maybe C++/CLI?)

Basically: Is there a way - no matter how hacky - to turn some totally arbitrary pointer into an object reference. And - short of making the CLR explode - damn the consequences.

(Another way to put my question is: "I want to implement a custom allocator for C#")

This leads to the follow-up question: What does the garbage collector do (implementation-specific, if need be) when faced with a reference that points outside of managed memory?

And, related to that, what would happen if Foo had a reference as a member field? What if it pointed at managed memory? What if it only ever pointed at other objects allocated in unmanaged memory?

Finally, if this is impossible: Why?


Update: Here are the "missing pieces" so far:

#1: How to convert an IntPtr to an object reference? It might be possible though unverifiable IL (see comments). So far I've had no luck with this. The framework seems to be extremely careful to prevent this from happening.

(It would also be nice to be able to get the size and layout information for non-blittable managed types at runtime. Again, the framework tries to make this impossible.)

#2: Assuming problem one can be solved - what does the GC do when it encounters an object reference that points outside of the GC heap? Does it crash? Anton Tykhyy, in his answer, guesses that it will. Given how careful the framework is to prevent #1, it does seem likely. Something that confirms this would be nice.

(Alternatively the object reference could point to pinned memory inside the GC heap. Would that make a difference?)

Based on this, I'm inclined to think that this idea for a hack is impossible - or at least not worth the effort. But I'd be interested to get an answer that goes into the technical details of #1 or #2 or both.

Purely C# Approach

So, there are a few options. The easiest is to use new/delete in an unsafe context for structs. The second is to use built-in Marshalling services to deal with unmanaged memory (code for this is visible below). However, both of these deal with structs (though I think the latter method is very close to what you want). My code has a limitation in that you must stick to structures throughout and use IntPtrs for references (using ChunkAllocator.ConvertPointerToStructure to get the data and ChunkAllocator.StoreStructure to store the changed data). This is obviously cumbersome, so you'd better really want the performance if you use my approach. However, if you are dealing with only value-types, this approach is sufficient.

Detour: Classes in the CLR

Classes have a 8 byte "prefix" in their allocated memory. Four bytes are for the sync index for multithreading, and four bytes are for identifying their type (basically, virtual method table and run-time reflection). This makes it hard to deal with unamanaged memory since these are CLR specific and since the sync index can change during run-time. See here for details on run-time object creation and here for an overview of memory layout for a reference type. Also check out CLR via C# for a more in-depth explanation.

A Caveat

As usual, things are rarely so simple as yes/no. The real complexity of reference types has to do with how the garbage collector compacts allocated memory during a garbage collection. If you can somehow ensure that a garbage collection doesn't happen or that it won't affect the data in question (see the fixed keyword) then you can turn an arbitrary pointer into an object reference (just offset the pointer by 8 bytes, then interpret that data as a struct with the same fields and memory layout; perhaps use StructLayoutAttribute to be sure). I would experiment with non-virtual methods to see if they work; they should (especially if you put them on the struct) but virtual methods are no-go due to the virtual method table that you'd have to discard.

One Does Not Simply Walk Into Mordor

Simply put, this means that managed reference types (classes) cannot be allocated in unmanaged memory. You could use managed reference types in C++, but those would be subject to garbage collection... and the process and code is more painful than the struct-based approach. Where does that leave us? Back where we started, of course.

There is a Secret Way

We could brave Shelob's Lair memory allocation ourselves. Unfortunately, this is where our paths must part, because I am not that knowledgeable about it. I will provide you with a link or two - perhaps three or four in actuality. This is rather complicated and begs the question: Are there other optimizations you could try? Cache coherency and superior algorithms is one approach, as is judicious application of P/Invoke for performance-critical code. You could also apply the aforementioned structures-only memory allocation for key methods/classes.

Good luck, and let us know if you find a superior alternative.

Appendix: Source Code

ChunkAllocator.cs

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Runtime.InteropServices;

namespace MemAllocLib
{
    public sealed class ChunkAllocator : IDisposable
    {
        IntPtr m_chunkStart;
        int m_offset;//offset from already allocated memory
        readonly int m_size;

        public ChunkAllocator(int memorySize = 1024)
        {
            if (memorySize < 1)
                throw new ArgumentOutOfRangeException("memorySize must be positive");

            m_size = memorySize;
            m_chunkStart = Marshal.AllocHGlobal(memorySize);
        }
        ~ChunkAllocator()
        {
            Dispose();
        }

        public IntPtr Allocate<T>() where T : struct
        {
            int reqBytes = Marshal.SizeOf(typeof(T));//not highly performant
            return Allocate<T>(reqBytes);
        }

        public IntPtr Allocate<T>(int reqBytes) where T : struct
        {
            if (m_chunkStart == IntPtr.Zero)
                throw new ObjectDisposedException("ChunkAllocator");
            if (m_offset + reqBytes > m_size)
                throw new OutOfMemoryException("Too many bytes allocated: " + reqBytes + " needed, but only " + (m_size - m_offset) + " bytes available");

            T created = default(T);
            Marshal.StructureToPtr(created, m_chunkStart + m_offset, false);
            m_offset += reqBytes;

            return m_chunkStart + (m_offset - reqBytes);
        }

        public void Dispose()
        {
            if (m_chunkStart != IntPtr.Zero)
            {
                Marshal.FreeHGlobal(m_chunkStart);
                m_offset = 0;
                m_chunkStart = IntPtr.Zero;
            }
        }

        public void ReleaseAllMemory()
        {
            m_offset = 0;
        }

        public int AllocatedMemory
        {
            get { return m_offset; }
        }

        public int AvailableMemory
        {
            get { return m_size - m_offset; }
        }

        public int TotalMemory
        {
            get { return m_size; }
        }

        public static T ConvertPointerToStruct<T>(IntPtr ptr) where T : struct
        {
            return (T)Marshal.PtrToStructure(ptr, typeof(T));
        }

        public static void StoreStructure<T>(IntPtr ptr, T data) where T : struct
        {
            Marshal.StructureToPtr(data, ptr, false);
        }
    }
}

Program.cs

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace MemoryAllocation
{
    class Program
    {
        static void Main(string[] args)
        {
            using (MemAllocLib.ChunkAllocator chunk = new MemAllocLib.ChunkAllocator())
            {
                Console.WriteLine(">> Simple data test");
                SimpleDataTest(chunk);

                Console.WriteLine();

                Console.WriteLine(">> Complex data test");
                ComplexDataTest(chunk);
            }

            Console.ReadLine();
        }

        private static void SimpleDataTest(MemAllocLib.ChunkAllocator chunk)
        {
            IntPtr ptr = chunk.Allocate<System.Int32>();

            Console.WriteLine(MemAllocLib.ChunkAllocator.ConvertPointerToStruct<Int32>(ptr));
            System.Diagnostics.Debug.Assert(MemAllocLib.ChunkAllocator.ConvertPointerToStruct<Int32>(ptr) == 0, "Data not initialized properly");
            System.Diagnostics.Debug.Assert(chunk.AllocatedMemory == sizeof(Int32), "Data not allocated properly");

            int data = MemAllocLib.ChunkAllocator.ConvertPointerToStruct<Int32>(ptr);
            data = 10;
            MemAllocLib.ChunkAllocator.StoreStructure(ptr, data);

            Console.WriteLine(MemAllocLib.ChunkAllocator.ConvertPointerToStruct<Int32>(ptr));
            System.Diagnostics.Debug.Assert(MemAllocLib.ChunkAllocator.ConvertPointerToStruct<Int32>(ptr) == 10, "Data not set properly");

            Console.WriteLine("All tests passed");
        }

        private static void ComplexDataTest(MemAllocLib.ChunkAllocator chunk)
        {
            IntPtr ptr = chunk.Allocate<Person>();

            Console.WriteLine(MemAllocLib.ChunkAllocator.ConvertPointerToStruct<Person>(ptr));
            System.Diagnostics.Debug.Assert(MemAllocLib.ChunkAllocator.ConvertPointerToStruct<Person>(ptr).Age == 0, "Data age not initialized properly");
            System.Diagnostics.Debug.Assert(MemAllocLib.ChunkAllocator.ConvertPointerToStruct<Person>(ptr).Name == null, "Data name not initialized properly");
            System.Diagnostics.Debug.Assert(chunk.AllocatedMemory == System.Runtime.InteropServices.Marshal.SizeOf(typeof(Person)) + sizeof(Int32), "Data not allocated properly");

            Person data = MemAllocLib.ChunkAllocator.ConvertPointerToStruct<Person>(ptr);
            data.Name = "Bob";
            data.Age = 20;
            MemAllocLib.ChunkAllocator.StoreStructure(ptr, data);

            Console.WriteLine(MemAllocLib.ChunkAllocator.ConvertPointerToStruct<Person>(ptr));
            System.Diagnostics.Debug.Assert(MemAllocLib.ChunkAllocator.ConvertPointerToStruct<Person>(ptr).Age == 20, "Data age not set properly");
            System.Diagnostics.Debug.Assert(MemAllocLib.ChunkAllocator.ConvertPointerToStruct<Person>(ptr).Name == "Bob", "Data name not set properly");

            Console.WriteLine("All tests passed");
        }

        struct Person
        {
            public string Name;
            public int Age;

            public Person(string name, int age)
            {
                Name = name;
                Age = age;
            }

            public override string ToString()
            {
                if (string.IsNullOrWhiteSpace(Name))
                    return "Age is " + Age;
                return Name + " is " + Age + " years old";
            }
        }
    }
}

I have a background in programming and have done a little .NET but I feel that I would benefit from improving my understanding of the Windows Architecture. Can anyone recomend a good book that discusses the Windows Operating System from a technical perspactive, particulary it's architecture/design and how it works. Im not looking for a huge technical manual, just looking to get a general appreciation of how Windows works.

Thanks.

Great question Dave. I am mostly a web developer, but the book that really gave me a great understanding of .Net and I think is a must read (maybe a "prequel" for you) is Jeffrey Richter's CLR via C#. It made me a better developer just from the fundamental way your construct your classes and how that impacts .Net, memory managment, multi-threading, etc.

Great fundamentals will lead you to books that some of these other folks have recommended.

I always recommend this book to anybody that is starting out and if you code along with it you will start to understand .Net a great deal. I will ask around Windows Architecture front...

Good luck!

I have an ASP.NET web application developed in Visual Studio 2008, composed of 3 different projects (one for UI, one of BO and the third for DAL).

How can I generate a single assembly file which holds all 3? Now it's generating 3 DLLS each for each project in the solution.

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've seen in CLR via C# and in codeproject article Delegate Behind the Scenes that when C# compiler sees this

public delegate void MyDelegate(int intValue);

it actually generates something like this

class MyDelegate : System.MulticastDelegate
{
    public virtual void Invoke(Int32 intValue);

    ...
}

Question is, why Invoke method is virtual? Can this generated delegate type be inherited? From the CLR point of view looks like it can. But why? Why not generating sealed class so there will be no virtual methods lookup penalty at runtime?

This is quacks-like-a-duck typing. Similar kind of typing that makes System.Int32, a value type, derived from ValueType, a reference type. Makes no sense, illegal in C#, but actually behaves that way. The real implementation of a delegate's Invoke method is buried in the CLR and is a static function written in C++.

But sure, annotating it as virtual makes somewhat sense because it behaves like a virtual method. The actual code that executes is not fixed like it is with a non-virtual class method. Even harder to reason out is what the proper model should be for a delegate that's bound to a static method. A virtual method that's static?

It is just a virtual duck.

Reading up on function pointers as used in C could help you get a better mental model for delegates. A delegate is a function pointer with bells on, it can also store the target object. C# lacks the syntax to express this another way.

I'm reading through a C# topic on Dispose() and ~finalize and when to use which. The author argues that you should not use references within your ~finalize because it's possible the object you're referencing may already be collected. The example specifically stated is, ".. you have two objects that have references to each other. If object #1 is collected first, then object #2's reference to it is pointing to an object that's no longer there."

In what scenarios would an instance of an object be in a state where it has a reference in memory to an object that is being GC'd? My guess is there are at least two different scenarios, one where the object reference is pointing at an object and one where the object reference is pointing at another object reference (eg. when it was passed by ref in a method).

There is a term called resurrection in .NET.

In short, resurrection may happen when your object is in finalization queue but when the finalizer (~ClassName() method) is called, it moves the object back to the game. For example:

public class SomeClass
{
    public static SomeClass m_instance;

    ...

    ~SomeClass()
    {
    m_instance = this;
    }
}

You can read more on this here: Object Resurrection using GC.ReRegisterForFinalize. But I would really recommend the book CLR via C# by Jeffrey Richter as it explained this subject in depth in one of the chapters.

I've read in The Pragmatic Programmer, and in some other articles (including one from Joel Spolsky), that you should only throw Exceptions in exceptional cases. Otherwise, you should return an error.

Sometimes it is possible (returning -1, -0, or a positive number, for example), but there are other cases where that is not possible. I mean, if you are returning a class, you can always return null, but I think the idea is to return something that will alert the caller what happened.

If I always return null, I don't think it is useful to say: If this method returns null, it could be because of A, B, C, D, or E

So, how exactly can this be implemented in C#?

Edit:
Hours after I posted this question, I saw another question here where the question itself was about wheter the code posted in was a good practice or not.

I see that is another way of doing what I was asking here. Here is the link:

Generic property disadvantages?

By using numbers you're directly contradicting what Microsoft recommend with Exceptions. The best source of information I've found that de-mystifies the whole subject, is Jeffrey Richter's CLR via C# 3. Also the .NET Framework Guidelines book is worth a read for its material on Exceptions.

To quote MSDN:

Do not return error codes. Exceptions are the primary means of reporting errors in frameworks.

One solution you could adopt is an out parameter, which gets the result. Your method then returns a bool much like a lot TryParse methods you meet in the framework.

This is one of those things that is so simple that no one ever just comes out and says it in any of the tutorials I've read.

I've been creating a few stand alone .NET applications as well as a few DLL based plug-ins for other programs. I've noticed that a project in Visual Studio, at least with Windows applications and class libraries, compile into a single file (EXE or DLL).

Is this always the case? In terms of organizing a larger application should I always think of projects in Visual Studio as corresponding to a single file in the final program?

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

You can automate this process for Visual Studio.

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, 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 alternative. 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.

When I was learning .NET I saw it as a platform that runs my .NET programs which has its own Stack & Heap.

But now after learning more about things, I see a .NET application as just like any other C/C++ native application. It is in Portable Executable (PE) file format with new data directory & .text section is filled with MSIL code instead of machine code. The only difference is few DLLs (which are considered as .NET platform) (like any other Dll dependency) are loaded.

I guess at the very entry point there is some machine code which calls into the loaded DLL(.net platform) and functions of those DLL read the MSIL from .text section (segment to be more correct) and generate equivalent machine code and put it in some kind of buffer (I don't know which area would it be it. I cannot be .text & .data as they are readonly. will they be stack or heap?). Then make the EIP point to this buffer of instructions. Last few instructions again call back into DLLs to repeat the process for rest of MSIL.

As of Managed Heap & Managed Stack they are just some portion of the processes heap & stack. its just that few functions (referred to as GC) will keep track of the memory allocations & deallocations from this portions of memory.

I like this realistic view. I don't know how far I'm true. I'm just guessing these things. Please correct me & tell me more about this. How far will is it similar to this view? Where can I learn more about .NET platform from this point of view?

Lately I have been reading Pro C# 2008 and the .NET 3.5 Platform (there's now a VS2010/.NET 4.0 version, too), and it does a great job explaining how the .NET bytecode works on the back-end, and how you can learn about what's really being called by using the reflector, etc. It's dense and long (and sometimes more info than I wanted), but it's good informative reading.

CLR via C# describes some internal .NET things, including PE load process and hosting of CLR in your own process.

For CLR check : CLR via C#.

It is really a great book especially if you are interested in "low level" .NET/CLR.

For JVM check : Java Virtual Machine

This sounds a little odd, but I'm not sure if my process has a memory leak or not, and I was hoping to get some information.

I was recently assigned an investigation into why a windows service in production was consuming roughly a gig of ram (the server it is running on has 8 gigs). This is outside of my experience as a developer, but it's been a very good chance for me to read up on how garbage collection is working on msdn and other sources. But at this point I'm very confused about /when/ collection actually runs, on this point, ever article I read is vague.

1) I have found a specific operation that increases memory by ~30kb each time it is executed. 2) I have very carefully gone over the code and believe that I am properly closing everything, and removing references 3) I have used several memory profilers, all of them seem to indicate that my old objects are linked to the gc. 4) If I leave the process absolutely idle for a few days, the memory usage suddenly plummets down to ~8 megs

So based on this, I'm not even sure I have a memory leak. Given that GC is an expensive process, is it possible that I grew to 1 gig in production just because there was still free ram to be had, and acquiring it was "cheaper" than running GC? Especially given that this service is run ~6 times a second? If this is the case, what options do I have? I am of the understanding that I cannot forceably trigger GC, do I have any resort?

Thank you for any input you might have, I realize memory leaks and gc in csharp is a deep topic and if there's a particularly helpful read on the subject, I'd be happy to be pointed that way as well.

Memory leak usually implies that memory is never deallocated and process eventually crashes with OutOfMemoryException. You are saying that it does get deallocated after a while

4) If I leave the process absolutely idle for a few days, the memory usage suddenly plummets down to ~8 megs

You certainly can force garbage collection using GC.Collect. But as others have said it is not a good long term solution. I highly recommend you to read about garbage collection in this book. If you still convinced that you have memory leak you can create a dump of the process in production environment using Process Explorer. And analyze it later using WinDbg. Unless you can use dotTrace or ANTS on production which would be a lot easier.

I am not sure how the user defined class objects are garbage collected. Do I need to implement IDisposable interface on every class and call the dispose() method on it to free the memory?

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.

I'm trying to determine why a process is hanging and am learning about various tools such as Process Explorer, Process Monitor, and WinDbg.

Anyway, I'm trying to use WinDbg and after attaching to my process, the debugger says this:

(1e9c.1128): Break instruction exception - code 80000003 (first chance)
eax=7ffda000 ebx=00000000 ecx=00000000 edx=77c5c964 esi=00000000 edi=00000000
eip=77c18b2e esp=0543ff5c ebp=0543ff88 iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246
ntdll!DbgBreakPoint:
77c18b2e cc              int     3

If I run !analyze -v, it displays this:

FAULTING_IP: 
ntdll!DbgBreakPoint+0
77c18b2e cc              int     3

I'm a software developer (VB.NET / C#) with no experience in this level of debugging, so I'm not sure what I'm doing, but it appears as though WinDbg is attaching to my process and then immediately breaking. Then, when I do an analyze it thinks the breakpoint (which it just set) is the problem with the application?

How am I supposed to use WinDbg to simply attach to a process and analyze it?

(Also, are there any good books/tutorial for getting started with this level of debugging and WinDbg?)

WinDbg is a user and kernel mode debugger, but on its own it doesn't really understand managed code and as such the !analyze command is of limited use. If you want to debug managed applications using WinDbg, you need some way to make WinDbg understand the internal structures of managed code. There are a number of extension DLLs that enables this. The .NET framework ships with sos.dll and there are downloads such as psscor2.dll and sosex.dll.

SOS and PSSCOR2 provide more or less the same features while SOSEX adds new features for managed debugging. Help files for each of these are available from withing WinDbg. E.g. to get the help for SOS you can use the !sos.help command.

You have to load either SOS or PSSCOR2 and possibly SOSEX to debug a managed application with WinDbg. E.g. if you want to load SOS you use the load command like this

.loadby sos clr

This will load SOS from the location of the .NET runtime. Please note that the runtime is called mscorwks in .NET 2 and coreclr in Silverlight, so if you're using either of these, you need to change the .loadby command accordingly.

WinDbg needs symbols to display additional information. This is particular important for unmanaged code. You can use the .symfix command to let WinDbg retrieve symbols as needed from Microsoft's symbol server.

As your application is hanging, there's a good chance that you'll have one or more blocked threads. You can view managed threads using the !threads (or just !t) command. In .NET simple locks are implemented internally using a structure called SyncBlocks. You can view these using the !syncblk command. If you have loaded SOSEX the !dlk command can automatically detect deadlocks.

If you want more information, there are a couple of books and some blogs to read.

Books:

Blogs:

  • Tess' blog is great. It has numerous tutorials and labs you can use to practice.
  • Tom's blog is also very useful.

Videos:

  • I did a presentation on managed debugging at the Microsoft development center in Denmark. Videos are available on Channel p. Part 1 and part 2.

When you overload an operator, such as operator +, the compiled CIL looks something like this:

.method public hidebysig specialname static bool op_Addition(...) { ... }

Why use the name op_Addition here and not, say, the name +?

I'm suggesting that the CIL syntax should have been

.method public hidebysig specialname static bool +(...) { ... }

And the member name, when looking for it, would have been + rather than op_Addition.

Note: This is a question about language design; "because the spec says so" is not a helpful answer.

The CLR does not know about operators, so the c# compiler generates methods with thes special names so that other .net languages that do not have support for operators can consume them as methods.

CLR Via c# is a good reference for this type of question.

Can you please tell me some tutorials/books about thinking a large application in c#. I have worked with 3 tier, but i need something more specific:

a way to design panels, so that for specific users specific panels will load and specific dlls a database management so that when a user modifies an entry, others can not modify that entry should i use entity framework or should i go old school with db and class creation

any links on the above will be greatly appreciated

thanks a lot!

That's not gonna be covered by a single book or tutorial, trust me. You need to decide a UI framework, data access technology, patterns and the overall architecture. And of course you need an in-depth knowledge on .NET framework, & how the CLR works. It's nothing C# specific. Since you have UI customization (Panels) requirements, WPF is definitely a better candidate for UI framework.

That being said -

  • For C#: Pro C# 2010 and the .NET 4 Platform

  • .NET & CLR: CLR via C#

  • UI Framework - WPF: Pro WPF in C# 2010

  • Use MVVM with WPF. MVVM will keep you on track maintaining the Separation of Concern. You can follow Microsoft's Prism guideline. For large applications with sophisticated UI requirements Prism is a better choice. You might need to use Dependency Injection. MEF is there to go hand-to-hand with MVVM & Prism.

  • Yes, Entity Framework can handle concurrency issues, but that its available in almost all data access framework. Entity Framework provides lots of other facilities, but when using it you should have clear idea of what you're doing. Programming Entity Framework is definitely gonna help.

Kind of a broad subject but two books I would recommend giving a read regardless of what language you are doing or the specifics of your project:

If you have specific questions about how to accomplish something I would post it on here or google it.

Microsoft .NET: Architecting Applications for the Enterprise - with a very good code example and there is a chapter on concurrency

Professional Enterprise .NET

ASP.NET 3.5 Website Programming: Problem - Design - Solution

I guess, there are not any online recources that could compete the complexity of these books.

Could someone provide a very high-level overview of .NET memory management?

More specifically I'm looking for an overview of memory management..

  • is there an overall .net heap?
  • are heaps application based?
  • when I run my application is a new heap created/memory allocated or is the memory from the overal .net heap?
  • what happens when the .net heap runs out of its original memory? does it request more from OS?
  • the basics would be a great start for me to then go-on and read more

Each process has its own heap - and if more memory is needed after the GC has cleaned up everything it can, the process asks the OS for more information.

The best resource I know about for this sort of information is Jeffrey Richter's CLR via C# book.

I'm interested in use cases for netmodules in .NET. In particular, I've been looking into better ways to break up solutions in .NET but not have quite as many assemblies to deploy. Netmodules are a very interesting idea, but they appear to break debugging and are not natively supported in Visual Studio (though they are for MSBuild). I'd prefer to rely on something native to .NET, so ILMerge, while interesting isn't what I really want.

For some of my own projects, I'm also beginning to use FAKE, which allows for some interesting build steps, such as separating out test files. In other words, writing custom compile steps is not a problem.

A netmodule on its own is practically worthless: Their types and code cannot be loaded and executed by the runtime environment. You can only load types and execute code from assemblies, so it's quite likely that you will eventually combine several netmodules into a (multi-file) assembly. So let's take a look at the benefits of these.

Jeffrey Richter mentions three uses for multi-file assemblies in his book CLR via C# (p. 44), two of which result from the use of netmodules:

  1. "You can partition your types among separate files, allowing for files to be incrementally downloaded […]. Partitioning the types into separate files also allows for partial or piecemeal packaging and deployment for applications you purchase and install."

    At least Microsoft's implementation of the CLI (.NET) seems to load multi-file assembly incrementally, and not in its entirety right from the start. A module from an assembly only appears to get loaded from disk (or from the network?) when a type inside it is actually needed.

  2. "You can create assemblies consisting of types implemented in different programming languages. […]"

    I'm not certain that this actually adds much value in real-world scenarios, (a) because Visual Studio doesn't support project references to netmodules, and (b) because you can get the same benefit with assemblies.

    There's one notable difference between a multi-assembly and multi-file assembly approach: One assembly cannot by default access another assembly's types that have internal/Friend (i.e. assembly) visibility. If you were compiling to modules instead and then link them into a single multi-file assembly, a module compiled from C# could access internal types of a module compiled with VB.NET (and vice versa).

    You'll find a brief demonstration of this below.


    CsharpClass.cs:

    internal class CsharpClass { }
    

    VbClass.vb:

    Friend Class VbClass : End Class
    

    Program.cs:

    public static class Program
    {
        public static void Main()
        {
            var vbClass = new VbClass();
            var csharpClass = new CsharpClass();
        }
    }
    

    Build script for netmodules:

    csc.exe /t:module /out:CsharpClass.netmodule CsharpClass.cs
    vbc.exe /t:module /out:VbClass.netmodule VbClass.vb   
    csc.exe /t:exe /out:Program.exe /addmodule:CsharpClass.netmodule /addmodule:VbClass.netmodule Program.cs
    

    This build will work and execute without any errors.

    Note that there is nothing magical about the .netmodule file extension; this is only a convention, but the output file is a regular .NET DLL.

    Build script for assemblies:

    csc.exe /t:library /out:CsharpClass.dll CsharpClass.cs
    vbc.exe /t:library /out:VbClass.dll VbClass.vb
    csc.exe /t:exe /out:Program.exe /r:CsharpClass.dll /r:VbClass.dll Program.cs
    

    This build will fail because:

    Program.cs(5,27): error CS0122: 'VbClass' is inaccessible due to its protection level
    Program.cs(5,23): error CS0143: The type 'VbClass' has no constructors defined
    Program.cs(6,31): error CS0122: 'CsharpClass' is inaccessible due to its protection level
    Program.cs(6,27): error CS0143: The type 'CsharpClass' has no constructors defined
    

In DDD examples I often see the use of methods where I would probably have used a property. Why is this?

For example (from Strengthening your domain: Aggregate Construction)

public class Order
{
    public bool IsLocal()
    {
       return Customer.Province == BillingProvince;
    }
}

One argument for choosing methods instead of properties is when there would be any code that does something. If it just returns some internal field value then use property. If it has any logic inside or does any calculation use method. This makes it clearer to client of code that there is something happening when you call this method.

I think I've read in CLR via CSharp that Microsoft regrets making DateTime.Now a property instead of method. It returns new value every time you call it. That should be method not property.

I was asked the following question in an interview:

There is a fixed size queue of tasks. Threads want to enqueue task. If the queue is full they should wait. The threads order should remain: if thread1 came with task1 and after that thread2 came with task2, task1 should enter the queue before task2.

Other threads want to dequeue tasks and execute it. If the queue is empty, they should wait, and also their order should remain: If t3 came before t4, t3 should enqueue task before t4.

How to achieve this (in pseudo-code)?

  1. Simple solution In .NET 4.0 were introduced namespace System.Collections.Concurrent, class from it are working quite right - I couldn't achieve some error from them.
    ConcurrentQueue and BlockingQueue are the place to start your research. But I think your question is not about the standart solution - that's bad answer on the interview, so:
  2. Solution based on Jeffrey Richter's book information:
    Base code (C#):

    internal sealed class SynchronizedQueue<T> {
        private readonly Object m_lock = new Object();
        private readonly Queue<T> m_queue = new Queue<T>();
    
        public void Enqueue(T item) {
            Monitor.Enter(m_lock);
            // After enqueuing an item, wake up any/all waiters
            m_queue.Enqueue(item);
            Monitor.PulseAll(m_lock);
            Monitor.Exit(m_lock);
        }
    
        public T Dequeue() {
            Monitor.Enter(m_lock);
            // Loop while the queue is empty (the condition)
            while (m_queue.Count == 0)
                Monitor.Wait(m_lock);
            // Dequeue an item from the queue and return it for processing
            T item = m_queue.Dequeue();
            Monitor.Exit(m_lock);
            return item;
        }
    }
    

    This class is a thread-safe, but still doesn't check the order - and here is a many ways to implement that. From the same book:

    ConcurrentQueue and ConcurrentStack are lock-free; these both internally use Interlocked methods to manipulate the collection.

    So, you must remove Monitor class usage, and provide check for your thread to being next one to enqueue item. This can be done by maintaining the number of current adders and current queue length in the private field. You should make this fields volatile.
    You should use Interlocked.Exchange to get your current adders and Interlocked.Read to get your current queue length.
    After that, you have unique number for your thread - current length + current adders. Use SpinWait class to spin around while current length will not became equal to your number, after that enqueue item, and leave the Enqueue method.

I strongly recommend you to study this book chapters about multithreading and locks - you'll be much more prepared for this type questions in your life. Also try to search similar questions here. For example:

Creating a blocking Queue<T> in .NET?

I know C,C++,COBOL.

Now I am trying to learn C# and I want to do some hobby projects with C#.

So can you suggest where do I start from.

I searched on google but I want to start from a book which gives me more practice problems for a new comer to .net

Can anybody suggest a great book online which I should really start from?

Everyone learns a little differently, so I've included a few different types of resources.

Books

It seems that one of the biggest challenges for a COBOL programmer to move to a language like C# is the Object-Oriented way everything is done. "Everything is an object" is a pretty good generalization within C#, and certainly good enough for a beginner. So, the first suggestion is a book about Object Thinking. It attempts to introduce objects for a philosophical and historical perspective. It specifically discusses some of the differences between procedural languages and OO languages. Now, it is a bit academic (written by a professor) but there's a good fundamental basis here.

Once OO is understood, there are a number of C# books available. Many people recommend Richter's CLR via C# which is a spectacularly good book. If the person is a veteran to CS, you can't recommend a better, more thorough book on C# and the CLR. For a more "approachable", feature-oriented way, I've always found Troelsen to be excellent.

Websites

Another approach is to compare and contrast syntaxes. Someone fluent in COBOL will think in COBOL when first attempting to write C#. So here is an article on CodeProject that does a side-by-side comparison of VB.NET, C#, and COBOL. It's not a complete overview, but it could be a good reference for someone trying to figure out how to, let's say, write a loop in C#. There is also this blog post which is more to the effect of taking C# and converting to COBOL. Still, the comparison between the two may be helpful.

Training

For those that need instructor-led courses, Microsoft offers Getting Started with Microsoft .NET for COBOL Programmers. Exactly where this would be offered, however, may be a challenge.

Coding

Fujistu makes a cool product called NetCOBOL for .NET. Nothing beats writing code. Here, you can write COBOL code within Visual Studio to produce Microsoft's Intermediate Language (MSIL) which runs on the CLR (how cool). Using this, a COBOL programmer could write OO COBOL, but leverage the .NET Framework. Perhaps using this, you could go the next step and use Reflector to decompile the IL into C#, VB, etc. The web-site doesn't list a price which means "If you have to ask, you can't afford it." Also, the goal here ISN'T to write more COBOL, so this may be a highly-addictive crutch to make the transition to C#.

Videos

Fujistu also has published a series of .NET for COBOL programmers on youtube. The intro video is located here and the first lesson is here, but anything by the user fujistucobol would be good.

What does it mean in .Net: try-catch block without any Exception as parameter for catch?

First of all, a little foreword. The CLR allows an instance of any type to be thrown as an exception; for example it is possible to throw System.String or even System.Windows.Forms.Form object. However, the C# compiler allows throwing only Exception-derived objects. So the only way to catch non-CLS-compliant exception was to have an empty catch() block in your code.

Prior to version 2.0 of the CLR non-empty catch blocks (i.e. catch (Exception ...)) were catching CLS-compliant exceptions only. But in version 2.0 of the CLR, Microsoft has introduced a new RuntimeWrappedException class so that when a non-CLS-compliant exception is thrown (from another language, for example) the CLR automatically constructs an instance of the RuntimeWrappedException class. Since then there's no need to have an empty catch blocks (i.e. catch()) anymore because catch (Exception ) would catch all exception anyway.

Hope this sheds some light.

For further information I can address you to Jefrey Richter's great book "CLR via C#", 3rd Edition of which is on sale now.

When you run a .NET executable, what exactly takes place, step by step in order. My basic understanding is that you run the executable, the CLR does some checking, compiles the CIL it into platform specific code, loads it up along with the specified required dll's (as specified in the manifest(s)) and runs your program.

Can someone elaborate on this, down to the "it allocates memory for this and that" level? I would really like to know what is happening from when you double-click on the executable to when your program is successfully running.

P.S. diagrams, external links welcome. :-)

One book to rule them all: CLR via C#.

I know that when objects are created in Heap, they also have extra two more fields:

  1. Sync Block Index
  2. Type Object Pointer

So I wonder when Type Object is created in Heap memory and what kind of data it holds? It only represents the metadata of the Type?

I haven't been able to find much detail about that.

The Type object also contains the bytes that back any static fields on the type as well as a method table with one entry per method defined within the type.

Each entry in the method table points to JIT-compiled native code if the method has been executed at least once.

The type object is created the first time the type is instantiated or the first time a static type member is referenced.

I highly recommend buying a copy of Jeffrey Richter's book, CLR via C# if you want to get a really deep understanding of what the CLR does. The section titled "How Things Relate at Runtime" in chapter 4 covers the .NET type allocation process on the heap in detail.

The May 2005 edition of MSDN magazine has an article titled "JIT and Run: Drill Into .NET Framework Internals to See How the CLR Creates Runtime Objects" with some good information as well, specifically the sections on Type Fundamentals and MethodTable.

I'm relatively new to C#, so please bear with me.

I am trying to understand how Task FromAsync works.

var task1 = Task<int>.Factory.FromAsync(Foo1, ...);  //what happens here? Is this 
called on a thread from threadpool?

SomeCode1(); // <- is this code executed in parallel with Foo1

task1.ContinueWith(Foo2,...);   //does this block the current thread until Foo1
 finishes? Shouldn't it act like a callback? If this whole code runs on a "normal"
thread does it block it? If this runs on a thread from a thread pool does it 
 release the thread until Foo1 finishes?

SomeCode2();  

Thank you for your help, I'm really struggling with async programming.

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

I'm trying to understand the correct structures of a program here to facilitate everything. Basically where to "put" things.

For example:

You have 2 classes.

Class 1 is your main.

Both classes have many methods.

Class 1 calls for an instance of Class 2 and runs a method. This method is supposed to return a value.

Question 1: Should I have a try/catch block INSIDE this method (in Class 2)?

Question 2: Should the try/catch block be where I call the method (in Class 1)?

try
   method();
catch
...

Question 3: When executing the method that is in Class 2, when it comes to returning a value, should I ever return "an error code" and then deal with this code in the calling class?

Question 4: When an error happens and I need to "halt" the program, should I use if/else statements so the code only moves forward if the correct conditions are met or should I use the keyword "break" more often?

Question 5: The possibilities for errors could be endless, specially if you have medium to large programs. How do you guys deal with unknowable errors which you might encounter while the user is running your program?

I in general agree w/ David and Peter... The one thing I would add is to be careful about exceptions you catch when you catch them... Richter has a very interesting chapter on exception handling and how exceptions were SUPPOSED to be inherited versus how they have actually been implemented... But even still, it's (IMO) lazy or at least ill-thought-out if you find yourself consistently catching the generic Exception class...

If you're doing file reading/writing, you may very well want to catch appropriate IO exceptions, but to consistently catch the most generic Exception class can lead you to problems if say, a NullReferenceException gets thrown and your try/catch was only protecting against IO Exceptions... Your catch block would try to fix (what it assumed was) an IO exception and it could put your code in a horribly unstable state.

Additionally, be very careful about continuing to re-throw the original error unless you're convinced you TRULY handled it appropriately... If you wrote a library and published it and swallowed all the errors because you thought you were doing the best thing, then someone that consumed your library would have no way to debug what was going on... Exceptions also get thrown into the servers logs, so a swallowed error would never make it there.

The one place that I would advocate catching the generic error is right at the UI layer where you obviously don't want to show the user a YSOD, but even then your catch should likely do some logging or something to help you debug later.

In CLR via C#, Jeffrey Richter gives the following example of delegate chaining (pg. 406):

internal delegate void Feedback(Int 32 value);

Feedback fb1 = new Feedback(method1);  // in the book, these methods
Feedback fb2 = new Feedback(method2);  // have different names
Feedback fb3 = new Feedback(method3); 

Feedback fbChain = null;
fbChain = (Feedback) Delegate.Combine(fbChain, fb1);
fbChain = (Feedback) Delegate.Combine(fbChain, fb2);
fbChain = (Feedback) Delegate.Combine(fbChain, fb3);

Why does the first call to Delegate.Combine have to pass in a null Delegate? Here's how I would have thought it should be written:

Feedback fbChain = (Feedback) Delegate.Combine(fb1, fb2);
fbChain = (Feedback) Delegate.Combine(fbchain, fb3);

Correct - you don't have to start with a null. What Delegate.Combine does is return a new delegate with the invocation list of the first argument appended with the invocation list of the second argument. If one of the arguments is null it just returns the other delegate you passed in.

Also, you don't have to use Combine directly. You can do this:

Feedback fbChain = method1;
fbChain += method2;
fbChain += method3;

or

fbChain = new Feedback(method1) + new Feedback(method2) + new Feedback(method3);

as + for delegates maps onto Combine. This is also typechecked by the compiler, rather than having to use Delegate.Combine (which will only fail at runtime if the signatures don't match)

What is the difference and advantage between having a single file assembly that is physically coded in multiple .cs files and a multi file assembly that has multiple .NetModules??

My prof says that the difference could be realized when these assemblies get loaded or during jitting. That not all .Netmodules of a multi file assembly will be loaded at once. But even he is not sure. Could anybody clarify me?

Lets assume that we have two .cs files called
RUT.cs, which contains rarely used types
FUT.cs, which contains frequently used types
Now csc /t:module RUT.cs
This line causes the C# compiler to create a RUT.netmodule file. This file is a standard DLL PE file, but, by itself, the CLR can’t load it.

Next let’s compile the frequently used types into their own module. We’ll make this module the keeper of the assembly’s manifest because the types are used so often. In fact, because this module will now represent the entire assembly, I’ll change the name of the output file to JeffTypes.dll instead of calling it FUT.dll:

csc /out:JeffTypes.dll /t:library /addmodule:RUT.netmodule FUT.cs

This line tells the C# compiler to compile the FUT.cs file to produce the JeffTypes.dll file. Because /t:library is specified, a DLL PE file containing the manifest metadata tables is emitted into the JeffTypes.dll file. The /addmodule:RUT.netmodule switch tells the compiler that RUT.netmodule is a file that should be considered part of the assembly. Specifically, the /addmodule switch tells the compiler to add the file to the FileDef manifest metadata table and to add RUT.netmodule’s publicly exported types to the ExportedTypesDef manifest metadata table. enter image description here

The RUT.netmodule file contains the IL code generated by compiling RUT.cs. This file also contains metadata tables that describe the types, methods, fields, properties, events, and so on that are defined by RUT.cs. The metadata tables also describe the types, methods, and so on that are referenced by RUT.cs. The JeffTypes.dll is a separate file. Like RUT.netmodule, this file includes the IL code generated by compiling FUT.cs and also includes similar definition and reference metadata tables. However, JeffTypes.dll contains the additional manifest metadata tables, making JeffTypes.dll an assembly. The additional manifest metadata tables describe all of the files that make up the assembly (the JeffTypes.dll file itself and the RUT.netmodule file). The manifest metadata tables also include all of the public types exported from JeffTypes.dll and RUT.netmodule

Now if some clinet code refrencing to JeffTypes.dll is executing, When a method is called for the first time, the CLR detects the types that the method references as a parameter, a return value, or as a local variable. The CLR then attempts to load the referenced assembly’s file that contains the manifest. If the type being accessed is in this file, the CLR performs its internal bookkeeping, allowing the type to be used. If the manifest indicates that the referenced type is in a different file, the CLR attempts to load the necessary file, performs its internal bookkeeping, and allows the type to be accessed. The CLR loads assembly files only when a method referencing a type in an unloaded assembly is called.

This means that to run an application, all of the files from a referenced assembly do not need to be present.
So, less used source classes could be compiled in NetModules and loaded when necessary, boosting performance and less Dll file sizes eases change management and deployment process.

Images and some of the quotes from jeffrey richter

when we talk about the windows memory architecture => we talking about the virtual memory manager that 'give' chunk of memory to the application manager heap that allocate the memory size that the application ask.

( http://msdn.microsoft.com/en-us/library/ms810466.aspx )

But in .net => is the .net managed heap is 'asking' memory from the virtual memory manager ( i'm almost sure this is the case ) or there is some layer between the .net managed heap and the virtual memory manager ?

( this question has no connection to GC )

The .NET runtime basically acts as a memory manager for the managed heap. So every time you new an object it either advances the pointer on the gen0 GC heap (which may trigger a collection) or allocates a chuck on the Large Object Heap. The latter is similar to a regular CRT heap in that it uses a free list.

The GC heap itself is stored in segments which are allocated/freed to the OS as needed. This means that managed memory usage is usually not reflected immediately on the process level.

You can inspect how the managed heap is built from different segments through the SOS debugger extension which can be loaded in WinDbg (it can be loaded in VS as well, but the experience is a little rough if you ask me).

There are two books that come to mind: CLR via C# and Shared Source CLI. They both cover this to some extent.

Where can i find information about whats going on behind the scene when Im creating a new thread ?

when i write

    Thread t = new Thread ()
....
t.start()....

i want to know what actually is going on... can you please redirect me ?

Just so it's here as an answer, Jeffrey Richter's CLR via C# will probably† teach you stuff you don't know about CLR internals.

And here's Joe Duffy's Concurrent Programming on Windows

† in a statistical sense

Can anyone tell a book which covers a in-depth coverage of .NET Framework (2.0, 3.5 or 4.0)?

Does JITting occur per-assembly or per-method? How does this affect the working set

I agree with Daniel.

If you have access to it, Jeffrey Richter's CLR via C# book provides an excellent overview of how JIT'ing occurs and how the CLR handles the results. It's a clear and concise explanation.

I have checked many books but couldn't find any good book. I am interested in book from where I can learn OOP concepts with examples in an easy way. Book like Java Black book

I can recommend Pro C# 2010 and the .NET 4 Platform for learning OOP with C# - I have the 2008 version of that book and it covers all the fundamentals - and once you got those down, the book offers much more as well.

Two excellent books that I would recommend are:

CLR via C# by Jeffrey Richter

and

Clean Code by "Uncle" Bob Martin

Richter's book will give you all of the details about the aspects (programming and OOP capabilities) of C#, and Martin's book will give you guidelines on writing proper code in an OO environment. Martin's book is geared towards Java, but the concepts apply equally to C# (IMHO).

The Head First OOA&D book that Mitch mentions in comments is also excellent. Probably the combination of all three will make you unstoppable. :)

Hope this helps!

I recently asked a developer to write a library using the new multithreading capabilities of .NET 4.0.

He's done a great job, but I'm concerned that the Task logic is repeated throughout the code and not nicely encapsulated.

I'm also concerned that this creates a problem when it comes to testing. Normally, I test by creating a seam in the code by creating an interface and a stub/mock object to run my tests against.

I suppose this is possible using this way of doing things. It just seems that the production code logic would be very different than the test logic.

Is the solution to make tests that are parallel as well, and just repeat the Task logic in them? Or have people thought up patterns where much of the Task handling logic can be encapsulated for easy duplication?

Thanks!

Task task = Task.Factory.StartNew(() =>
        {
            if(cancellationToken.IsCancellationRequested)
            {
                throw new OperationCanceledException();
            }

            if (_bookHeader.EncryptionType != 0)
            {
                throw new MobiException("The book is encrypted");
            }

            ExtractText();

            partReady(66.66f);
        }, cancellationToken);

        Task opfTask = task.ContinueWith(antecedent =>
            {
                if (antecedent.Status != TaskStatus.Canceled)
                {
                    OpfDocument opf = CreateOpf();

                    partReady(80);

                    MobiDocument book = new MobiDocument()
                    {
                        Contents = _mobiHtml,
                        Description = opf,
                        Header = _bookHeader,
                        Sections = _sections
                    };
                    Document = book;


                    GC.Collect();

                    partReady(100);
                }
            });             

        return opfTask;
    }

I'd be surprised (but delighted) if it's possible to better the last 3 chapters of CLR via C# 3rd Ed by Richter for getting a great handle on the landscape of parallel stuff in .NET 4. (Just read Effective C#, Second Edition and can't say the same for it's coverage of TPL and PL)

One reason I feel this is relevant is that he talks a lot about how to make the code clean and maintainable (and some stuff in PowerThreading that he's used quite a bit). (And in the unlikely event you're not aware of the book, it's the CLR book to have, and the 3rd Ed is a significant upgrade of the 2nd Ed)

I've been coding c# for close to 4 years now (vb.net before that) in an ASP.NET web forms environment. I've got the basics down but there are some things that I sometimes see that confuse me (interfaces, IEnumerable, IQueryable, reflection, etc..) that I'd like to grasp. I'm currently using c# 3.0 and will probably be moving to c# 4 in the next year or so. I'm currently learning MVC.

At my point in my programming career, what books, blogs, or resources could you guys recommend? Thanks!

ASP.NET MVC beginners book get ASP.NET MVC 2.0 cookbook. Its just for beginners and to learn core concepts of asp.net mvc 2.0 its very good.

Go deep. Read up and understand the internals of how the CLR works:

CLR Via C#, Third Edition by Jeffrey Richter

And understand the latest\greatest C# language features:

C# in Depth, Second Edition, by Jon Skeet

Don't be stuck only in C# and .NET; think about the bigger picture of computing, that's what I've done. Algorithms are the most important, as they govern how things like IQueryable and the other sorting interfaces work.

Algorithmics: The Spirit of Computing (3rd Edition)

Also worth looking at:

The Architecture of Computer Hardware and Systems Software: An Information Technology Approach

These are some course material I've come by, and I've really enjoyed them so far. I also am a big fan of C#, but I've benefited from getting down (low level) and dirty with these books.

One other one worth mentoning is:

Engines of Logic

This covers the history of computing and software, via some mathematical geniuses from the last century and before. People like Liebniz and Goedel, Von Neuman and Alan Turing.

Hope you find something interesting there. It's a bit off-topic for C# but for flexing the computer brain muscles, they're really good.

"...defines the syntax, order of evaluation of operands and operators, and the meaning of expressions."

of course...

-edit-

I almost forgot...

More and more I realized that without jumping into the code details, I cannot really understand the how CLR works.

So could you recommend some good books on SSCLI (Shared Source CLI)?

Many thanks.

There's Shared Source CLI Essentials.

For detailed information on the CLR, Jeffrey Ricther's CLR via C# is really useful. Make sure to get the recently published 3rd edition as it has updated info on CLR 4.

Also, check this question.

My programming language is C# .Net 3.5 and I may have to install my applications in very old client systems (windows XP-SP1 and above) and may be that those systems do not contain any version of .Net (or even Windows-Installer-3.1) in them. I have worked on VS-2008 deployment projects on and off since some time and I have some working knowledge of it. I want to write a deployment project in VS-2008 but I have 2 questions :

  1. Can a VS-2008 deployment project containing pre-requisites run on a system without any version of .Net (or even Windows-Installer-3.1) pre-installed in the system ?
  2. How to create a boot-strapper installer to run in systems without .net pre-installed in them (boot strapper will install all pre-requisites including .net and other 3rd party run times) ?

Regards

Akshay Mishra

No, because there are not just DLLs, there is common language runtime needed to execute your program. Read the great book by Richter to better understand what happens when you create a program using .net libraries and its lifecycle.
By the way, i'm not quite sure, there must be some older version of .net installed with SP1. So may be you consider changing your application to use .NET 2?
UPDATE
May be you want to add .NET to your setup as prerequisite? You can add them without creating bootstrapper packages. See the article: http://www.codeproject.com/Articles/35976/Add-Prerequisites-of-NET-Framework-in-Visual-Studi

When I have a static field/property which lives in my application pool for the life of the application pool, where does it live in memory? I'm assuming its promoted into gen2 and lives out its days there? (assuming its small enough not to go into the LOH)

Static properties live in the heap in the memory space allocated to the type object for the type/class. They are loaded at the same time the type is loaded.

Static properties cannot be garbage collected. Type object can never be unloaded.

End of the chapter 4 of the book CLR via C# explains it. Here is a small snippet diagram:enter image description here

This is just a portion of the diagram (cannot copy fully because of the copyright) and shows Employee type object with its static fields. Type object is similar to all other objects and has a pointer to its type which happens to be System.Type.

Can anybody reccomend books or other online resources for MultiThreaded Windows Forms in C# ? I am mostly interested to learn more about this topic especially in the context of a GUI application that sends messages and listens in the background for responses from the server.

Many Thanks, MK

I'd second CLR via C#, but Concurrent Programming on Windows by Joe Duffy does multithreading and concurrency in much more depth if that's what you're looking for.

EDIT: Windows Forms 2.0 Programming by Chris Sells also has coverage of the topic and is a very good (and readable) general WinForms book if you dont already have one

Bill Wagner's More Effective C#: 50 Specific Ways to Improve Your C# addresses this topic, along with many other useful ones.

I don't know if there are any specific books on WinForms and multithreading. There are books which discuss the .NET Asynchronous Programming Model, which is used considerably in WinForms and WPF programming.

Try Programming .NET Components by Juval Louwy (OReilly Press) as well as CLR via C# by Jeffrey Richter (Microsoft Press). That ought to get you started.

Can anyone suggest any books or websites which go into detail about how the CLR works? I've been trying to learn more about the detail of how my applications execute, but have found a relatively small number of resources.

There are a few great blog posts on MSDN, such as this one about object lifecyles. I've also recently bought Jeffrey Richter's excellent CLR via C# which provides a great overview of how pretty much every C# construct translates into CLR.

I still want more detail though - it'd be great to cover every topic in CLR via C# in the same level of detail as the MSDN article. Any suggestions for blogs/books/articles which go into significant depth on the CLR?

I've heard that Compiling for the .NET Common Language Runtime (CLR) is quite good (but haven't read it myself).

From To Many days I am searching for a detail document which will help me to understand garbage collection done by CLR with example of some lines of coding including some functions,class, value type and reference type. Please share with if there is certain document which shows it step by step.

If you want to get into the more general topic of garbage collection take a look at the book Garbage Collection: Algorithms for Automatic Dynamic Memory Management.

I know it is not good practice to catch System.Exception unless on the top level of an application. What about a thread? Is it okay to catch System.Exception on the top level of the thread?

Update: The thread is a long running thread that should only be terminated when the application stops. So in order to make sure that the application does not crash I simply catch System.Exception and log the error. Everything is recreated.

        while (Terminate == false)
        {
            var discoveryClient = new DiscoveryClient(new UdpDiscoveryEndpoint());

            try
            {
                var criteria = new FindCriteria(typeof(T));
                criteria.Scopes.Add(new Uri(Scope));
                var discovered = discoveryClient.Find(criteria);
                discoveryClient.Close();
                discoveryClient = null;

                // do something with the endpoints
            }
            catch (OutOfMemoryException e)
            {
                m_Logger.LogException(e, "Exception when trying to discover clients (Contract: {0})", typeof(T).Name);
                throw;
            }
            catch (Exception e)
            {
                m_Logger.LogException(e, "Exception when trying to discover clients (Contract: {0})", typeof(T).Name);

                if (discoveryClient != null)
                    (discoveryClient as IDisposable).Dispose();
            }

        }

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

I reading a book( CLR via c#)in the book writer speak about IL and managed module that managed module compiling in native cpu code and then execute in the book writer said that Managed module Is faster than Unmanaged module.my question is why Managed module Is faster than Unmanaged module but for in Managed module first compile to IL and then compile in native cpu.

(What I wrote below is not mine, it is copy-pasted from a book: CLR via C#, Page No 14)


There are many reasons why a managed code can outperform unmanaged code

When the JIT compiler compiles the IL code into native machine code at run time, the compiler knows more about the execution environment than an unmanaged compiler would know.

Some ways in which managed code can outperform unmanaged code

  • A JIT compiler can determine if the application is running on an Intel Pentium 4 CPU and produce native code that takes the advantage of any special instruction offered by the CPU. Usually, unmanaged application are compiled for the lowest-common denominator of the CPU and avoid using special instruction that would give application performance boost.
  • A JIT compiler can determine when a certain test always fail on the machine that it is running on. Consider the example

    if (num_of_cpu > 1)
    {        
    }
    

This code causes the JIT to not generate any CPU instruction if the machine has only One CPU.

  • The CLR could profile the code's execution and recompile the IL into a native code while the application runs. The recompiled code will be reorganized to reduce incorrect branch prediction depending on the observed execution patterns. Current version of C# do not do this, but future version might.

Is there anything in c# that you can use to create a collection of events like lists, hashsets, and a dictionary in this case? Thankyou.

Sure you can:

Dictionary<String, Delegate> m_events = new Dictionary<String, Delegate>();

In Jeff Richter's Book CLR via C# you can find a complete implementation of an EventSet class.

(Even if you don't have the book you can download the sample code from http://www.wintellect.com/Media/Default/Downloads/CLR_via_C_,_3rd_Edition_Code_by_Jeffrey_Richter_(January_20,_2010).zip. The class in question is in "Ch11-1-EventSet.cs".)

As far as the question goes what an event is:

Say you have this line of code in your class:

public event EventHandler<NewMailEventArgs> NewMail;

then the C# compiler will translate the line above into three constructs:

  1. A private delegate field. (Something like: private EventHandler<NewMailEventArgs> NewMail;

  2. A public add_Xxx method (where Xxx is the Event name) that interested subscribers can use to register a callback delegate with the event.

  3. A public remove_Xxx method (where Xxx is the Event name) that subscribers can use to unregister from the event.

(All the gory details can be found in section 11.2 of aforementioned book.)

So in other words the 'thing' you can store in your Event collection class is just a plain old delegate nothing else.

I want to know the internal working of .net when we doing any thing at application level. Like if in my project I will create an object of class then what happened in the behind of the scene in .net internal level or when I inherit a base class to a child class then how my child class get all method of base class what exactly happened inside the .net.

It might be a curious question but I want to know the internal depth and working of all. It is most appreciable, If anyone can suggest me a book, reading or a great article in this.

Imho, one of the best is "CLR via C#" By J. Richter

A good starting point is Charles Petzold's .Net Book Zero free book

In addition to CLR via C#, I also recommend Advanced .Net Debugging and the slightly-dated Debugging Microsoft .Net 2.0 Applications if you really want to dig deep into the internals.

I wonder if anyone could point me in the direction where I can read about the nuts and bolts of C#. What I'm interested in learning are method call costs, what it costs to create objects and such.

My aim of learning this is to get a better understanding of how increase the performance of an application and get a better understanding of how the C# language works.

The reference should preferable be a book, a book that I can read cover to cover.

You may need to know about Garbage Collection and CLR

CLR via C# is excellent for low level details about the CLR. It specifically covers the details of method invocation, creating new objects, garbage collection and lots more.

For actual performance numbers you should use a profiler to avoid the common pitfalls of premature optimization.

Just trying to ping up some experienced Thread gurus out there...trying to learn more about threading without many real code issues at the moment that would help me practice it more.

I've got some resources already but probably there are some good ones I do not know of out there:

  1. C# 2008 and 2005 Threaded Programming: Beginner's Guide (Book) (this is the one I'm thinking about starting to look at first)
  2. CLR via C# (Dev-Pro) (I have this book also and Jeffery has some threading stuff in here too)
  3. Threading in C# - eBook
  4. Concurrent Programming on Windows
  5. .NET Multi-threading Book from 2003 (Book) (not sure if this stuff is outdated...)

So:

1) Looking for others (videos, books, etc.) and also what your opinion is on the resources above (would you recommend certain ones as better or ones as outdated / bad?).

2) Also, since this is a broad and highly complex topic...being a complete foreigner to this, I'm trying to narrow down some kind of sane study list. Threading is deeeeeeeep so I just want to cover the basics or most likely the areas they'll probably touch (locking, thread safe, etc.). I don't need to go into this interview being an expert...just show that I am not completely clueless about when to use it, common scenarios and a couple examples I can explain to them.

3) Anyone with threading experience out there to point me to some good resources or give me some good study tips or areas you think I should most definitely hit up?

4) Obviously with the advent of .NET 4.0 that changes things altogether but I am focusing on .NET 3.5 mainly here. I need to just know the basics of THREADING first...the concept, things to be aware of, locking, thread safe singletons (I know John Skeet's page on Singletons, etc.).

5) Another thing that would help me are real world examples and reasons to use threading. Both on the IIS side, OOP side, server farms, ect. I'd like to know some real examples of use of threading or common scenarios in real life apps where you really need to start utilizing threading.

I don't need everyone to answer all 5 of my areas here...even just advice in one of the 1-5 above would be greatly appreciated.

Thanks...

UPDATE / DISCLAIMER (after receiving a few assumptions about me)

No I'm not going to go in there claiming I know threading or am an expert in it, but that I'm a beginner and have done only a couple things at a past job and still learning. But I did want to give the context in why I'm posting this entire thread here so you can help me hone in better in a shorter period of time...filter out a path that may be better so I don't waste my time both for the interview but also for my future learning.

Threading can seem very easy to learn. You just use new Thread(ThreadFunc).Start() and voila, you are using threading. How hard can it be, right?

Threading problems are not something that you will notice directly but are something that will sneak up when you least expect it. They usually come in production systems when there are some load and sporadically shut down your system.

After a while you will discover that you need to do synchronizing before modifying share data. And when you start doing so, you will see a large performance degrade.

Threading is easy to get going with, but will take years to master. Protecting shared data is an art and will need a lot of thought to get it done properly. I've written multi threaded servers for several years, both in C++ with IO completion ports and lately in C#. I still make mistakes that can produce unexpected result in my servers.

As for topics you need to learn:

  1. Look at some examples using Thread class.
  2. The lock keyword.
  3. Asynchronous programming (it's very easy to do this wrong, just look at all SO questions about it). .Net uses BeginXXXX/EndXXXX for async programming.
  4. Other locking techniques than lock, for instance Semaphore and ReaderWriterLock
  5. The Interlocked class.

I usually use this pattern for Thread functions:

public class Example
{
    ManualResetEvent _myEvent = new ManualResetEvent(false);
    Thread _myThread;
    bool _isRunning = true;

    public Example()
    {
        _myThread = new Thread(WorkerFunc);
        _myThread.Start();
    }


    public void WorkerFunc()
    {
        while (_isRunning)
        { 
            try
            {
                _myEvent.Wait(Timeout.Infinite);
                _myEvent.Reset();
                ActualFunc();
            }
            catch (ThreadAbortException) { return; }
            catch (Exception err)
            {
                 _logger.Error("Thread func failed, lucky we caught it so the server don't die..", err);
            }
        }
    }

    public void Stop()
    {
       _isRunning = false;
       _myEvent.Set();
       _myThread.Join();
    }

    public void DoWork()
    {
        //add some work to the thread job queue or something
        _myEvent.Set();
    }

    private void ActualFunc()
    {
         //actual thread work is done here
         // in a seperate method to keep everything clean.
    }
}

Just wrote it here in the answer, do not promise that it will work 100% :)

Ok, so the initial search in StackOverflow shows nothing related for this question. So here it goes:

Let's pretend for a moment that you're just getting started in a career in computer programming. Let's say that, for whatever reason, you decide to use the .Net framework as a basis for your programming. Let's also say that you've been exposed to some programming background, but not one in .Net, so it seems foreign to you at first. And lastly, you don't have the benefit of 25 years of exposure to the Win32 API, which explains why it seems so foreign to you when you start looking at it.

So the questions are:

  1. What is a comprehensive overview of what .Net is? It appears to be a combination of a runtime environment, a set of languages, a common set of libraries, and perhaps a few other things...so it's about as clear as mud. Specifically, what are the key components to .Net?
  2. What is the easiest way to understand .Net programming with regard to available APIs?
  3. Which language would best suit beginning programming out of the "stock" languages that Microsoft has to offer? (C++, C#, VB, etc.)
  4. What are some differences between .Net programming and programming in a procedural language (aka Pascal, Modula, etc.)
  5. What are some differences between .Net programming and programming in a "traditional" object-oriented language? (aka Smalltalk, Java, Python, Ruby, etc.)
  6. As I currently understand it, the CLR provides a foundation for all of the other languages to run on. What are some of the inherent limitations of the CLR?
  7. Given the enormous amount of API to cover, would it even be worth learning a .Net language (using the Microsoft APIs) given that you would not have prior exposure to Win32 programming?
  8. Let's say you write a for-profit program with .Net. Can you resell the program without running afoul of licensing issues?
  9. Let's say you write a gratis (free) program with .Net. Can you offer the program to the public under a "free" license (GPL, BSD, Artistic, etc.) without running afoul of licensing issues?

Thank you in advance for your patience.

What is a comprehensive overview of what .Net is? It appears to be a combination of a runtime environment, a set of languages, a common set of libraries, and perhaps a few other things...so it's about as clear as mud. Specifically, what are the key components to .Net?

CLR Via C# will explain that and a lot more.

As I currently understand it, the CLR provides a foundation for all of the other languages to run on. What are some of the inherent limitations of the CLR?

The above book will teach you all you need to know about the CLR.

Sometimes I dont know witch type of exception should I throw. So I usually throw Exception(). Is there some nice article about this?

The problem with throwing a generic exception is that it restricts the ability of your code further up the stack to handle it properly (i.e. best practice is to trap the most specific exception possible before falling back, and to only capture what you can handle).

Jeffrey Richter has an excellent section on exception handling (including info on the System.Exception namespace) in CLR via C#

"Framework Design Guidelines" by Cwalina and Abrahms covers this topic really well (IMHO).

It is available for free online here, or the book (not free) here (UK) or here(US). Look in the section entitled Design Guidelines for Exceptions.

The book of CLR via C# 3rd explains about the default global CSC.rsp file in page 35. What's the equivalent rsp file in mono?

I searched the mono directory to find

/Library/Frameworks/Mono.framework/Versions/2.8/lib/mono/4.0/xbuild.rsp
which doesn't have nothing in it.

The mono compiler currently doesn't use a separate file: the list of default assemblies is hardcoded in the source file (mcs/driver.cs in the sources). By default only System and System.Xml are loaded. The above holds for the command-line compiler, xbuild, Monodevelop or other tools may have different default sets themselves.

A somewhat equivalent for mono is the pkg-config file dotnet.pc, but you have to use the command line option -pkg to load it explicitly:

gmcs -pkg:dotnet myprogram.cs

Could some one refer me good article (PDF, web Link or Book Chapter) about ".net Framework Fundamentals". There is lot of material available on web but since i am new to .net that's why i am unable to decide what to study and what to leave. I have a programing background(C++) and now want to learn about .net, i am expecting to start learning from basic and then move towards more details.

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

I have a client who wants to transition off their old environment into .NET.

The client has a good grounding in basic OO concepts (their existing development environment supports this) and are expert developers, but need a quick "up to speed" introduction to the .NET framework (C# as the chosen language) for building Line of Business applications (they're keen on Silverlight).

Any recommendations?

I have learned about programming for 3 years from Assembly to BASIC to C and WPF, but I wonder that inside the reference book, did't much help me in creating a simple/ complex , a complete system. I never touch C# before and its totally different between C# and WPF, many source code provide a separate program without link to database , and when i tried to connected to database, my application is malfunction. I try to find a complete sample LOB app,but when i figure out why i download from Codeproject is very complicated ....and its MVVM ... a more complicated than what i think. I need a professional give me an advice ...I am a graduated diploma student and a WPF self learner.

i think u should read good books about CLR/C# (such as this) and more specifically about WPF (i recommend either WPF 4 Unleashed or Pro WPF in C# 2010)

also, u can find nice code samples at WPF samples

And ,finally, u should necessarily code ur own programs: more code - more experience

My background: 1. I recently graduated college (BS in CS), and have been working full time as a MOSS 2007 software developer for 7 months. Any server side code I write is in C# using asp.net 2.0. 2. I have mostly (Java, C) experience and a strong grasp of OOP from college.

What I'm looking for: A book on asp.net 2.0 that will help me understand the framework. If code examples are in C# or there is additional information on C# development, that is a plus, but my primary goal is to understand how the framework works. For example, I know that Page_Init gets called, then Page_Load, etc but how does that work internally? Any recommendations?

Right now I'm looking at the following books: Professional ASP.NET 2.0 Programmer to Programmer, Professional ASP.NET 2.0 Special Edition, CLR via C#

Given the info above, can anyone help me limit my choices? I like the reviews for CLR via C# the best, but I'm not convinced that it will provide enough info about asp.net itself. For the other two titles, I'm wary that they assume too much knowledge of asp.net v1, but I have no such experience. Thanks.

CLR via C# is not a book about ASP.NET but it's a must for any developer working in .NET to understand it's inner workings. I say again, a must.

Either of mentioned ASP.NET books are good and provides what you need.

Possible Duplicate:
How delegates work (in the background)?

As we know delegate is function pointer.

How it is working internally?

Detailed explanation will be appreciated.

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