This question is for interest sake. I'm working with a third-party library and came across the following documentation on a CMS.Security.Dummy class:

DO NOT DELETE THIS CLASS - This class prevents the compiler from dropping entire namespace under .NET 4.0.

Does anybody know, or can anybody speculate why .NET 4 would drop the namespace if the dummy class were removed?

Because .NET 4 is explicitly named in the source code comment, I assume previous C# versions exhibit behaviour that do not require this dummy class. That's purely speculative though.

Screen shot

Decompiled Source Code

#region Assembly CMS.SettingsProvider.dll, v4.0.30319
// ...\solution\wwwroot\Bin\CMS.SettingsProvider.dll
#endregion

using System;

namespace CMS.Security
{
    // Summary:
    //     DO NOT DELETE THIS CLASS - This class prevents the compiler from dropping
    //     entire namespace under .NET 4.0.
    public class Dummy
    {
        // Summary:
        //     DO NOT DELETE THIS CLASS - This class prevents the compiler from dropping
        //     entire namespace under .NET 4.0.
        public Dummy();
    }
}

A little-appreciated fact is that there is no such thing as a "namespace" from the point of view of the underlying CLR type system. Rather, it's just a convention that we say that a type that contains periods in its name is "a member of a namespace". Logically there is no difference at all between the legal code:

namespace N
{
    class C  {}
}

and the psuedo-code:

class N.C {}

C# forces you to pretend this pleasant fiction is reality, but it is just a fiction -- from the perspective of the CLR type system, of course. From the perspective of the C# compiler, of course namespaces are "real". They just don't correspond to anything in metadata other than a portion of the name of a type.

In short: if you make an assembly with an "empty" namespace then the "namespace" doesn't exist at all in the compiled binary. A "namespace" only comes into existence when there is a type in the library that has periods in its name.

Now, why you would care about ensuring that an "empty" namespace has some presence in the binary form, I have no idea.

I assume previous C# versions exhibit behaviour that do not require this dummy class

Nope. Every version of C# since 1.0 throws away empty namespaces.

I was investigating String.Concat : (Reflector)

very strange :

the have the values array ,

they creating a NEW ARRAY for which later they send him to ConcatArray.

Question :

Why they created a new array ? they had values from the first place...

Well for one thing, it means that the contents of the new array can be trusted to be non-null.... and unchanging.

Without that copying, another thread could modify the original array during the call to ConcatArray, which presumably could throw an exception or even trigger a security bug. With the copying, the input array can be changed at any time - each element will be read exactly once, so there can be no inconsistency. (The result may be a mixture of old and new elements, but you won't end up with memory corruption.)

Suppose ConcatArray is trusted to do bulk copying out of the strings in the array it's passed, without checking for buffer overflow. Then if you change the input array at just the right time, you could end up writing outside the allocated memory. Badness. With this defensive copy, the system can be sure¹ that the total length really is the total length.

---

¹ Well, unless reflection is used to change the contents of a string. But that can't be done without fairly high permissions - whereas changing the contents of an array is easy.

When the user is selecting values from a combobox, if they choose a value, the "SelectionChanged" event fires and the new value is set and everything's fine. If, however, they decide not to change the value and click elsewhere on the UI (like a text box they want to edit), they have to click twice - the first click simply closes the combobox popup, and the next click will focus the element they wanted to activate on the first click.

How can I prevent the combobox popup from hijacking the focus target on the first click like that?

I've tried monitoring the ComboBox_LostFocus event, but this fires at the wrong time. When the user clicks the dropdown and the popup list is displayed, the ComboBox_LostFocus event fires - it's losing focus to it's own dropdown list. I don't want to do anything to change that. When the user then clicks away and the popup closes, the ComboBox never regains focus (focus is just 'lost' to everything) and so this event is useless.

I think I might have found a solution. Comboboxes do have a DropDownClosed event - the problem is it isn't a RoutedEvent, so you can't create a style for ComboBoxes and have them all inherit the event via an EventSetter. (You get the error 'DropDownClosed' must be a RoutedEvent registered with a name that ends with the keyword "Event")

However, the Loaded event is a RoutedEvent, so we can hook into that in the style:

<Style x:Key="ComboBoxCellStyle" TargetType="ComboBox">
    <EventSetter Event="Loaded" Handler="ComboBox_Loaded" />
</Style>

Now that we have an event that will always fire before anything else is done with the ComboBox, we can hook into the event we actually care about:

private void ComboBox_Loaded(object sender, RoutedEventArgs e)
{
    ((ComboBox)sender).DropDownClosed -= ComboBox_OnDropDownClosed;
    ((ComboBox)sender).DropDownClosed += new System.EventHandler(ComboBox_OnDropDownClosed);
}

Now that I finally have access to the event that fires when the DropDown is closing, I can perform whatever actions I need to make sure the focus is terminated on the bothersome ComboBox. In my case, the following:

void ComboBox_OnDropDownClosed(object sender, System.EventArgs e)
{
    FrameworkElement visualElement = (FrameworkElement)sender;

    while( visualElement != null && !(visualElement is DataCell) )
        visualElement = (FrameworkElement)visualElement.TemplatedParent;
    if( visualElement is DataCell )
    {
        DataCell dataCell = (DataCell)visualElement;
        dataCell.EndEdit();
        if( !(dataCell.ParentRow is InsertionRow) ) dataCell.ParentRow.EndEdit();
    }
}

I had a ComboBox as the template of a DataCell in a GridView, and this particular problem was preventing the DataRow from ending edit when the user popped open a ComboBox then clicked outside of the grid.

That was my biggest problem with this bug. A secondary problem setting the focus in this event iff the user clicked. The combobox might also have just been closed because the user hit tab or escape though, so we can't just setfocus to the mouse position. We'd need more information on what caused the DropDownClosed event to fire. Probably means hooking into more unrouted events in the _Loaded event handler.