softlogger Latest Articles ::CSharp

Binary vs. Source compatibility

Mike Stalls blog — 2008-03-11T00:00:00

Binary Compatibility means that when something is updated, you continue to work without needing to even recompile.

Source Compatibility means that you need to recompile to keep things working, but you don't have to actually change the sources.

One is not a superset of the other. Here are some examples in each combo.

Compatibility generally doesn't just mean that the change is discoverable, but that the change has some significant breaking implication that would cause a reasonably client to need to adjust their behavior. (Of course, you always find afterwards that's some important client did something unexpected and you need to compensate. Hence the heroics of the AppCompat folks). For example, with C# + reflection, any change is discoverable, so any change could technically break a client; but if a client breaks because they're relying on the names of private methods that you changed, they're hard-pressed to complain.

Yes Binary + Yes Source:

Renaming private methods. Changing a method body in a way that continues to behave the same.

Yes Binary, Not Source:

Adding new method overloads. Since overload resolution is determined at compile time, adding new methods won't affect already-compiled binaries. But if you recompile, it's possible that you may bind to the new overloads. (For example, see float.Equals)

Not Binary, Yes Source:

In this case, you just need to recompile your sources to keep working. The compiler will respond to the change in a corrective way. For example, consider removing a method overload. At a binary level, the method you're bound to is removed and so things fail. But if you recompile, the compiler may bind to another overload that's semantically equivalent, and so things keep working without you having to change any source.

Not Binary, Not Source:

A real breaking change. This requires clients to update their sources and recompile. For example, removing a method.

Carousel(flying) Movement for Images using .NET DataGrid

Dutts DOTNET Support — 2008-02-12T00:00:00

Coalesce ?? operator in C# 2.0

Dmytro Shteflyuks Home — 2008-01-14T00:00:00

Operator ??, that was introduced in the .NET 2.0, takes first place in my top used C# idioms list a long time, but unfortunately it is rarely used in projects I’ve participated. Therefore these snippets could be found in production code very often:

public string Caption

{

    get { return ViewState["Caption"] != null ? (string) ViewState["Caption"] : ""; }

    set { ViewState["Caption"] = value; }

}

Or even:

public string VisibleStatistic

{

    get

    {

        string retval = (string) ViewState["VisibleStatistic"];

        return retval == null ? "" : retval;

    }

    set

    {

        ViewState["VisibleStatistic"] = value;

    }

}

public string SelectedCategoryName

{

    get

    {

        object retval = ViewState["SelectedCategoryName"];

        if (retval != null)

            return (string) retval;

        return String.Empty;

    }

    set

    {

        ViewState["SelectedCategoryName"] = value;

    }

}

Almost 50% of this could be easily removed, and you will get beautiful and clear code, just right after you will understand what the hell is operator ??. Here is information from MSDN:

The ?? operator returns the left-hand operand if it is not null, or else it returns the right operand.

Easy and clean explanation. Let’s try to rewrite all these examples using this operator:

public string Caption

{

    get { return (string) ViewState["Caption"] ?? String.Empty; }

    set { ViewState["Caption"] = value; }

}

public string VisibleStatistic

{

    get { return (string) ViewState["VisibleStatistic"] ?? String.Empty; }

    set { ViewState["VisibleStatistic"] = value; }

}

public string SelectedCategoryName

{

    get { return (string) ViewState["SelectedCategoryName"] ?? String.Empty; }

    set { ViewState["SelectedCategoryName"] = value; }

}

In case of value-types this approach will not work: you will get NullReferenceException. But do not worry — in this case we can use Nullable-types. Before:

public int FirstWidth

{

    get { return ViewState["FirstWidth"] != null ? (int) ViewState["FirstWidth"] : 0; }

    set { ViewState["FirstWidth"] = value; }

}

After:

public int FirstWidth

{

    get { return (int?) ViewState["FirstWidth"] ?? 0; }

    set { ViewState["FirstWidth"] = value; }

}

When you are using ?? operator, expression will be evaluated in the left to right order, so you can use something like this:

string name = FirstName ?? LastName ?? "Anonymous";

Of course, it looks more readably than the:

string name;

if (FirstName != null)

    name = FirstName;

else if (LastName != null)

    name = LastName;

else

    name = "Anonymous";

And a fortiori than:

string name = FirstName != null

        ? FirstName

        : (LastName != null ? LastName : "Anonymous");

Add it to your armoury!

.net, c#, syntax, tricks

Using Reflector to search through code and resolve .NET issues

If broken it is, fix it you should — 2008-01-10T00:00:00

As you already know, i spend my days analyzing dumps for customers, and more often than not I don't have access to the customers code.

I could probably ask for it but it usually takes a long time and even then I often just get partial code, and sometimes, if the customer has multiple environments or if there has been recent changes, the code I would get may not correspond exactly to what was running in production when the dump was taken.

I'm sure many of you are familiar with Lutz Roeder's Reflector already... I just have to say, I just love this tool... it has made my life soo much easier over the years that it's not even funny. I constantly have 2-3 sessions open and in case you are not familiar with some of its features I wanted to show how I use it on a daily bases...

Before I do though, here is a presentation about all the 5.0 features

Saving the modules

If I have a dump of a process and want to look at the code running inside it I can open it up in windbg and use sos to save the dlls using

!savemodule <base address> <path to save>

And I can get the base address by running lmv mmodulename, or just lm to get all start/base addresses for all modules... anyways, it gets pretty tedious to do that for all modules so instead I automate it a bit with windbgs !for_each_module, so the command below, saves out all the dlls/exes loaded in the process in binary form so they will be stored on disk pretty much as an exact replica of the dll loaded in the process...

0:000> !for_each_module !savemodule ${@#Base} f:\blog\modules\${@#ModuleName}.dll
01000000
5 sections in file at 00990000
section 0 - VA=1000, VASize=7f749, FileAddr=400, FileSize=7f800
section 1 - VA=81000, VASize=490, FileAddr=7fc00, FileSize=600
section 2 - VA=82000, VASize=237c, FileAddr=80200, FileSize=2000
section 3 - VA=85000, VASize=3d8, FileAddr=82200, FileSize=400
section 4 - VA=86000, VASize=5404, FileAddr=82600, FileSize=5600
Successfully saved file: f:\blog\modules\oleaut32.dll
01000000
4 sections in file at 00a20000
section 0 - VA=1000, VASize=498f4, FileAddr=400, FileSize=49a00
section 1 - VA=4b000, VASize=1054, FileAddr=49e00, FileSize=c00
section 2 - VA=4d000, VASize=1598, FileAddr=4aa00, FileSize=1600
section 3 - VA=4f000, VASize=26ec, FileAddr=4c000, FileSize=2800
Successfully saved file: f:\blog\modules\shlwapi.dll
00040000
3 sections in file at 00f60000
section 0 - VA=2000, VASize=2954, FileAddr=200, FileSize=2a00
section 1 - VA=6000, VASize=2a8, FileAddr=2c00, FileSize=400
section 2 - VA=8000, VASize=c, FileAddr=3000, FileSize=200
Successfully saved file: f:\blog\modules\y9w_t4cv.dll
00040000
3 sections in file at 00f70000
section 0 - VA=2000, VASize=2954, FileAddr=200, FileSize=2a00
section 1 - VA=6000, VASize=2a8, FileAddr=2c00, FileSize=400
section 2 - VA=8000, VASize=c, FileAddr=3000, FileSize=200
Successfully saved file: f:\blog\modules\ibyunanw.dll
00040000
3 sections in file at 00f80000
section 0 - VA=2000, VASize=2954, FileAddr=200, FileSize=2a00
section 1 - VA=6000, VASize=2a8, FileAddr=2c00, FileSize=400
section 2 - VA=8000, VASize=c, FileAddr=3000, FileSize=200
Successfully saved file: f:\blog\modules\th5r9oei.dll
00040000
3 sections in file at 00f90000
section 0 - VA=2000, VASize=2954, FileAddr=200, FileSize=2a00
section 1 - VA=6000, VASize=2a8, FileAddr=2c00, FileSize=400
section 2 - VA=8000, VASize=c, FileAddr=3000, FileSize=200
Successfully saved file: f:\blog\modules\t0i_pxyo.dll
...

Opening in reflector

In order to get all the code running in the process i just open a new instance of reflector, clean out any previously opened dlls and do file/open, selecting all the modules i just saved.

Sometimes you need to close out dlls like System.dll System.Xml.dll etc. that have native images and open those directly from the framework directory instead.

Searching in reflector

Let's say I want to debug the issue described in this post, where we are leaking dynamic assemblies because we are creating new XmlSerializers, and we want to know where in our code we might be creating these...

I would use the search function, searching for types to find XmlSerializer

And then just double click on the XmlSerializer option to explore that class...

Btw, it has great member search and string/constant search options as well if you need that...

Finding out who calls it

Once we have found the XmlSerializer class we can take one of the methods we are interested in (in this case any of the XmlSerializer constructors that generate dynamic assemblies without caching them) and right-click and choose Analyze...

This opens the Analyzer pane where we can expand the Used By node to find out who is calling this method...

And in this case it tells us that the only method that is using this constructor, in the code loaded in the process, is Lab3_2.Page_Load. And if we right click and choose Go To Member we can even see the code for this in the Disassembler pane so we can see how it calls it.

And that way we can pinpoint the exact line of code that caused this assembly leak...

Laters

Tess

Logging for Libraries

Waste of Time — 2008-01-05T00:00:00

A pet peeve of mine for a long time has been how many libraries handle logging. There are general two techniques:

Don't log
Use [commons-logging|log4r|printf|syslog|slf4j]

Both suck.

In the first case you cannot get info out. In the second case the library is deciding how you will get the info out. The first one is okay for anything that can never go wrong. I'm sure you can think of something in that category. For everything else, you frequently need to see what is going wrong -- or at least figure out why what you are giving it is garbage.

For a library, then, logging is a feature. This is where most folks whip out commons-logging, log4perl, or whatever. Bzzzz. You just added a dependency and dictated that users figure out how to make use of that logging system. The much better way is to expose logging via callbacks and provide concrete instances of the common cases.

An example might look like:

foo.setLogger(new FooLogger() {
    public void log(int level, String msg) {
        System.err.printf("%s\n",msg);
    }
})

Which is boring, but you know, covers 98% of the cases where you want logging in a library. To cover the common cases:

foo.setLogger(new PrintStreamLogger(System.err));
    ...
foo.setLogger(new Log4jLogger(Wombat.class));

This is the runtime-configured-slf4j-per-project approach. It seems kinda gnarly until you use the library and things just magically work they way you want. Any dependency on external logging is specifically selected by users, or they can do their own thing.

Quirk in the DateTime class

.NET slave — 2008-01-05T00:00:00

I experienced a strange behaviour with the DateTime class and formatting today. For some reason this error only occurs when you format a DateTime in certain cultures like Italian. The error is not present in English, Danish and most other cultures.

It happens when you use the DateTime.ToString and DateTime.ParseExact methods. When you write the following:

String date = DateTime.Now.ToString("yyyy-MM-dd HH:mm")

You would expect the date variable to be formatted like so 2008-01-05 11:30. In Italian it doesn’t. Instead it replaces the colon with a period which produces this 2008-01-05 11.30. This might be correctly formatted for the Italian culture, but I explicitly wrote I wanted the colon delimiter in the format string. However, there is a workaround.

All you need is to change the format string into a less obvious one. The following produces the right colon delimited date and time string:

String date = DateTime.Now.ToString("yyyy-MM-dd HH\\:mm")

Strangely enough, you have to escape the colon with two backslashes for it to work. This trick seems to work in all cultures.

Use SC CONFIG to isolate a Service in its own svchost instance.

Gregs Cool [Insert Clever Name] of the Day — 2008-01-05T00:00:00

Digging in - How to isolate a service in its own scvhost.exe

"This is a very good public link to read about service control manager internals and how to manage services.
http://download.microsoft.com/download/f/3/9/f3900e1e-a45c-45a4-b716-740e553e1f62/SPTCF_SYS.doc
Description of svchost.exe http://support.microsoft.com/kb/314056
...
for troubleshooting purposes if we want to isolate any one service running under svchost---we can do that using sc config BITS type= own

now as you see BITS is running under its own scvhost process.
..."

This is like a two for one deal...

First there's a link to the cool Managing System Services document (87 page chapter 13 from what I think is the Windows Server 2003 Resource Kit)

And then there's the tip on how to isolate a Service in a svchost.exe instance. (Say because a SVChost.exe instance is chewing up processor cycles, but that instance is hosting a number of services so it's hard to tell which one is being bad. So you want to isolate each service to its own svchost instance to hunt the evil one...)

DataGridviewAutoFilter Sample Updated (Think "Click on a Grid Column Header and select value to filter rows on" sample)

Gregs Cool [Insert Clever Name] of the Day — 2007-12-10T00:00:00

Windows Forms Documentation Updates - DataGridviewAutoFilter sample updated

"I've made a few bug-fixes to my DataGridViewAutoFilter sample, which is described in Building a Drop-Down Filter List for a DataGridView Column Header Cell. It might be a week or two until the article is updated (as of December 5, 2007), but the new sample download has already been posted. The download contains C# and VB projects, plus the updated article in Word 2003 format.

Here's a summary of the fixes:
..."

MSDN - Building a Drop-Down Filter List for a DataGridView Column Header Cell

"Summary: The Microsoft Windows Forms DataGridView control in Microsoft Visual Studio 2005 provides a grid experience similar to Microsoft Excel, but does not provide the column filtering drop-down lists that Excel provides in its AutoFilter feature. However, the DataGridView can bind to data sources that provide filtering, such as the ADO.NET DataView. This article describes how to build a custom DataGridView column header cell that displays drop-down filter lists, by taking advantage of the filtering capabilities of the data source and the new BindingSource component. (25 printed pages)
...

..."

This is a feature found in many third party grids, which you can have for free...

Code snippet for property old style

The Moth — 2007-12-04T00:00:00

When I first realised that the prop snippet now generates automatic properties in C# I thought it was cool. The more I write code in VS2008 though I find that when I need to write a property with get/setters that are explicitly implemented, it becomes tedious – I used to rely on prop in VS2005 too much I guess. This is easily rectified by adding a new code snippet of course.

Creating snippet is so easy it should be illegal :), but to save you the manual work here is the one I created for this purpose (propOld). Simply "save as" to your local drive and then from Visual Studio 2008 menu "Tools->Code Snippet Manager" click the "Import" button; then in a C# file type proOLD and hit TAB (instead of prop+TAB).

Display Checkboxes in ASP.NET 2.0 GridView using skins

peterkellner.net — 2007-11-24T00:00:00

So, I’ve been struggling for a while with how to style a checkbox to work with a skin file. Basically, what I did was create some gif files that look like checked and unchecked check boxes. I defined them in my SkinFile.skin file as follows:

<asp:ImageButton SkinID=”iconCheckedDisabled” ImageUrl=”Images/iconCheckedDisabled.gif” runat=”server” ToolTip=”Checked Disabled” />

<asp:ImageButton SkinID=”iconCheckedEnabled” ImageUrl=”Images/iconCheckedEnabled.gif” runat=”server” ToolTip=”Checked Enabled” />

<asp:ImageButton SkinID=”iconUnCheckedDisabled” ImageUrl=”Images/iconUnCheckedDisabled.gif” runat=”server” ToolTip=”Unchecked Disabled” />

<asp:ImageButton SkinID=”iconUnCheckedEnabled” ImageUrl=”Images/iconUnCheckedEnabled.gif” runat=”server” ToolTip=”Unchecked Enabled” />

The image files look like the following:

The problem basically is that you can’t dynamically swap skin files easily because they must be set at the preinit phase of event processing. Not at databound events which is where I’d want to do it.

So, my revelation was that I could just list all the states in a gridview template, then use the visibility attribute to make them show the correct one. That way, the skins are all loaded all the time, just now showing all the time. The GridView Code looks like the following:

<asp:GridView ID=”GridViewAssigned” runat=”server” AllowPaging=”True”
AllowSorting=”True” Caption=”Assigned” AutoGenerateColumns=”false”
DataSourceID=”ObjectDataSourceGroupsAssigned”
>
<Columns>
<asp:TemplateField ShowHeader=”False” >
<ItemTemplate>
<asp:ImageButton ID=”LinkButtonUnassign” SkinID=”ImageButtonRemove” runat=”server” BackColor=”white” CausesValidation=”False”
CommandArgument=’<%# Eval(”id”) %>‘ CommandName=”Select” ForeColor=”black” />
ItemTemplate>
asp:TemplateField>
<asp:TemplateField ShowHeader=”True” HeaderText=”Assign To New Content By Default” >
<ItemTemplate>

<asp:ImageButton ID=”LinkButtonToggleDefaultChecked” SkinID=’iconCheckedEnabled’ runat=”server” BackColor=”white” CausesValidation=”False”
visible=’<%# (bool) Eval(”Defaultnewcontent”) %>‘
CommandArgument=’<%# Eval(”id”) + “;” + Eval(”Approved”) %>‘ CommandName=”ToggleDefault” ForeColor=”black” />

<asp:ImageButton ID=”LinkButtonToggleDefaultUnChecked” SkinID=”iconUnCheckedEnabled” runat=”server” BackColor=”white” CausesValidation=”False”
visible=’<%# !(bool) Eval(”Approved”) %>‘
CommandArgument=’<%# Eval(”id”) + “;” + Eval(”Approved”) %>‘ CommandName=”ToggleDefault” ForeColor=”black” />
ItemTemplate>
asp:TemplateField>
<asp:BoundField DataField=”Name” HeaderText=”Name” SortExpression=”Name” />
Columns>
asp:GridView>

Then, when you finally run it, the gridview looks something like this.

Notice no codebehind was necessary for this trick! Good luck and hope this save you some time.

C# 3.0 Object Initializers Revisited

B# .NET Blog — 2007-11-22T00:00:00

A while ago I posted about this new C# 3.0 feature. Although the IL code (aargh, yet another of these posts :-)) in that post reveals how object initializers are implemented internally, I wanted to make it slightly more explicit over here to avoid confusion.

Consider the following C# 3.0 fragment:

using System;

class Oini
{
   public static void Main()
   {
      Customer c = new Customer() { Name = "Bart", City = "Redmond", Age = 24 };
   }
}

This is not equivalent to:

using System;

class Oini
{
   public static void Main()
   {
      Customer c = new Customer();
      c.Name = "Bart";
      c.City = "Redmond";
      c.Age = 24;
   }
}

It is equivalent to the following however:

using System;

class Oini
{
   public static void Main()
   {
      Customer __t = new Customer();
      __t.Name = "Bart";
      __t.City = "Redmond";
      __t.Age = 24;
      Customer c = __t;
   }
}

I know it's subtle but there's a very good reason to do it this way: atomic assignment. Assignments should be read from right to left:

Customer c = new Customer() { Name = "Bart", City = "Redmond", Age = 24 };

means

evaluate the right-hand side (rhs):

new Customer() { Name = "Bart", City = "Redmond", Age = 24 }
assign it to the left-hand side (lhs):

Customer c

therefore, we need a temporary object to evaluate the right-hand side first prior to assigning it to the target variable.

One place where this subtlety is quite important is the use of multi-threading. It's a bit of a convoluted sample, I agree, since in multi-threaded circumstances you'll likely have a locking-strategy or so in place to avoid base states but anyhow, here's a sample:

using System;
using System.Threading;

class Customer
{
   public string Name { get; set; }
   public string City { get; set; }
   public int Age { get; set; }
}

class Demo
{
   static Customer c;
   static int n = 0;
   static bool safe = false;

   static void Main(string[] args)
   {
      safe = args.Length > 0;

      Init();

      AppDomain.CurrentDomain.UnhandledException +=
         delegate(object sender, UnhandledExceptionEventArgs e)
         {
            Console.WriteLine("Invalid state after " + n + " assignments.");
            Environment.Exit(1);
         };

      new Thread(() => Monitor()).Start();

      for (n = 1; ; n++)
         Init();
   }

   static void Init()
   {
      if (safe)
      {
         c = new Customer() {
            Name = "Bart",
            City = "Redmond",
            Age = 24
         };
      }
      else
      {
         c = new Customer();
         c.Name = "Bart";
         c.City = "Redmond";
         c.Age = 24;
      }
   }

   static void Monitor()
   {
      while (true)
      {
         if (c.Name != "Bart" || c.City != "Redmond" || c.Age != 24)
            throw new Exception("Bad state detected");
      }
   }
}

If you execute this application without command-line arguments it should fail pretty quickly. However if you run it with some parameter, safe will be set to true, which causes Init to use the C# 3.0 implementation of object initialization, which is atomic. So we shouldn't get in intermediate states at all.

Here's the reverse translation of the Init body using Reflector:

If you understand this sample, you know why atomic assignment matters (and that's a good thing :-)). To pinpoint the core problem, consider the following fragment of Init (in the safe-negative case):

         c = new Customer();
         c.Name = "Bart";
         c.City = "Redmond";
         c.Age = 24;

If the monitoring thread gets a chance to kick in somewhere in the middle of executing these four statements, the state is "corrupted". Obviously you can fix this by putting a lock in place (small exercise) but it's nice to know the atomic character of object initializers in C# 3.0 anyhow.

Enjoy!

Managed and Native Interop - C# or C++/CLI?

Jason Olson — 2007-11-22T00:00:00

This is a topic that I've been thinking a lot about lately. And I would really like to get all of your opinions as well (especially if you disagree with me).

This debate came up recently (again) on my trip to Tech Ed Developer in Barcelona. If I am having to write interop code, should I use C# and p/invoke, or should I use C++/CLI? I had some very smart people like Kate Gregory and Daniel Moth to chat with this about. Kate and Daniel are definitely good people to chat with because, honestly, they have completely different opinions on this topic. Kate is on the C++/CLI side of things, especially for serious interop tasks, while Daniel believes that you should keep it in C# no matter how complicated that C# gets. So, what side of the fence do I fall on?

This is a question I've been pondering for a while now. Since I first came in to this Windows Server 2008 Technical Evangelist, I've had to write a lot of interop code. And I personally believe in using the right tool for the job. And while p/invoke is great for smaller interop jobs between native code and managed code, it can "get out of hand" quickly. For instance, to p/invoke into the new Transactional NTFS APIs, I could look at having to create a bunch (several hundred lines of code or many more) of interop structures merely to call DeviceIoControl to get issue a single TxF command. Here's the thing: all those structures are all ready defined on the native side and could be used with ease (as in, a simple "#include" statement) on the C++/CLI side of things. No extra code necessary.

But it's not just the structure definitions that are the problem, it is also the programming paradigm used in the native code you are trying to interop with. When dealing with a simple Windows API function, this may not be a problem at all. Of course, it gets a little scary when dealing with COM interop, but at least there are still the tools built into C# to interop with COM. Where the train really starts to derail is when you start writing interop code for a native library that uses a different paradigm.

For instance, let's look at DeviceIoControl. It's not really one function call, it's a complete API in itself. I've had to get familiar with DeviceIoControl when doing my work with Transactional NTFS. DeviceIoControl uses a much more conversational paradigm than managed developers are perhaps used to. Here's a common "calling session" with DeviceIoControl (minus all the fun exception handling that should be there):

while (true)
{
    // Clean-up previously allocated memory

    // Allocate memory

    // Issue command
    if (!DeviceIoControl(...))
    {
        if (GetLastError() == ERROR_MORE_DATA)
        {
            // Determine how much more memory we need

            continue;
        }
    }
    else
    {
        // There was enough memory finally

        // Pull data out of buffer we issued to DeviceIoControl

        break;
    }
}

When writing managed code against this DeviceIoControl paradigm, you will write more code that is harder to maintain and debug than you will if you simply used C++/CLI to do the interop. With C++/CLI you can use the API natively exactly like it's meant to be used, and then "expose" the code to the managed world via C++/CLI. When I moved my Transaction NTFS wrapper from C# to C++/CLI, I was able to remove a large chunk of code, and it was much easier to read and understand. Using the right tool for the job will do that for you.

The DeviceIoControl paradigm is just one example though. Another "hang up" when writing interop code in C# is when you need to do some very detailed memory and pointer manipulation. Take this following piece of code that is used within the DeviceIoControl pattern above and is used to get the list of running transactions on a system (assuming the "list" has already been populated):

// Loop through the transaction entries and store them in a list
TXFS_LIST_TRANSACTIONS_ENTRY *txEntry;
txEntry = (TXFS_LIST_TRANSACTIONS_ENTRY *)((char *)txList + sizeof(TXFS_LIST_TRANSACTIONS));
for (DWORD i = 0; i < txList->NumberOfTransactions; i++)
{
    TRANSACTION_ENTRY *newEntry = AddTxFEntry(txEntry->TransactionId, txEntry->TransactionState);

    // Each transaction is attempted to be loaded with their files ASAP (if any).
    LoadLockedFiles(rmDirectory, newEntry);
    txEntry++;
}

This code is a PITA to write in C#. Not only do you have to write all the interop structures for TXFS_LIST_TRANSACTIONS_ENTRY, TXFS_LIST_TRANSACTIONS, and TRANSACTION_ENTRY, but you have to do all the pointer fun via the Marshal helper in C#. Sure, you could pop into unsafe code and deal with pointers directly, but I think if you are willing to do that, you should be more than willing to just use C++/CLI. Why would I go through all that, if I can just write the code and expose the results to managed code via C++/CLI? As soon as I switched the wrapper from C# to C++/CLI, my job got a LOT easier. And this is coming from a programmer that is relatively new to the whole C++ world. If I can write in C++/CLI for interop, I honestly believe any committed C# developer can as well.

Let's look at a small snippet from the Transactional NTFS Wrapper:

FileStream^ TransactedFile::Open(System::String ^path, FileMode mode, FileAccess access, FileShare share) {
                
    ...

    ////////////////////////////////////////////////////////////////////////
    // We need to marshal our values into native types since we are
    // going to call into a native Windows API based on CLR parameters
    marshal_context ctx;
    const wchar_t *marshalledPath = ctx.marshal_as<const wchar_t *>(path);

    HANDLE fileHandle = CreateFileTransacted(marshalledPath, 
        marshal_as<DWORD>(access), 
        marshal_as<DWORD>(share),
        NULL, 
        marshal_as<DWORD>(mode), 
        FILE_ATTRIBUTE_NORMAL, 
        NULL, 
        kernelTransactionHandle, 
        NULL, 
        NULL);
    
    ...
}

This is the actual segment of code that does the main interop piece for me. Is the above that intimidating? A couple of things to note to those C# developers out there. You can think of the "^" as denoting "by reference". Yes, it's a bit more complicated than that, but just think of it that way for now, that's all you need to know. And the "::" operator is your namespace operator. So instead of "System.String", I have "System::String". Once again, a very simple syntactic difference.

The marshal_context object is a new object introduced with Visual C++ 2008 as part of the new marshalling library. By using the marshal_context, the context will take care of memory allocation and de-allocation for the strings we are are interop'ing. Very simple. The CreateFileTransacted API expects the path to be a "const wchar_t *", so I simply marshal our passed System::String as "const wchar_t *" and we're good to go. Since marshal_as<> is template based, it's very easy to extend yourself. And that's what I've done with marshalling System::IO::FileMode/Access/Share as DWORD (which I will show in a future post).

Now, honestly, is that piece of code that scary? If you have questions about it or things that still scare you, please let me know and I will look at writing a future post on the topic.

Back to the debate at hand though: C# versus C++/CLI for interop. I can certainly understand where Daniel is coming from. C# developers can quickly become intimidated when seeing C++/CLI code. It isn't the C# code they know and love. But I'm not sure he gives C# developers enough credit. It's an important step for developers to realize that, syntactically, C++/CLI and C# are not that different. If you are familiar with reference types in C#, you are probably more familiar with pointers than you realize. There are some "gotchas" around topics like pinned pointers, but they are concepts you need to know in C# as well if writing interop code there, so they aren't that big of a deal in the end. I'm not saying to not use P/Invoke and C# though. I'm simply saying to use the right tool for the job. If it is a very simple Windows API you are writing interop code for, C# and P/Invoke is probably "good enough". For more complicated interop jobs though (as in with most of the new enhancements in Vista and Windows Server 2008), why not use C++/CLI since it will make your life easier one you get over the small learning curve?

Did I have this same opinion before Visual Studio 2008? Yes, and no. Yes, C++/CLI code was still built for interop, but I honestly believe that the introduction of the extensible marshal_as<> construct (combined with other technologies like STL CLR) make interop in C++/CLI even more powerful and easier to use than before. For instance, marshalling strings was not fun to do before Visual Studio 2008 (especially for a developer not extremely aware of the different ways to use strings in native code). However, out of the box, the marshal_as<> construct provides a lot of different ways to work with and to interop with strings. And in all of these ways, you don't have to worry about allocating or de-allocating memory at all (ah, the same joys I get when working in a garbage collected world). And in the case that you are interacting with C++ libraries that are possibly STL-based, STL CLR provides you with a library that you simply don't get in C# (interop'ing with C-based Windows APIs are one thing, interop'ing with proper C++ libraries are a completely different beast when using C# for the interop code).

If you are a C# developer that writes _any_ interop code, you owe it to yourself to learn C++/CLI. Trust me, it will make your life much easier, and it's not that hard to learn. And being scared of pointers is no excuse. If you are comfortable with reference types in C#, you are probably more familiar with the concept of pointers than you realize. Plus, with STL and Boost (even more so with the upcoming TR1 work), there really is no need to have a pointer anywhere in your modern C++ program (ah, the sweetness that is the shared_ptr).

So with the launch of Visual Studio 2008, I believe that the "right tool" for the "interop job" is C++/CLI for anything that is beyond trivial. Constructs and libraries like marshal_as<> and STL CLR only drive this point home more. You can feel free to continue to write thousands of lines of managed-code-copying-already-defined-in-header-files simply to p/invoke into an existing Windows API, but me? I will be using Visual C++ 2008 and enjoying every minute of it since I don't have to do any re-invention of the wheel.

Query syntax in VB

Don Boxs Spoutlet — 2007-11-11T00:00:00

One other feature I'm liking in VB is that you can omit the trailing select clause in a query.

That is, you can simply say this:

From ch In "Hello" Where ch <> "H"

which in C# would look like this:

from ch in "Hello" where ch != 'H' select ch

Creating dumps with Windbg and writing ADPlus Config files

If broken it is, fix it you should — 2007-10-09T00:00:00

My colleague Carlo just wrote a post on how to create dumps and how to configure ADPlus with config files, that I thought was really useful

http://blogs.msdn.com/carloc/archive/2007/10/08/ok-now-how-do-i-capture-my-dump.aspx

He also talks a little about DebugDiag, a tool for creating dumps and doing automated dump analysis for certain cases. Btw, the dumps you generate with debug diag can be read in windbd and vice versa since the dump format is exactly the same.

Tess

Determining your Terminal Server Session ID from C#

Scrappydog — 2007-09-05T00:00:00

I ran into an interesting .NET Remoting problem yesterday: Users on Terminal Services were stomping on each other running an app with a "private" remoting server that hadn't taken into account the possibility that multiple user could be trying to run it simultaneously on the same computer.

So the next question became: How do we uniquely identify separate instances on the same server? The quick answer was username, but that would fail if a user had multiple terminal server sessions. The better answer was to use the terminal server session id. Here's a code sample to determine your session id:

        [DllImport("kernel32.dll")]
        static extern bool ProcessIdToSessionId(uint dwProcessId, out uint pSessionId);
 
        static void Main(string[] args)
        {
            Process _currentProcess = Process.GetCurrentProcess();
            uint _processID = (uint)_currentProcess.Id;
            uint _sessionID;
 
            bool _result = ProcessIdToSessionId(_processID, out _sessionID);
 
            Console.WriteLine("ProcessIdToSessionId Result: " + _result.ToString());
            Console.WriteLine("Process ID = " + _processID.ToString());
            Console.WriteLine("Session ID = " + _sessionID.ToString());
 
 
            Console.ReadLine();
        }

Notes:

On a standalone workstation the session id is zero (0).
The console session on a server is also zero (0).