Best .net questions in June 2012

Combining Predicates in F#

17 votes

Is there a standard way of logically combining predicates in F#? For example, let's say I have isCar x and isBlue x then I want something that gives me:

let isBlueCar x = isCar x && isBlue x

But using some sort of composition, rather than invocation, maybe like:

let isBlueCar x = isCar && isBlue

Preferably, that something would be able to accept a large/arbitrary number of predicates.

You could define a combinator.

let (<&>) f g = (fun x -> f x && g x)

then do

let isBlueCar = isCar <&> isBlue

How do I get the differences between two string arrays?

17 votes

How to compare two array string using C#.net? Eg:

string[] com1 = { "COM6", "COM7" };
string[] com2 = { "COM6", "COM7","COM8" };

Here com1 and com2 are Array string. Result: COM8. How to achieve this?

I think this the shortest way to solve this

foreach (string com in com2 )
{
    if (!com1.Contains(com))
    {
        MessageBox.Show(com);
    }
}

Operator ">" cannot be applied to type int

14 votes

I'm curious to know why the C# compiler only gives me an error message for the second if statement, when they are essentially the same thing.

enum Permissions : ulong
{
    ViewListItems = 1L,
}

public void Method()
{
    int mask = 138612833;
    int compare = 32;

    if (mask > 0 & (ulong)Permissions.ViewListItems > 32)
    {
        //Works
    }

    if (mask > 0 & (ulong)Permissions.ViewListItems > compare)
    {
        //Operator '>' cannot be applied to operands of type 'ulong' and 'int'
    }
}

(If anyone can think of a better more specific title, please edit the post.)

I've been experimenting with this, using ILSpy to examine the output, and this is what I've discovered.

Obviously in your second case this is an error - you can't compare a ulong and an int because there isn't a type you can coerce both to. A ulong might be too big for a long, and an int might be negative.

In your first case, however, the compiler is being clever. It realises that const 1 > const 32 is never true, and doesn't include your if statement in the compiled output at all. (It should give a warning for unreachable code.) It's the same if you define and use a const int rather than a literal, or even if you cast the literal explicitly (i.e. (int)32).

But then isn't the compiler successfully comparing a ulong with an int, which we just said was impossible?

Apparently not. So what is going on?

Try instead to do something along the following lines. (Taking input and writing output so the compiler doesn't compile anything away.)

const int thirtytwo = 32;
static void Main(string[] args)
{
    ulong x = ulong.Parse(Console.ReadLine());
    bool gt = x > thirtytwo;
    Console.WriteLine(gt);
}

This will compile, even though the ulong is a variable, and even though the result isn't known at compile time. Take a look at the output in ILSpy:

private static void Main(string[] args)
{
    ulong x = ulong.Parse(Console.ReadLine());
    bool gt = x > 32uL;        /* Oh look, a ulong. */
    Console.WriteLine(gt);
}

So, the compiler is in fact treating your const int as a ulong. If you make thirtytwo = -1, the code fails to compile, even though we then know that gt will always be true. The compiler itself can't compare a ulong to an int.

Also note that if you make x a long instead of a ulong, the compiler generates 32L rather than 32 as an integer, even though it doesn't have to. (You can compare an int and a long at runtime.)

This points to the compiler not treating 32 as a ulong in the first case because it has to, merely because it can match the type of x. It's saving the runtime from having to coerce the constant, and this is just a bonus when the coercion should by rights not be possible.

Is it OK for a factory method to return null?

14 votes

I'm wondering about best practice here. Is it good practice for a factory method to return null if it can't create anything? Here's an example:

ICommand command = CommandFactory.CreateCommand(args);
if (command != null)
    command.Execute();
else
    // do something else if there is no command

An alternative would be to return a NullCommand or something, I guess, but what is best practice?

I think it's potentially reasonable for a factory method to return null in some situations, but not if it's a method called CreateCommand. If it were GetCommand or FetchCommand, that might be okay... but a Create method should throw an exception on failure, I would suggest.

Whether you really want it to return null in this situation depends on the bigger picture, of course. (Is there a reasonable null object implementation you could return instead, for example?)

Where to validate method's arguments?

13 votes

I'm wondering, where - and how often - in the code validate method's arguments.

In the example class below (a .dll library), what do you think is the best way? Suppose I want to validate, that some object cannot be null (but it can be any other validation required for method to run properly). Is it better to check it only once in point 1., in public method avaible for user, and later "trust myself", that in other, private, methods it will not be null or, better be a little paranoid and check it every time it's going to be used (in points 2. 3. and 4.)

Checking it just before using the object (in points 2, 3, 4) protects me in the future, if I decide to change something in the class, using these private methods, and "forget" to pass valid object. Also I don't have to remember about validation if I add some new public method in the future. On the other hand - it's checking for the same condition over and over again. Or maybe you have some other suggestions?

public class MyClass()
{
    public MyClass()
    {
    }

    public void ProcessObject(SomeObject obj)
    {
        //1. if (obj == null) throw new ArgumentException("You must provide valid object.");

        DoSomething(obj);
        DoMore(obj);
        DoSomethingElse(obj);
    }

    private void DoSomething(SomeObject obj)
    {
        //2. if (obj == null) throw new ArgumenException("You must provide valid object.");
        //do something with obj...
    }

    private void DoMore(SomeObject obj)
    {
        //3. if (obj == null) throw new ArgumentException("You must provide valid object.");
        //do something with obj...
    }

    private void DoSomethingElse(SomeObject obj)
    {
        //4. if (obj == null) throw new ArgumentException("You must provide valid object.");
        //do something with obj..
    }
}  

If it's an API that you're exposing for other developers to consume, then on each of your methods you should indeed throw either ArgumentException or ArgumentNullException.

If it's internal classes or methods that other developers will not be interacting with directly, I would use Debug.Assert, so in debug mode you get additional debugging information, and in release mode it gets nopped away and you receive the performance benefit of not doing all these argument checks everywhere.

Why does C# allow an *implicit* conversion from Long to Float, when this could lose precision?

13 votes

A similar question Long in Float, why? here does not answer what I am searching for.

C# standard allows implicit conversion from long to float. But any long greater than 2^24 when represented as a float is bound to lose its 'value'. C# standard clearly states that long to float conversion may lose 'precision' but will never lose 'magnitude'.

My Questions are
  1. In reference to integral types what is meant by 'precision' and 'magnitude'. Isn't number n totally different from number n+1 unlike real numbers where 3.333333 and 3.333329 may be considered close enough for a calculation (i.e. depending on what precision programmer wants)
  2. Isn't allowing implicit conversion from long to float an invitation to subtle bugs as it can lead a long to 'silently' lose value (as a C# programmer I am accustomed to compiler doing an excellent job in guarding me against such issues)

So what could have been the rationale of C# language design team in allowing this conversion as implicit? What is it that I am missing here that justifies implicit conversion from long to float?

In general, floating point numbers don't represent many numbers exactly. By their nature they are inexact and subject to precision errors. It really doesn't add value to warn you about what is always the case with floating point.

Transparent window layer that is click-through and always stays on top

12 votes

This is some code that I picked up which I tried to implement. Its purpose is to create a form layer which is transparent, full screen, borderless, clickthrough, and always on top of other windows. It then lets you draw using directx over the top of it remaining otherwise transparent.

The parts that don't work are the click-through part, and the directx render. When I run it I basically have an invisible force field in front of all other windows and have to alt-tab around to visual studio to quickly press ALT F5 and end the debug (so at least the always on top and transparency works). I have been trying to figure out why those parts dont work, but my newbie c# skills fail me. hopefully someone can spot why and provide a modification.

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Text;
using System.Windows.Forms;
using System.Diagnostics;
using System.Runtime.InteropServices;
using System.Globalization;
using Microsoft.DirectX;
using Microsoft.DirectX.Direct3D;
using System.Threading;


namespace MinimapSpy
{
public partial class Form1 : Form
{

    private Margins marg;

    //this is used to specify the boundaries of the transparent area
    internal struct Margins
    {
        public int Left, Right, Top, Bottom;
    }

    [DllImport("user32.dll", SetLastError = true)]

    private static extern UInt32 GetWindowLong(IntPtr hWnd, int nIndex);

    [DllImport("user32.dll")]

    static extern int SetWindowLong(IntPtr hWnd, int nIndex, IntPtr dwNewLong);

    [DllImport("user32.dll")]

    static extern bool SetLayeredWindowAttributes(IntPtr hwnd, uint crKey, byte bAlpha, uint dwFlags);

    public const int GWL_EXSTYLE = -20;

    public const int WS_EX_LAYERED = 0x80000;

    public const int WS_EX_TRANSPARENT = 0x20;

    public const int LWA_ALPHA = 0x2;

    public const int LWA_COLORKEY = 0x1;

    [DllImport("dwmapi.dll")]
    static extern void DwmExtendFrameIntoClientArea(IntPtr hWnd, ref Margins pMargins);

    private Device device = null;



    public Form1()
    {

        //Make the window's border completely transparant
        SetWindowLong(this.Handle, GWL_EXSTYLE,
                (IntPtr)(GetWindowLong(this.Handle, GWL_EXSTYLE) ^ WS_EX_LAYERED ^ WS_EX_TRANSPARENT));

        //Set the Alpha on the Whole Window to 255 (solid)
        SetLayeredWindowAttributes(this.Handle, 0, 255, LWA_ALPHA);

        //Init DirectX
        //This initializes the DirectX device. It needs to be done once.
        //The alpha channel in the backbuffer is critical.
        PresentParameters presentParameters = new PresentParameters();
        presentParameters.Windowed = true;
        presentParameters.SwapEffect = SwapEffect.Discard;
        presentParameters.BackBufferFormat = Format.A8R8G8B8;

        this.device = new Device(0, DeviceType.Hardware, this.Handle,
        CreateFlags.HardwareVertexProcessing, presentParameters);


        Thread dx = new Thread(new ThreadStart(this.dxThread));
        dx.IsBackground = true;
        dx.Start();  
        InitializeComponent();

    }

   protected override void OnPaint(PaintEventArgs e)
   {
        //Create a margin (the whole form)
      marg.Left = 0;
     marg.Top = 0;
      marg.Right = this.Width;
      marg.Bottom = this.Height;

        //Expand the Aero Glass Effect Border to the WHOLE form.
        // since we have already had the border invisible we now
        // have a completely invisible window - apart from the DirectX
        // renders NOT in black.
     DwmExtendFrameIntoClientArea(this.Handle, ref marg);  

  }
    private void Form1_Load(object sender, EventArgs e)
    {

    }
    private void dxThread()
    {
        while (true)
        {
            //Place your update logic here
            device.Clear(ClearFlags.Target, Color.FromArgb(0, 0, 0, 0), 1.0f, 0);
            device.RenderState.ZBufferEnable = false;
            device.RenderState.Lighting = false;
            device.RenderState.CullMode = Cull.None;
            device.Transform.Projection = Matrix.OrthoOffCenterLH(0, this.Width, this.Height, 0, 0, 1);
            device.BeginScene();

            //Place your rendering logic here

            device.EndScene();
            //device.Present();
        }

        this.device.Dispose();
        Application.Exit();
    }  

}

}

Here's a refined full sample code for making a window topmost - click through - transparent (= alpha blended). The sample makes a rotating color wheel which is rendered with DirectX, or actually with XNA 4.0, because I believe Microsoft has discontinued developing the managed directx and favours XNA today.

using System;
using System.Windows.Forms;
using System.Runtime.InteropServices;
using Microsoft.Xna.Framework.Graphics;

namespace ClickThroughXNA
{
    public partial class Form1 : Form
    {
        // Directx graphics device
        GraphicsDevice dev = null;        
        BasicEffect effect = null;     

        // Wheel vertexes
        VertexPositionColor[] v = new VertexPositionColor[100];

        // Wheel rotation
        float rot = 0;

        public Form1()
        {
            InitializeComponent();

            StartPosition = FormStartPosition.CenterScreen;   
            Size = new System.Drawing.Size(500, 500);
            FormBorderStyle = System.Windows.Forms.FormBorderStyle.None;  // no borders

            TopMost = true;        // make the form allways on top                     
            Visible = true;        // Important! if this isn't set, then the form is not shown at all

            // Set the form click-through
            int initialStyle = GetWindowLong(this.Handle, -20);
            SetWindowLong(this.Handle, -20, initialStyle | 0x80000 | 0x20);

            // Create device presentation parameters
            PresentationParameters p = new PresentationParameters();
            p.IsFullScreen = false;
            p.DeviceWindowHandle = this.Handle;
            p.BackBufferFormat = SurfaceFormat.Vector4;
            p.PresentationInterval = PresentInterval.One;

            // Create XNA graphics device
            dev = new GraphicsDevice(GraphicsAdapter.DefaultAdapter, GraphicsProfile.Reach, p);

            // Init basic effect
            effect = new BasicEffect(dev);

            // Extend aero glass style on form init
            OnResize(null);
        }


        protected override void OnResize(EventArgs e)
        {
            int[] margins = new int[] { 0, 0, Width, Height };

            // Extend aero glass style to whole form
            DwmExtendFrameIntoClientArea(this.Handle, ref margins);  
        }


        protected override void OnPaintBackground(PaintEventArgs e)
        {
            // do nothing here to stop window normal background painting
        }


        protected override void OnPaint(PaintEventArgs e)
        {                
            // Clear device with fully transparent black
            dev.Clear(new Microsoft.Xna.Framework.Color(0, 0, 0, 0.0f));

            // Rotate wheel a bit
            rot+=0.1f;

            // Make the wheel vertexes and colors for vertexes
            for (int i = 0; i < v.Length; i++)
            {                    
                if (i % 3 == 1)
                    v[i].Position = new Microsoft.Xna.Framework.Vector3((float)Math.Sin((i + rot) * (Math.PI * 2f / (float)v.Length)), (float)Math.Cos((i + rot) * (Math.PI * 2f / (float)v.Length)), 0);
                else if (i % 3 == 2)
                    v[i].Position = new Microsoft.Xna.Framework.Vector3((float)Math.Sin((i + 2 + rot) * (Math.PI * 2f / (float)v.Length)), (float)Math.Cos((i + 2 + rot) * (Math.PI * 2f / (float)v.Length)), 0);

                v[i].Color = new Microsoft.Xna.Framework.Color(1 - (i / (float)v.Length), i / (float)v.Length, 0, i / (float)v.Length);
            }

            // Enable position colored vertex rendering
            effect.VertexColorEnabled = true;
            foreach (EffectPass pass in effect.CurrentTechnique.Passes) pass.Apply();

            // Draw the primitives (the wheel)
            dev.DrawUserPrimitives(PrimitiveType.TriangleList, v, 0, v.Length / 3, VertexPositionColor.VertexDeclaration);

            // Present the device contents into form
            dev.Present();

            // Redraw immediatily
            Invalidate();            
        }


        [DllImport("user32.dll", SetLastError = true)]
        static extern int GetWindowLong(IntPtr hWnd, int nIndex);

        [DllImport("user32.dll")]
        static extern int SetWindowLong(IntPtr hWnd, int nIndex, int dwNewLong);

        [DllImport("dwmapi.dll")]
        static extern void DwmExtendFrameIntoClientArea(IntPtr hWnd, ref int[] pMargins);

    }
}

Round-twice error in .NET's Double.ToString method

12 votes

Mathematically, consider for this question the rational number

8725724278030350 / 2**48

where ** in the denominator denotes exponentiation, i.e. the denominator is 2 to the 48th power. (The fraction is not in lowest terms, reducible by 2.) This number is exactly representable as a System.Double. Its decimal expansion is

31.0000000000000'49'73799150320701301097869873046875 (exact)

where the apostrophes do not represent missing digits but merely mark the boudaries where rounding to 15 resp. 17 digits is to be performed.

Note the following: If this number is rounded to 15 digits, the result will be 31 (followed by thirteen 0s) because the next digits (49...) begin with a 4 (meaning round down). But if the number is first rounded to 17 digits and then rounded to 15 digits, the result could be 31.0000000000001. This is because the first rounding rounds up by increasing the 49... digits to 50 (terminates) (next digits were 73...), and the second rounding might then round up again (when the midpoint-rounding rule says "round away from zero").

(There are many more numbers with the above characteristics, of course.)

Now, it turns out that .NET's standard string representation of this number is "31.0000000000001". The question: Isn't this a bug? By standard string representation we mean the String produced by the parameterles Double.ToString() instance method which is of course identical to what is produced by ToString("G").

An interesting thing to note is that if you cast the above number to System.Decimal then you get a decimal that is 31 exactly! See this Stack Overflow question for a discussion of the surprising fact that casting a Double to Decimal involves first rounding to 15 digits. This means that casting to Decimal makes a correct round to 15 digits, whereas calling ToSting() makes an incorrect one.

To sum up, we have a floating-point number that, when output to the user, is 31.0000000000001, but when converted to Decimal (where 29 digits are available), becomes 31 exactly. This is unfortunate.

Here's some C# code for you to verify the problem:

static void Main()
{
  const double evil = 31.0000000000000497;
  string exactString = DoubleConverter.ToExactString(evil); // Jon Skeet, http://csharpindepth.com/Articles/General/FloatingPoint.aspx 

  Console.WriteLine("Exact value (Jon Skeet): {0}", exactString);   // writes 31.00000000000004973799150320701301097869873046875
  Console.WriteLine("General format (G): {0}", evil);               // writes 31.0000000000001
  Console.WriteLine("Round-trip format (R): {0:R}", evil);          // writes 31.00000000000005

  Console.WriteLine();
  Console.WriteLine("Binary repr.: {0}", String.Join(", ", BitConverter.GetBytes(evil).Select(b => "0x" + b.ToString("X2"))));

  Console.WriteLine();
  decimal converted = (decimal)evil;
  Console.WriteLine("Decimal version: {0}", converted);             // writes 31
  decimal preciseDecimal = decimal.Parse(exactString, CultureInfo.InvariantCulture);
  Console.WriteLine("Better decimal: {0}", preciseDecimal);         // writes 31.000000000000049737991503207
}

The above code uses Skeet's ToExactString method. If you don't want to use his stuff (can be found through the URL), just delete the code lines above dependent on exactString. You can still see how the Double in question (evil) is rounded and cast.

ADDITION:

OK, so I tested some more numbers, and here's a table:

  exact value (truncated)       "R" format         "G" format     decimal cast
 -------------------------  ------------------  ----------------  ------------
 6.00000000000000'53'29...  6.0000000000000053  6.00000000000001  6
 9.00000000000000'53'29...  9.0000000000000053  9.00000000000001  9
 30.0000000000000'49'73...  30.00000000000005   30.0000000000001  30
 50.0000000000000'49'73...  50.00000000000005   50.0000000000001  50
 200.000000000000'51'15...  200.00000000000051  200.000000000001  200
 500.000000000000'51'15...  500.00000000000051  500.000000000001  500
 1020.00000000000'50'02...  1020.000000000005   1020.00000000001  1020
 2000.00000000000'50'02...  2000.000000000005   2000.00000000001  2000
 3000.00000000000'50'02...  3000.000000000005   3000.00000000001  3000
 9000.00000000000'54'56...  9000.0000000000055  9000.00000000001  9000
 20000.0000000000'50'93...  20000.000000000051  20000.0000000001  20000
 50000.0000000000'50'93...  50000.000000000051  50000.0000000001  50000
 500000.000000000'52'38...  500000.00000000052  500000.000000001  500000
 1020000.00000000'50'05...  1020000.000000005   1020000.00000001  1020000

The first column gives the exact (though truncated) value that the Double represent. The second column gives the string representation from the "R" format string. The third column gives the usual string representation. And finally the fourth column gives the System.Decimal that results from converting this Double.

We conclude the following:

  • Round to 15 digits by ToString() and round to 15 digits by conversion to Decimal disagree in very many cases
  • Conversion to Decimal also rounds incorrectly in many cases, and the errors in these cases cannot be described as "round-twice" errors
  • In my cases, ToString() seems to yield a bigger number than Decimal conversion when they disagree (no matter which of the two rounds correctly)

I only experimented with cases like the above. I haven't checked if there are rounding errors with numbers of other "forms".

So from your experiments, it appears that Double.ToString doesn't do correct rounding.

That's rather unfortunate, but not particularly surprising: doing correct rounding for binary to decimal conversions is nontrivial, and also potentially quite slow, requiring multiprecision arithmetic in corner cases. See David Gay's dtoa.c code here for one example of what's involved in correctly-rounded double-to-string and string-to-double conversion. (Python currently uses a variant of this code for its float-to-string and string-to-float conversions.)

Even the current IEEE 754 standard for floating-point arithmetic recommends, but doesn't require that conversions from binary floating-point types to decimal strings are always correctly rounded. Here's a snippet, from section 5.12.2, "External decimal character sequences representing finite numbers".

There might be an implementation-defined limit on the number of significant digits that can be converted with correct rounding to and from supported binary formats. That limit, H, shall be such that H ≥ M+3 and it should be that H is unbounded.

Here M is defined as the maximum of Pmin(bf) over all supported binary formats bf, and since Pmin(float64) is defined as 17 and .NET supports the float64 format via the Double type, M should be at least 17 on .NET. In short, this means that if .NET were to follow the standard, it would be providing correctly rounded string conversions up to at least 20 significant digits. So it looks as though the .NET Double doesn't meet this standard.

In answer to the 'Is this a bug' question, much as I'd like it to be a bug, there really doesn't seem to be any claim of accuracy or IEEE 754 conformance anywhere that I can find in the number formatting documentation for .NET. So it might be considered undesirable, but I'd have a hard time calling it an actual bug.


EDIT: Jeppe Stig Nielsen points out that the System.Double page on MSDN states that

Double complies with the IEC 60559:1989 (IEEE 754) standard for binary floating-point arithmetic.

It's not clear to me exactly what this statement of compliance is supposed to cover, but even for the older 1985 version of IEEE 754, the string conversion described seems to violate the binary-to-decimal requirements of that standard.

Given that, I'll happily upgrade my assessment to 'possible bug'.

Reliably detecting compiler generated classes in C# expression trees

10 votes

I'm building a C# expression-to-Javascript converter, along the lines of Linq-to-SQL, but I'm running into problems with compiler generated expression trees.

The particular problem I'm having is dealing with MemberExpression values which were compiler generated, but which DO NOT have the CompilerGeneratedAttribute specified on their types.

Here's a cut-down version of what I've been trying:

void ProcessMemberExpression(MemberExpression memberX) {
    var expression = memberX.Expression;
    var expressionType = expression.Type;
    var customAttributes = expressionType.GetCustomAttributes(true);
    var expressionTypeIsCompilerGenerated = customAttributes.Any(x => x is CompilerGeneratedAttribute);
    if (expressionTypeIsCompilerGenerated) {
        var memberExpressionValue = Expression.Lambda(memberX).Compile().DynamicInvoke();
        ... do stuff ...
    }
    else {
        ... do other stuff ...
    }
}

Now, I have a Visual Studio debugging session open and I find this (running in the Immediate Window):

expressionType.Name
"<>c__DisplayClass64"
expressionType.GetCustomAttributes(true)
{object[0]}
expressionType.GetCustomAttributes(true).Length
0

So what I have here is an obviously compiler generated class with no custom attributes and hence no CompilerGeneratedAttribute! Therefore, my code will do other stuff, when I intend it to just do stuff.

If anyone could help me out here, I'd be very grateful. If at all possible, I'd really rather not do anything sordid like matching the expressionType.Name against something like <>.*__DisplayClass.

Based on Jon Skeet's answer here, it sounds like checking for angle brackets will work.

Where/what is the private variable in auto-implemented property?

Why would I need to check for greater than Int32.MaxValue?

Asked on Wed, 27 Jun 2012 by kmp c# .net
10 votes

I am using Visual Studio 2010 SP1 Ultimate on a c# class library project (.net 4) and I am curious about something...

Given this method:

public void DoSomethingBrilliant(int input)
{
    if (input == int.MaxValue)
        throw new ArgumentOutOfRangeException("input");

    input++;

    Console.WriteLine(input);
}

I get this warning from code analysis:

CA2233 : Microsoft.Usage : Correct the potential overflow in the operation 'input+1' in 'Test.DoSomethingBrilliant(int)'.

I thought to myself, that is a bit odd since I am checking that the input++ operation won't overflow by throwing that snazzy exception at the beginning but I changed it to this:

public void DoSomethingBrilliant(int input)
{
    if (input >= int.MaxValue)
        throw new ArgumentOutOfRangeException("input");

    input++;

    Console.WriteLine(input);
}

and sure enough the warning went away.

Now my little brain is all confused because given I am getting an int as an argument why would checking to see if it is greater than the maximum value allowed for an integer ever provide any value?

Then I went back to the original bit of code and switched to debug and it built without the warning! Curiouser and curioser...

I checked the differences between debug and release and found that if I tick the Optimize code option the warning from code analysis pops right back up.

So the optimization results in something that means I need to check for greater than int.MaxValue. Huh? Why? Am I being super dense? What has the optimization done that means I might get an int bigger than int.MaxValue passed into a method accepting an int?

Or, is this just a bug in the code analysis feature?

Update

Here is the IL for the "unoptimized" version (where the code analysis gets it right):

.method public hidebysig instance void  DoSomethingBrilliant(int32 input) cil managed
{
  // Code size       40 (0x28)
  .maxstack  2
  .locals init ([0] bool CS$4$0000)
  IL_0000:  nop
  IL_0001:  ldarg.1
  IL_0002:  ldc.i4     0x7fffffff
  IL_0007:  ceq
  IL_0009:  ldc.i4.0
  IL_000a:  ceq
  IL_000c:  stloc.0
  IL_000d:  ldloc.0
  IL_000e:  brtrue.s   IL_001b
  IL_0010:  ldstr      "input"
  IL_0015:  newobj     instance void [mscorlib]System.ArgumentOutOfRangeException::.ctor(string)
  IL_001a:  throw
  IL_001b:  ldarg.1
  IL_001c:  ldc.i4.1
  IL_001d:  add
  IL_001e:  starg.s    input
  IL_0020:  ldarg.1
  IL_0021:  call       void [mscorlib]System.Console::WriteLine(int32)
  IL_0026:  nop
  IL_0027:  ret
} // end of method Test::DoSomethingBrilliant

and here it is for the optimized version (where it gets it wrong):

.method public hidebysig instance void  DoSomethingBrilliant(int32 input) cil managed
{
  // Code size       31 (0x1f)
  .maxstack  8
  IL_0000:  ldarg.1
  IL_0001:  ldc.i4     0x7fffffff
  IL_0006:  bne.un.s   IL_0013
  IL_0008:  ldstr      "input"
  IL_000d:  newobj     instance void [mscorlib]System.ArgumentOutOfRangeException::.ctor(string)
  IL_0012:  throw
  IL_0013:  ldarg.1
  IL_0014:  ldc.i4.1
  IL_0015:  add
  IL_0016:  starg.s    input
  IL_0018:  ldarg.1
  IL_0019:  call       void [mscorlib]System.Console::WriteLine(int32)
  IL_001e:  ret
} // end of method Test::DoSomethingBrilliant

I see a bunch of extra calls before the throw operation but I am going to be honest - I have no idea what they do!

Or, is this just a bug in the code analysis feature?

Looks like it. Not terribly surprising, to be honest - getting this sort of code analysis to be perfect is mightily tricky. Given that any particular int cannot be greater than int.MaxValue, >= and == are definitely equivalent.

When does the UnderlyingSystemType differ from the current Type instance

10 votes

System.Type contains a UnderlyingSystemType property. Msdn states that it:

Indicates the type provided by the common language runtime that represents this type.

In most cases, this property simply returns the current Type instance.

My question is, in what circumstances does this property not return the current Type instance itself. And in those cases, what sort of type will be the current Type instance and the returned underlying system type be?

To be honest I never did it by myself, but I know that it is possible to create your own RuntimeType like definition of your specified type.

If you notice the Type class is abstract and has a lot of abstract memebers. What happens is that your type (whatever is it) automatically creates RuntimeType derived from Type class and implements it for your type.

So the property UnderlyingSystemType in case of orindary RuntimeType will return Type property equal value, in case of overriden implementation, instead, (that is for influencing relfection behavior, but I repeat I personally never did this before), will return user-defined type value.

EDIT

Actually the link provided by guys in comments is a good one:

When is a Type not a Type?

How different async programming is from Threads?

9 votes

I've been reading some async articles here: http://www.asp.net/web-forms/tutorials/aspnet-45/using-asynchronous-methods-in-aspnet-45 and the author says :

When you’re doing asynchronous work, you’re not always using a thread. For example, when you make an asynchronous web service request, ASP.NET will not be using any threads between the async method call and the await.

So what I am trying to understand is, how does it become async if we don't use any Threads for concurrent execution? What does it mean "you're not always using a thread."?

Let me first explain what I know regarding working with threads (A quick example, of course Threads can be used in different situations other than UI and Worker methodology here)

  1. You have UI Thread to take input, give output.
  2. You can handle things in UI Thread but it makes the UI unresponsive.
  3. So lets say we have a stream-related operation and we need to download some sort of data.
  4. And we also allow users to do other things while it is being downloaded.
  5. We create a new worker thread which downloads the file and changes the progress bar.
  6. Once it is done, there is nothing to do so thread is killed.
  7. We continue from UI thread.

We can either wait for the worker thread in UI thread depending on the situation but before that while the file is being downloaded, we can do other things with UI thread and then wait for the worker thread.

Isn't the same for async programming? If not, what's the difference? I read that async programming uses ThreadPool to pull threads from though.

Threads are not necessary for asynchronous programming.

"Asynchronous" means that the API doesn't block the calling thread. It does not mean that there is another thread that is blocking.

First, consider your UI example, this time using actual asynchronous APIs:

  1. You have UI Thread to take input, give output.
  2. You can handle things in UI Thread but it makes the UI unresponsive.
  3. So lets say we have a stream-related operation and we need to download some sort of data.
  4. And we also allow users to do other things while it is being downloaded.
  5. We use asynchronous APIs to download the file. No worker thread is necessary.
  6. The asynchronous operation reports its progress back to the UI thread (which updates the progress bar), and it also reports its completion to the UI thread (which can respond to it like any other event).

This shows how there can be only one thread involved (the UI thread), yet also have asynchronous operations going on. You can start up multiple asynchronous operations and yet only have one thread involved in those operations - no threads are blocked on them.

async/await provides a very nice syntax for starting an asynchronous operation and then returning, and having the rest of the method continue when that operation completes.

ASP.NET is similar, except it doesn't have a main/UI thread. Instead, it has a "request context" for every incomplete request. ASP.NET threads come from a thread pool, and they enter the "request context" when they work on a request; when they're done, they exit their "request context" and return to the thread pool.

ASP.NET keeps track of incomplete asynchronous operations for each request, so when a thread returns to the thread pool, it checks to see if there are any asynchronous operations in progress for that request; if there are none, then the request is complete.

So, when you await an incomplete asynchronous operation in ASP.NET, the thread will increment that counter and return. ASP.NET knows the request isn't complete because the counter is non-zero, so it doesn't finish the response. The thread returns to the thread pool, and at that point: there are no threads working on that request.

When the asynchronous operation completes, it schedules the remainder of the async method to the request context. ASP.NET grabs one of its handler threads (which may or may not be the same thread that executed the earlier part of the async method), the counter is decremented, and the thread executes the async method.

ASP.NET vNext is slightly different; there's more support for asynchronous handlers throughout the framework. But the general concept is the same.

For more information:

How can I unsubscribe to this .NET event?

9 votes

I wish to programatically unsubscribe to an event, which as been wired up.

I wish to know how I can unsubscribe to the EndRequest event.

I'm not to sure how to do this, considering i'm using inline code. (is that the correct technical term?)

I know i can use the some.Event -= MethodName to unsubscribe .. but I don't have a method name, here.

The reason I'm using the inline code is because I wish to reference a variable defined outside of the event (which I required .. but feels smelly... i feel like I need to pass it in).

Any suggestions?

Code time..

public void Init(HttpApplication httpApplication)
{
    httpApplication.EndRequest += (sender, e) =>
    {
        if (some logic) 
            HandleCustomErrors(httpApplication, sender, e,
                              (HttpStatusCode)httpApplication.Response.StatusCode);
    };

    httpApplication.Error += (sender, e) => 
            HandleCustomErrors(httpApplication, sender, e);
}

private static void HandleCustomErrors(HttpApplication httpApplication, 
                                       object sender, EventArgs e, 
                                       HttpStatusCode httpStatusCode =
                                           HttpStatusCode.InternalServerError)
{ ... }

This is just some sample code I have, for me to handle errors in a ASP.NET application.

NOTE: Please don't turn this into a discussion about ASP.NET error handling. I'm just playing around with events and using these events for some sample R&D / learning.

It's not possible to unsubscribe that anonymous delegate. You would need to store it in a variable and unsubscribe it later:

EndRequestEventHandler handler = (sender, e) =>
{
    if (some logic) 
        HandleCustomErrors(httpApplication, sender, e,
                          (HttpStatusCode)httpApplication.Response.StatusCode);
};

httpApplication.EndRequest += handler;
// do stuff
httpApplication.EndRequest -= handler;

Consuming a web service using a different interface

9 votes

I have a wsdl file that is constructed in an extremely unhelpful way. It is huge,in some cases several megabytes in size, and when I use the various Visual Studio tools to generate a wrapper from it, the resulting codebase is so large that it tends to crash Visual Studio on weaker machines. The compilation time is ludicrous, and the resulting class uses properties where a more dynamic mode of access is absolutely necessary (i.e. some sort of indexer). There is no option of any changes on the server side.

The wsdl files are far larger than could be processed by hand, and there is an arbitrary number of them. The solution I've employed so far, is to use reflection or late binding with the resulting, auto-generated class. However, since I'm dealing here with a wrapper that wraps what's basically a client for SOAP messages it would make sense if there is another way.

Essentially, I want to create a wrapper that exposes a more dynamic interface, especially where fields are concerned. The task isn't entirely straightforward, so I'm looking for suggestions regarding what to do, and various classes, customizable code generators, WSDL explorers/parsers, etc, that will make the task less time-consuming. Should I construct my own SOAP client? What would I base it on? What .NET features can help me with this task?

You could hand craft an interface that supports a subset of the methods available on the WebService and do away with the need to generate a service reference.

You would have to create the right soap signature for the methods including dto's and namespaces. The downside of this is that you would be forced to manage any changes to the service manually.

Here is a simple example showing a proxy client created with the ISubsetInterface communication with a service exposing the IServiceInterface. To achieve this the Name property has to match the name of the IServiceInterface contract which in this case defaults to "IServiceInterface" but your implementation might require manipulation of the Namespace and Actions. The simplest way to know what you need to manipulate is to look at the generated wsdl.

[TestFixture]
public class When_using_a_subset_of_a_WCF_interface
{
    [Test]
    public void Should_call_interesting_method()
    {
        var serviceHost = new ServiceHost(typeof(Service));

        serviceHost.AddServiceEndpoint( typeof(IServiceInterface), new BasicHttpBinding(), "http://localhost:8081/Service" );
        serviceHost.Description.Behaviors.Find<ServiceDebugBehavior>().IncludeExceptionDetailInFaults = true;

        serviceHost.Open();

        using( var channelFactory = new ChannelFactory<ISubsetInterface>( new BasicHttpBinding(), "http://localhost:8081/Service") )
        {
            var client = channelFactory.CreateChannel();

            client.InterestingMethod().Should().Be( "foo" );
        }

        serviceHost.Close();
    }

    [ServiceContract]
    interface IServiceInterface
    {
        [OperationContract]
        string InterestingMethod();
        [OperationContract]
        string UninterestingMethod();
    }

    [ServiceContract(Name = "IServiceInterface")]
    interface ISubsetInterface
    {
        [OperationContract]
        string InterestingMethod();
    }

    class Service : IServiceInterface
    {
        public string InterestingMethod() { return "foo"; }

        public string UninterestingMethod() { throw new NotImplementedException(); }
    }
}

Does List<T>.Last() enumerate the collection?

9 votes

Considering the boundaries of a List are known, does .Last() enumerate the collection?

I ask this because the documentation says that it is defined by Enumerable (in which case it would need to enumerate the collection)

If it does enumerate the collection then I can simply access the last element by index (as we know the .Count of a List<T>) but it seems silly to have to do this....

It does enumerate the collection if it's an IEnumerable<T> and not an IList<T>(with an Array or List the index would be used).

Enumerable.Last is implemented in the following way (ILSpy):

public static TSource Last<TSource>(this IEnumerable<TSource> source)
{
    if (source == null)
    {
        throw Error.ArgumentNull("source");
    }
    IList<TSource> list = source as IList<TSource>;
    if (list != null)
    {
        int count = list.Count;
        if (count > 0)
        {
            return list[count - 1];
        }
    }
    else
    {
        using (IEnumerator<TSource> enumerator = source.GetEnumerator())
        {
            if (enumerator.MoveNext())
            {
                TSource current;
                do
                {
                    current = enumerator.Current;
                }
                while (enumerator.MoveNext());
                return current;
            }
        }
    }
    throw Error.NoElements();
}

1.2GB memory exception

8 votes

I read about memory limit

I have an application which works with huge images which needs to be streamed. Like in a video processing with single frames. The application has about 40 plugins, each of them can contain database, image processing and WPF GUI.

The application also has 2 plugins which uses older DotNet Winforms.

All works well except the application goes over about 1.2GB in RAM. Then on unusual locations in the plugins where new memory is allocated I receive the "Out of Memory exception".

I am working on a 64Bit system compiled as 32Bit. I have no more idea what to do and how to search for any fault.

Is there a limit or can I catch them?

It is very difficult to write a 32-bit program that consumes all of the available virtual memory space. You'll hit the wall well below 2 gigabytes, what you run out of first is a chunk of virtual memory that's large enough to fit the requested size. You can only get up to the 2GB limit by making small allocations, small enough to fit in the holes.

That wall hits early in a program that manipulates bitmaps. They can consume a big chunk of VM to store the bitmap pixels and it needs to be a contiguous allocation. They are stored in an array, not a tree. It's an unmanaged memory allocation, typical .NET memory profilers tend to be a bit helpless to show you the problem.

There isn't anything reasonable you can do about address space fragmentation, the notion that consuming all available VM should be possible is just wrong. You can get more breathing space on a 64-bit operating system by running editbin.exe in a post build event and use its /LARGEADDRESSAWARE command line option. That allows the process to use the available 4 gigabytes of VM, an option that's specific to the 64-bit version of Windows and possible because Windows doesn't need the upper 2GB. And of course, changing the platform target to AnyCPU is a quick and easy way to get gobs of virtual memory.

Undefined CLR namespace - No solution found

8 votes

I've been researching for a while now trying to find a reason why the following would be occuring, but no solutions on StackOverflow or Google are able to help me.

I have a custom UserControl that is attempting to reference a namespace within the same project:

xmlns:my="clr-namespace:ColorPicker"

however when I compile I get the following error:

Undefined CLR namespace. The 'clr-namespace' URI refers to a namespace 'ColorPicker' that is not included in the assembly.

This is resulting in not being able to build my project or reference other custom controls within the xaml, generating these kinds of errors:

The type 'my:ColorSelector' was not found. Verify that you are not missing an assembly reference and that all referenced assemblies have been built.

I've attempted all the solutions given in these posts:

adding a custom namespace to xaml

WPF xmlns: The 'clr-namespace' URI refers to a namespace that is not included in the assembly

The 'clr-namespace' URI refers to a namespace that is not included in the assembly

Undefined CLR namespace

Also, just to be clear, I'm not getting any other errors about other files in this project, so it doesn't seem like it could be the result of other files not compiling.

UPDATE: A sample project that produces the error for me can be downloaded here: http://www.filefactory.com/file/28fbmhj3f4qj/n/ColorPicker_zip

Your first linked question has the answer. The answer is: you have to build the assembly containing the namespace and referenced classes/controls before you can reference it in .xaml. I commented out your xaml namespace declarations, then commented out the xaml elements from those namespaces, then commented out the C# code that broke as a result of those elements no longer being declared. In other words, I kept commenting till I could build successfully. Once the assembly built, I uncommented the xaml namespace declarations, then the elements. This gave an error about needing to use x:Name instead of Name on those elements, so I did so. Then uncommented the C# code and it builds.

is there an asp.net fiddle?

7 votes

Similar to jsfiddle, is there an asp.net fiddle website for us to share asp.net code fiddles? It'll greatly help asp.net developers. the current way to post asp.net code on SO is not so reader friendly. I hope there's something out there to make this easier. If there isn't anything like that (as i did some search but can't find one). Is this even something technically possible to be developed since c# is not a late binding language.

You could use something like compilr.com, It requires an account to create projects but people can view it anonymously. It's pretty neat.

Example: http://compilr.com/cravecode/test-share/main.cs

UPDATE

I'd also checkout coderun.com/ide

Database table insert locks from a multi threaded application

7 votes

I have a process that is running multi threaded.

Process has a thread safe collection of items to process.

Each thread processes items from the collection in a loop.

Each item in the list is sent to a stored procedure by the thread to insert data into 3 tables in a transaction (in sql). If one insert fails, all three fails. Note that the scope of transaction is per item.

The inserts are pretty simple, just inserting one row (foreign key related) into each table, with identity seeds. There is no read, just insert and then move on to the next item.

If I have multiple threads trying to process their own items each trying to insert into the same set of tables, will this create deadlocks, timeouts, or any other problems due to transaction locks?

I know I have to use one db connection per thread, i'm mainly concerned with the lock levels of tables in each transaction. When one thread is inserting rows into the 3 tables, will the other threads have to wait? There is no dependency of rows per table, except the auto identiy needs to be incremented. If it is a table level lock to increment the identity, then I suppose other threads will have to wait. The inserts may or may not be fast sometimes. If it is going to have to wait, does it make sense to do multithreading?

The objective for multithreading is to speed up the processing of items.

Please share your experience.

PS: Identity seed is not a GUID.

In SQL Server multiple inserts into a single table normally do not block each other on their own. The IDENTITY generation mechanism is highly concurrent so it does not serialize access. Inserts may block each other if they insert the same key in an unique index (one of them will also hit a duplicate key violation if both attempt to commit). You also have a probability game because keys are hashed, but it only comes into play in large transactions, see %%LOCKRES%% COLLISION PROBABILITY MAGIC MARKER: 16,777,215. If the transaction inserts into multiple tables also there shouldn't be conflicts as long as, again, the keys inserted are disjoint (this happens naturally if the inserts are master-child-child).

That being said, the presence of secondary indexes and specially the foreign keys constraints may introduce blocking and possible deadlocks. W/o an exact schema definition is impossible to tell wether you are or are not susceptible to deadlocks. Any other workload (reports, reads, maintenance) also adds to the contention problems and can potentially cause blocking and deadlocks.

Really really really high end deployments (the kind that don't need to ask for advice on forums...) can suffer from insert hot spot symptoms, see Resolving PAGELATCH Contention on Highly Concurrent INSERT Workloads

BTW, doing INSERTs from multiple threads is very seldom the correct answer to increasing the load throughput. See The Data Loading Performance Guide for good advice on how to solve that problem. And one last advice: multiple threads are also seldom the answer to making any program faster. Async programming is almost always the correct answer. See AsynchronousProcessing and BeginExecuteNonQuery.

As a side note:

just inserting one row (foreign key related) into each table, ... There is no read,

This statement is actually contradicting itself. Foreign keys implies reads, since they must be validated during writes.

Why I get squares instead of text?

7 votes

I tried to install and use a font in my WPF application, but all I get is like this: enter image description here

Here is the code I tried to use the font:

richtext1.FontFamily = "SH_Roq'a";

The expected result is: ( snap shot from MS Word ) enter image description here

If I try to add the font file to the project folder, and use it as a resource, like this:

richtext1.FontFamily = "./#SH_Roq'a";

I won't get the square results, but, I won't have the expected font either! What I get is Tahoma font:

enter image description here

which is not the targeted font, please download the targeted font file here for experiments

Any help is appreciated!

EDIT

The plain text for the above captured text is:

تفاح احمر

So for those who are experts with using fonts, they can experiment with.

There are several problems with the font:

  1. it is not Unicode-encoded: it uses a Platform ID 3, Encoding ID 0 cmap subtable, also known as a "Symbol" table. These do not generally work well outside of old-style Windows desktop applications.

  2. there are no OpenType Layout features (GSUB, GPOS, etc.) which are essential for correct shaping (initial, medial, final, isolated forms; lam-alef ligatures, etc.) of Arabic/Urdu/Farsi writing.

  3. it uses a very, very old OS/2 table (version 0). Some Microsoft technologies require version 1 at minimum. There are also reserved bits set in the fsSelection field of this table and a number of other suspect settings.

I stopped looking there. This font appears to have been built with very old tools, using outdated knowledge of font construction. It needs significant updating in order to work correctly in modern environments.