Track Current Item in Visual Studio
Pretty dumb post, but I always forget where this option is, yet I hardly can live without it.
So here it is:
- Projects and Solutions
- General
- Track Active Item in Solution Explorer
- General
Something else I can’t live without and yet is not set by default is the line numbers. I really don’t understand why this is not set as default!
Recycling Application Pools with PowerShell
A few days ago, a colleague and I were looking for a way to recycle Application Pools in a PowerShell script.
Turned out that we couldn’t find any “native” way of doing this, but it is still possible to do it using the Microsoft.Web.Administration.ServerManager class:
[void][Reflection.Assembly]::LoadWithPartialName("Microsoft.Web.Administration") function RecycleAppPools() { $serv = new-object Microsoft.Web.Administration.ServerManager $serv.ApplicationPools | % { $_.Recycle() } }
Not much, but still pretty useful. However, this will recycle all the Application Pools on the IIS server. In our case, we were only interested in recycling the Sharepoint related pools.
A simple Where did the trick:
$serv.ApplicationPools | ? { $_.Name -like "SharePoint*" } | % { $_.Recycle() }
Reading an Int32 from a DataRow coming from SharePoint
In my previous post, I described how to convert a String to an Int32 making sure that Convert.ToInt32 works all the time for positive integers.
Now, there is still an issue with that method: when the integer is negative. In that case, adding a 0 in front of it does not work and makes the conversion throw a FormatException, as the underlying parse chokes on the “0-”.
Now, the obvious ultimate solution to that problem is simply to write an extension method for DataRow to try to parse the value as an Int32:
internal static int FieldAsInt32(this DataRow dataRow, String columnName, int defaultValue) { var fieldValue = dataRow.Field<String>(columnName); int value; if (Int32.TryParse(fieldValue, out value)) { return value; } else { return defaultValue; } } internal static int FieldAsInt32(this DataRow dataRow, String columnName) { return dataRow.FieldAsInt32(columnName, 0); }
I added an overload that takes the default value, i.e. the value that is to be returned if the parse fails. The default for that is 0. This might not be useful in all cases, but in our case this field is used to order elements, so if it can be parsed, it has to return a very high value to make sure it is the latest in the ordered sequence.
Convert.ToInt32(String) With an Empty String
Lately, I have been struggling with the Convert.ToInt32 overload that takes a String as a parameter. Basically, it’s the same as Int32.Parse, except that if the given String is null, it returns 0 instead of throwing a FormatException. That’s quite cool, but Convert.ToInt32 still throws when the argument is an empty String…
Now, my particular case is that I’m retrieving data from Sharepoint, and that the field retrieved can be empty if the user left it blank (when retrieving the field trough a DataTable).
The workaround to that issue is actually pretty silly: just add a 0 at the beginning of the parsed String, and it will work all the time (and return 0 when the string is empty, as it does with null). Now mind you, this only works with positive integers. If your integer is negative, adding a 0 in front of it will make the Convert.ToInt32 throw a FormatException again…
String theInt = ""; //Throws... Console.WriteLine(Convert.ToInt32(theInt)); //Doesn't throw Console.WriteLine(Convert.ToInt32("0" + theInt)); theInt = Int32.MaxValue.ToString(); //Doesn't throw Console.WriteLine(Convert.ToInt32("0" + theInt)); theInt = Int32.MinValue.ToString(); //Throws again... Console.WriteLine(Convert.ToInt32("0" + theInt));
So, this is safe to use if you are certain that the integer in the String is always positive.
PS: note that I always write String with a capital S in my code (and in text), this is a habit left from Java I guess…
C# Compiler Emits call IL Instruction for Instance Methods Called on the Reference Returned by a Constructor
Some time ago, I wrote how the call instruction could actually call an instance method on a null reference, and that inside this instance method, the this keyword would reference to null.
I find that very interesting, so I kept on disassembling some sample code to see what’s the generated IL and try to grasp some of the compiler’s logic.
Here is some simple code used to see what’s the IL generated by the C# compiler:
class Hello1 { internal String GetHello() { return "Hello1"; } } sealed class Hello2 { internal String GetHello() { return "Hello2"; } } static void Main(string[] args) { var h1 = new Hello1(); Console.WriteLine(h1.GetHello()); var h2 = new Hello2(); Console.WriteLine(h2.GetHello()); Console.WriteLine(new Hello1().GetHello()); Console.WriteLine(new Hello2().GetHello()); Console.ReadLine(); }
In the first two calls, we use a local variable that we call the GetHello method on, and in the two last calls we instantiate the object and call the GetHello method on the reference returned by the constructor, reference that we don’t keep.
Here’s the IL generated for the Main method:
We can see that in the first two call, the callvirt instruction is emitted by the compiler. As the call happens on a variable, the runtime type of the object could be different from the compile type, meaning that using the callvirt instruction makes sense (the compiler is not “smart” enough to detect that the compile time and the runtime types are the same).
In the two subsequent calls, however, as the method call is done on the reference returned by the constructor, the instruction emitted is call, which is slightly more performant than callvirt.
For more information on call and callvirt instructions, see ECMA 335 12.4.1.2.
