Here's a tip for young players. You may find that getting the latest WiX 3.0 beta from here gives you an error saying that you need to have a version of Visual Studio installed that is above the Express edition. I have Team Suite installed, so it should be a problem. After lots of research, I came across this post which gave me the answer. It wasn't a problem with the version of Visual Studio that I had installed, it was because latest build published on the SourceForge download page was prior to their support of x64 systems. After downloading the latest build published here, it's all good.
One of my most used feature in the 3.5 compiler for .Net is automatic properties. In case you are not familiar, here is a recap.
Traditionally, properties work with a backing field. For example:
private String _someValue;
public String SomeValue
{
get
{
return _someValue;
}
set
{
_someValue = value;
}
}
Automatic properties under the 3.5 compiler allow this code to be represented as:
public String SomeValue
{
get;
set;
}
Automatic properties make code cleaner and easier to use. Additionally, they also require less testing. There isn't any point testing their logic of accessing the backing field to ensure correct operation and they appear with 100% code coverage. My biggest gripe though is that they don't truly support readonly definitions.
The documentation on MSDN says:
Auto-implemented properties must declare both a get and a set accessor. To create a readonly auto-implemented property, give it a private set accessor.
The implementation of automatic properties by the compiler define that readonly automatic properties are achieved by assigning a private scope to the set accessor. For example:
public String SomeValue
{
get;
private set;
}
Unfortunately, I think this is a cheap bandaid hack. It doesn't make the property truly readonly. It is technically readonly, but only from the perspective of external callers. Internal to the class, the property is not readonly because the private scope makes setting the property value possible. This doesn't protect the value of the backing field which is what a true readonly property should be able to support. See here for the MSDN documentation on the readonly keyword.
I would like to see this changed. Without understanding the complexities of writing compilers, I would think that this change would not be too significant. The simple fix would be to enhance the syntax of the automatic property setter definition. If the private set statement could be enhanced to understand a readonly keyword, then the compile could mark the backing field with the same readonly keyword. For example:
public String SomeValue
{
get;
private readonly set;
}
This would then be interpreted by the compiler as something like this:
private readonly String _someValue;
public String SomeValue
{
get
{
return _someValue;
}
set
{
_someValue = value;
}
}
I have added this as a suggestion to Microsoft Connect here.
I have been pulling my hair out this afternoon trying to figure out why my code is performing so badly in a load test. After playing with the code and running a lot of tests, I didn't have any answers until I looked at my testrunconfig file. Code coverage was the first thing I looked at.
With code coverage turned on, the report looked like this.
After I turned code coverage off, I was much happier.
The Test Response Time graphs (top right) highlight the difference between the test run performance as does the the CPU usage (red line in the bottom right graph). Of the four tests, the one that is doing the most work was averaging 6.76 seconds per test with code coverage which is atrocious. Without code coverage, this test was running an average of 0.00024 seconds per test. Just a little different.
Updated: Changed images so they are more readable and changed the scale of the Test Response Time graph so the difference of the tests can be seen.
I read Patrick Smacchia's post this morning about a simple trick to code better and to increase testability and found it to be a great argument. These are the kinds of posts that I really enjoy reading and thinking about. They often have me hacking up test projects to flesh out ideas or kicking off Reflector to see what the BCL is doing.
This was a good post because it got me to challenge why I am coding in the particular style that I have. I have always been a fan of combining if tests when it doesn't result in overly complex logic. In this case, Patrick is arguing that such a style of coding increases nesting depth and makes testing harder.
Take this test case based on his post:
using System;
using System.Collections.Generic;
using System.Diagnostics;
namespace ConsoleApplication1
{
internal class Program
{
public static void MethodA(List<String> list)
{
foreach (String item in list)
{
if (item == null || item.Length == 0
|| item.Contains("a"))
{
continue;
}
Console.Write(String.Empty);
}
}
public static void MethodB(List<String> list)
{
foreach (String item in list)
{
if (item == null)
{
continue;
}
if (item.Length == 0)
{
continue;
}
if (item.Contains("a"))
{
continue;
}
Console.Write(String.Empty);
}
}
private static void Main(String[] args)
{
List<String> items = new List<String>(100);
for (Int32 index = 0; index < 100; index++)
{
items.Add(index.ToString());
}
Stopwatch watch = new Stopwatch();
watch.Start();
for (Int32 firstLoop = 0; firstLoop < 100000; firstLoop ++)
{
MethodA(items);
}
watch.Stop();
Int64 firstTickCount = watch.ElapsedTicks;
watch.Reset();
watch.Start();
for (Int32 secondLoop = 0; secondLoop < 100000; secondLoop++)
{
MethodB(items);
}
watch.Stop();
Int64 secondTickCount = watch.ElapsedTicks;
Console.WriteLine(firstTickCount);
Console.WriteLine(secondTickCount);
Console.WriteLine(secondTickCount - firstTickCount);
Console.ReadKey();
}
}
}
MethodA contains the combined if tests while MethodB separates them out into individual tests. While I'm not sure about the nesting depth argument due to compiler optimizations, I totally agree about the increase in testability. I also think that such a coding style is much more readable. The risk of combined if tests is that they quickly become complex and difficult to understand.
The first question I had about this was what is the impact on compiled code? Does this change impact performance? After writing up the above test case, I found that it doesn't (as unscientific as the test case is). The next step was to check out the difference in the IL. Turns out that both methods have exactly the same IL. This would explain the similar performance results. I say similar because there would be many outside influences that would result in slightly different outcomes.
So performance isn't a problem as the compiler optimizes the code. The code is more readable and there is no risk of getting confused about the combination of if statements. It is also, as Patrick argues, more testable. The individual continue statements will not get covered if the related scenario of an if statement is not tested for. On this point however, Visual Studio will highlight the line as partially tested rather than 100% covered, but doesn't help in telling you which part of the statement wasn't covered. This makes this style more testable as it is completely clear what hasn't been tested.
I'm no IL expert, but it is interesting that the compiler seems to choose the more complex version (at least to Reflectors interpretation). The following is Reflectors decompilation of the release build interpreted in C#.
public static void MethodB(List<string> list)
{
foreach (string item in list)
{
if (((item != null) && (item.Length != 0)) && !item.Contains("a"))
{
Console.Write(string.Empty);
}
}
}
I think I have a new change to my coding style.