Archive for October, 2005

This is a bit off-topic, but bare with me 🙂

My good friend Yaniv just discovered something a bit wierd in C# 2005 regarding Nullable types.

Consider the following piece of code:

DateTime? modified;
modified = row.IsmodifiedNull() ?
null : row.modified;

What it basically does is sets null to “modified” if row.IsmodifiedNull() returns true or sets row.modified into “modified” if row.IsmodifiedNull() returns false.

This code cannot be compiled. The compiler yelled that it cannot set null to “modified” even though modified is defined as a Nullable type.

This code is actually equivalent to the abobe code, doesn’t use the “?” syntax and DOES compile:

if (row.IsmodifiedNull())
{
modified = null;
}
else
{
modified = row.modified;
}

After further investigation, Yaniv changed the code to the code below and it did work:

modified = row.IsmodifiedNull() ? (
Nullable<DateTime>)null : row.modified;

Its reasonable to assume that the “?” syntax is eventually translated in compile time into an “if” statement so why in a normal “if” statement setting “modified” to null works and in the “?” syntax it does not.

Bug? Feature?

I wonder who can comment on this.

I had a stupid problem today compiling MDbg in VS2005 and I thought I should share it with you so others won’t waste 10min for their lives.

I have both VS2003 and VS2005 (the RTM of course 😉 ) installed on my machine.

The MDbg source code that I talked about in the previous post, has one assembly called corapi2 which only includes IL source code since it has a few COM marshaling trickes that are not covered by IL code generated from C#.

corapi2 has a .csproj file and is a part of the MDbg solution for ease of use. it doesn’t compile C# code, but rather run a post build command that runs ILAsm.

I tried to compile the soultion but it failed saying that it cannot recognize the interface ICorDebugProcessEnum.

I started to investigate and saw that it is suppose to be declared in corapi2.
I dropped corapi2.dll into Reflector and saw no .NET code. Strange.

I tried manually compiling it and go a funny error about uint32 in line 88. Go figure.
Then I noticed that I’m running ILAsm of Framework 1.1 and not Framework 2.0 since, for some reason I have the Framework 1.1 folder in my PATH environment variable.

I open the the Visual Studio 2005 Command Prompt, changed dir to the Mdbg folder and run nmake (which is the other option of compiling it) and it compiled with no special problems :-).

Beware of the PATH!

I just wanted to remind you that according to the post in the 10th of August in Mike Stall’s blog, the MDbg that worked on Beta 2 is also intended for use in the RTM release of .NET Framework 2.0.

You can get it from here.
It includes FULL source code for the debugger (which is a pure C# application) as well as additional samples and an extensions API (if you wrote an interesting extension please let me know).

I talked a bit about MDbg in a previous post.

Monad Beta 2 that works with the RTM release of the .NET Framework 2.0 is released.
For those of you who are outside of the loop (naa… can’t be), Monad is the code name for Microsoft Shell (dubbed by a few as MSH) which is the the first attempt in many years (since cmd for NT came) to give the power of a strong shell to Windows developers/admins.

Get it here while its hot.

What a good way to instrument whatever it is that needs to be instrumented using the full power of the .NET Framework.
I’m sure you (and probably me) will be able to find some use for in debugging scenarios (wink, wink).

In my previous post about GC.AddMemoryPressure Tomer Gabel commented that people should not use this feature since its not the correct thing to do.

In addition to that Yuval Ararat wrote a post about this issue as well.

First of all, if I wasn’t clear enough in my first post, they are technically write BUT (and there is a big but here) there are situations, mainly in interoperability issues that might require us to better notify the GC that behind this small and insignificant .NET object lies a whole lot of unmanaged memory that is allocated and will only be released when this .NET object dies.

Calling GC.AddMemoryPressure will simply make the GC consider this object for who it really is, a memory hungry object that hides behind it a lot of unmanaged allocated memory.

Originally I just wanted to introduce this feature to people and make sure they know about it even though its quite esoteric and will mostly be used by applications with specific needs (and believe me, I know at least one application that could have benefited from this feature if it was available in .NET 1.1).

And Tomer, regarding the typos and stuff, I usually try to spell check and proof my posts, but some times they slip by 😉

Maoni has a great post about the changes and improvments of the GC in CLR 2.0.
Read all about it. Its good stuff and its Important.

In addition to that, there is a link to the slides she used in her PDC lecture.

I’m hoping to write a few more tidbits about the new and improved GC in a future post, so stay tuned.

Enjoy!

Hi everyone!

I didn’t post lately because I was on a personal vacation for two weeks.

I had a few interesting stuff I was working on before I left for the vacation so be sure to check the blog in a couple of days for some cool stuff.