C# Frequently Asked Questions : C# Language 2.0

Is it possible to output the command-line used to build a project in Visual Studio?

CSharpFAQ — Wed, 01 Dec 2004 01:54:00 GMT

Now that Whidbey has been out in Beta for more than a few months, it seems worth revisiting some frequently asked questions which have different (better?) answers now.

In Everett (v7.1) the answer used to be No.

However, in Whidbey (v8.0), the answer is Yes (and No).

For the yes part of the answer, after building, go to the Output Window, select "Show Output from: Build", and about half way down you will see a section like this:


Target "Compile" in project "ConsoleApplication1.csproj" 
Task "Csc" 
Csc.exe /noconfig /warn:4 /define:DEBUG;TRACE /debug+ /optimize- /out:obj\Debug\ConsoleApplication1.exe /reference:C:\WINDOWS\Microsoft.NET\Framework\v2.0.31125\System.Data.dll, C:\WINDOWS.0\Microsoft.NET\Framework\v2.0.31125\System.XML.dll, C:\WINDOWS\Microsoft.NET\Framework\v2.0.31125\System.dll /target:exe /win32icon:App.ico AssemblyInfo.cs Class1.cs 
The task is invoking the IDE's in-process compiler to perform the equivalent of the above command-line.

Now for the no part of the answer. The project system does not actually execute this command line as part of the build process. As the output says, the IDE directly calls its own in-process compiler to perform the equivalent. However, in all cases, you should get the same results using the command line suggested in the output window. If you don't, you could be looking at a bug.

Note: before you cut and paste the build output to the command line, remember to add the path to CSC.EXE

[Author: SantoshZ]

Why does C#'s iterators feature spit out a class definition instead of a struct definition?

CSharpFAQ — Tue, 20 Jul 2004 17:30:00 GMT

Q: Why does C#'s iterators feature spit out a class definition instead of a struct definition?

The iterators feature in C# generates classes that implement the enumerators required. This is detailed in the C# Specification. Why doesn't it use structs, which would be more efficient.

There are two reasons.

(1) Naming. We generate classes that implement the enumerator interfaces and then use only the interface types in the public protocol. That way the names of the generated classes are purely an implementation detail. This is highly desirable from a versioning perspective. With a struct-based implementation, to get any of the efficiencies associated with structs we would have to use their types in the public protocol (using interfaces the structs would just get boxed). That in turns means we'd have to invent a name mangling scheme for the structs. In particular, iterators returning IEnumerable<T> would be complicated because a type could have multiple such members that differ only in their parameter list, meaning that the parameter list would have to be part of the mangled name.

(2) Structs don't work in recursive cases. For example, a TreeNode type could implement an iterator that recursively iterates first the left and then the right subtrees by foreach-ing contained members that are also of type TreeNode. With a struct-based implementation this would translate into an enumerator struct that contains a field of its own type--which isn't possible. (Think of it this way: A foreach statement obtains an enumerator and stores that in a local variable. In iterators, local variables are transformed into fields in the enumerator. A recursive iterator would therefore create a struct with a member of its own type.) You could argue that we can detect whether or not iterators are recursive and adjust our code generation scheme accordingly. However, you then end up with a versioning problem when a previously non-recursive iterator changes its (supposedly private) implementation to become recursive.

Anders (via Eric)

Why don't nullable relational operators return bool? instead of bool?

CSharpFAQ — Tue, 25 May 2004 18:51:00 GMT

Q: Why don't nullable relational operators return “bool?” instead of “bool“?

Nullable types are a new feature of C# 2.0.

When dealing with nullable types, if you write the following:

int? i = 15;
int? j = 16;

the type of

i == j

is a normal bool, rather than a bool? (ie nullable bool). Why?

A: In our initial designs, we spent a fair amount of time discussing what the behavior should be here, and how we should cross over from the three-valued nullable world to the two-valued “normal C#“ world.

Consider the following method:

void Process(int? p)
{
    if (p == null)
    {
        // do some processing...
    }
}

This seems like a very natural thing for a C# user to want to write. But if equality is three-valued, comparing anything to null always returns a null value (ie null isn't equal to anything), and therefore such a comparison can never succeed. Instead, the user would have to write:

if (!p.HasValue)

or something similar. We decided that the value of having a model that was consistent with the way users were used to dealing with reference null was pretty high, and therefore decided to make the relational operators return bool.