I’ve seen this question coming up a few times, and bumped into this at a client recently: the UAC dialog coming up when debugging a 32-bit executable.
This is caused (more details below) by Installer Detection Technology introduced in Windows Vista (with UAC) and tightened in more modern Windows versions.
The solution is to either:
not include Installer, Patch, Update, Upgrade, Setup, … in your EXE name
provide a correct manifest to your EXE (getting this right can be hard)
Had to investigate some Assembly Loading issues, so I wrote two batch files to enable and disable the .NET Fusion Log:
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
It is all about handling values that are not Integers, Overflow values and Nulls. There are subtle differences, in the handling of the methods, and the exceptions they could throw: ArgumentNullException, FormatException and OverflowException.
During a recent code review, I bumped into a couple of C# constructors having boolean parameters, leading to the dreaded magic booleans code smell.
This reminded me of the infamous Avoiding Booleans post on Coding Horror, which now is almost 10 years old.
To celebrate, I will coin the Dutch phrase when marking these in a review:
Boolean parameters en literals zijn vrijwel altijd een zwaktebod. Een teken dat beter nagedacht moet worden over het doel van de code.
The Dutch word zwaktebod is used when bidding Bridge using the Acol system. It is the equivalent of a “weak takeout” response to a bid of 1 NT (notrump or no trump, in other languages sometimes sans atout).
The English translation is just about this:
Boolean parameters and literals virtually always are a sign of weakness. It indicates you need to give more thought to the goal of the code.
Setting ForeColor = Color.Red (funny there is a plural in SystemColors but not in Color) it doesn’t display it as such:
To my surprise, the TextBox had ReadOnly text (you could copy, but not modify it), which showed with a a grey (SystemColors.Control) BackColor and a black (SystemColors.WindowText) ForeColor: the defaults for a ReadOnly TextBox, not using my ForeColor = Color.Red;
I vaguely remembered there was some odd way of solving this, but since I hadn’t written a blog article about it back then (somewhere around .NET 1.x or 2.0 I didn’t have a blog yet), I was glad that Cheetah posted this answer on StackOverflow: Read the rest of this entry »
Reuse the VB.NET built-in Replace Function (Visual Basic) which works at least as of Visual Studio 2003 (.NET 1.1) and probably in Visual Studio 2002 (.NET 1.0, which I don’t have any more)
Normally you would not want to use a reserved word as an identifier. But sometimes it can be very convenient, for instance for a code generator that wraps remoting calls or does ORM.
Bosak posted an interesting piece of code on StackOverflow last year. His particular code was in C#, but it does not matter what kind of compiler you use:
Sometimes a compiler will complain about unreachable code, for instance when it thinks a function never returns a value.
But you know the program logic does.
Simple solution: When you have code that never should be reached: throw an appropriate exception.
public static int GetInt(int number)
{
int[] ints = new int[]{ 3, 7, 9, int.MaxValue };
foreach (int i in ints)
if (number <= i)
return i;
return int.MaxValue; //this should be unreachable code since the last int is int.MaxValue and number <= int.MaxValue is allways true so the above code will allways return
}