“Add Service Reference” option not appearing in Visual Studio 2008
Had to do a bit of head-scratching on this one. New projects created in Visual Studio 2008 did show the “Add Service Reference” when right-clicking on a project in Solution Explorer while some existing ones didn’t.
Using “Add Web Reference” instead of “Add Service Reference” has its own set of issues in that WCF services are meant to be used with DataContractSerializer. “Add Web Reference” utilizes XmlSerializer which might lead to some surprises when consuming WCF web-services. The way the two serializers handle WSDL is different. This article explains why you might find that property values of your complex types in web-services do not reach all the way to the web-service from the client.
Somebody logged a Microsoft Connect ticket on this but didn’t receive an answer because the issue couldn’t be reproduced.
Anyway, if you’re facing this issue – make sure that the target framework for your project is .NET 3.0 or later (you can do this in the Application tab of your project’s properties). You need to do this extra step if you upgrade your project to Visual Studio 2008 from older versions otherwise “Add Service Reference” wouldn’t appear. You can target .NET 2.0 from Visual Studio 2008 projects and that’s the default behavior during upgrade.
Update: This didn’t fix the issue for you? Check the comments for more alternatives.
A simple RTF report generator
I was describing how a simple yet extensible report-generator could be implemented quickly to somebody. I’m posting it here as some of you might find it useful (and I can refer to this link in future conversations 
).
The concept:
…is really simple. The idea is to look for a placeholder like @Fruit and replace it with “Apple”. However to make the whole thing extensible, reflection is used. When calling the report generator, you need to specify a reportInput object (can be of any type), in addition to the file-paths of input and output reports. The report-generator uses reflection to determine the properties available on the reportInput object. For each property, it derives a tag name and substitutes the derived tag name with the actual property value in the input file. The text read from the input file after making replacements is finally written to the output file. For further extensibility, the tag format is not hard-coded and can be specified as an argument.
Before (an RTF file with placeholders):
After (an RTF file with placeholders replaced with values):
The code:
public static class SimpleReportGenerator
{
public static void Generate(string inputFilePath, string outputFilePath, object reportInput, string tagFormat)
{
if (string.IsNullOrEmpty(inputFilePath))
throw new ArgumentException("inputFilePath");
if (string.IsNullOrEmpty(outputFilePath))
throw new ArgumentException("outputFilePath");
if (reportInput == null)
throw new ArgumentNullException("reportInput");
if (string.IsNullOrEmpty(tagFormat))
throw new ArgumentException("tagFormat");
string inputFileText = File.ReadAllText(inputFilePath);
StringBuilder reportOutput = new StringBuilder(inputFileText);
Type reportInputType = reportInput.GetType();
PropertyInfo[] properties = reportInputType.GetProperties();
foreach (PropertyInfo property in properties)
{
string propertyTag = String.Format(tagFormat, property.Name);
object propertyValueObj = property.GetValue(reportInput, null);
string propertyValue = (propertyValueObj != null) ? propertyValueObj.ToString() : String.Empty;
reportOutput.Replace(propertyTag, propertyValue);
}
File.WriteAllText(outputFilePath, reportOutput.ToString());
}
}
An example:
Defining ReportInput
public class ReportInput
{
public string ReportTitle { get; set; }
public string ReportHeading { get; set; }
public string ReportBody { get; set; }
public string ReportAuthor { get; set; }
public DateTime ReportDate { get; set; }
}
Creating a ReportInput for testing
public ReportInput GetTest()
{
ReportInput input = new ReportInput() { ReportAuthor = "John Doe", ReportBody = "A quick brown fox jumped over a lazy dog", ReportDate = DateTime.Now, ReportHeading = "The new report", ReportTitle = "Here we go" };
return input;
}
Generating a report
string input = "testreport.rtf";
string output = "testreport_out.rtf";
ReportInput reportInput = GetTest();
// "@{0}" indicates that a property named "Foo" corresponds to "@Foo" tag in the input file.
SimpleReportGenerator.Generate(input, output, reportInput, "@{0}");
ArrayList item comparison
What’ll be the output of the following piece of code (asked here)?
ArrayList a = new ArrayList(); ArrayList b = new ArrayList(); a.Add(1); b.Add(1); a.Add(2); b.Add(2.0); Console.WriteLine(a[0] == b[0]); Console.WriteLine(a[1] == b[1]);
One might expect…
True
True
But what you’d actually get is…
False
False
…because of boxing.
a.Add(1) boxes the integer 1 into an object and stores it in a, while b.Add(1) boxes the integer 1 into a separate object and stores it in b. Since a[0] and b[0] are going to be different objects, the check is going to fail. Same logic applies when comparing a[1] and b[1].
However, it gets interesting. If you tried to do a similar thing in VB.NET, the output would be different.
So with a code like this…
Dim a as new ArrayList() Dim b as new ArrayList() a.Add(1) b.Add(1) a.Add(2) b.Add(2.0) Console.WriteLine(a(0) = b(0)) Console.WriteLine(a(1) = b(1))
The output is going to be…
True
True
Surprised Well, VB.NET compiler translates the equality check (”=”) to a call to a helper function part of VB.NET runtime which would cast the left and right hand sides appropriately before comparison. In the first case, it would compare the two objects as integers, while in the second case it would compare the two objects as doubles after converting the integer on left hand side to a double.
That’s why we have generics - no surprises like these…
What you should do…
I am fortunate enough to work with a couple of great individuals. Recently I was able to hypnotize persuade them into discussing things which should and shouldn’t be done in a software project
I am absolutely sure that the discussion will help me in the future (and them). However I thought the merged list is generic enough to help anyone, and hence this post.
In the beginning…
- Before you start on a project, follow up with your managers and ensure that a detailed feasibility analysis has been done. This should include business planning, market analysis, and of course technology investigation to identify major road-blocks that are likely to be encountered in the future. For the technical analysis, you must involve the person who is going to actually write most of the code later on – because he’s the only one who’s most likely to consider all the possible issues.
- Involve engineers during requirement gathering phase. If possible, ask each of them to take a good look at a system of other competitors and report back with their findings. This will help the Product Manager in that there’s a better guarantee of the surface area of features being covered. The other bigger benefit is that the engineers would have a much clearer idea of the sort of product they’re supposed to build without having to read hundreds of pages in the requirements documents. This will also make them, I believe, more receptive to changes made in the requirements later on as they’ll have a better picture of the landscape. Being receptive to changes is very important.
- Identify major fears and unknowns that can negatively affect the outcome of a project. Make a proactive effort to address them at the start of the project.
- Make responsibilities of all individuals involved in the project clear for accountability. Assign roles to them appropriately.
- There should be a designated Project Manager whose role should be to maintain timelines, and escalate issues up to and from senior management. Asking a person in another role to also perform as a PM might not be effective always.
Day to day…
- Obtain sign-off for technical decisions and have a general plan for proceeding if a sign-off is not made within a specific amount of time.
- Daily standup meetings help a lot in keeping every one up to date on status and outstanding issues. There’s a lot to be learned from body language which might otherwise be lost in other forms of communication. However it is important to keep the meetings short – 10 to 15 minutes. There’s lots of literature about how the meetings should and shouldn’t be done. I’ll just say that you need to try out different things and pick the one which works best with the personalities of the individuals in the team.
In the meetings…
- Long weekly meetings drain the energy out of people and consequently the project. While I have my doubts on whether people pay attention after 45 minutes on average, I have even stronger doubts on the effectiveness of the meetings that go on for more than 2 hours. There might be exceptions of course, and I’d be interested in knowing what they did differently.
- After the weekly meeting, ensure that the meeting minutes are sent out describing each item discussed in the agenda along with the decisions made, open issues, and action items (assigning a person responsible).
- Be on time in meetings. Try to attend the meetings physically instead of over phone.
- Try to avoid taking calls on your cell phones during meetings – especially when you are actively involved in a discussion.
- Making decisions based on consensus is not always effective. Making decisions without considering inputs from others is equally bad.
When conducting code / design / UI reviews…
- If the process is to do design / code reviews in the meetings, to make the review more effective, try to restrict the number of attendees to the minimum absolutely necessary. Assigning reviewers to subsystems, if possible, might help in this regard.
- When performing a code review ensure that you enforce the positive aspects of the code, while identifying the aspects that need improvement. Too many details are bad; only give as many specifics as you think are needed to send the developer whose code is being reviewed forward in the right direction. When performing a review, pay attention and make an honest effort to understand the problem being posed to you.
When your code / design / UI is being reviewed by someone…
- When asking someone for a code / design review, make a dedicated effort to get their feedback. This might require you to spend an hour preparing a sample application to demonstrate the problem, but the time spent in it would be worth the effort. Be open to feedback. Negative feedback is still better than no feedback at all.
In general…
- Do not shoot down ideas point blank. This erodes the enthusiasm of the contributors which is very difficult to get back. Make sure you identify the positive aspects of every idea.
- Do not be afraid to hire temporary contractors and subject matter experts if required. That’s why a feasibility analysis is important.
- When involving new people in a project, ensure that they have received adequate training on other internal products and frameworks as required.
- If you’re required to use a common piece of code, ensure that it has an adequate test-bed. Secondly, push for dedicating engineering resources for their maintenance, depending of course on the size of the common code. If there aren’t any developers accountable for the upkeep of the common piece of code, you’re likely to lose the confidence of the developers who’re supposed to use it.
But most importantly…
- Work to a level where you can be proud of your contributions tomorrow. In the end, that’s all that matters.
Two (useless but potentially) interesting tid-bits
Try-Catch-Finally
A try-catch-finally is converted into IL by the C# compiler as a try-catch inside the try block of another try-finally. This allows for finally block to execute even when exceptions are raised in the catch block. Use ildasm and check it out yourself!
throw football;
Though you cannot throw an arbitrary managed object as “throw myObj” (you’ll get a compilation error), you can modify the generated IL to do so. However your catch block will actually receive a RuntimeWrappedException in these scenarios. Why is this allowed? Well, unlike C#, it is legal to throw arbitrary objects in managed C++ and in those cases a RuntimeWrappedException is thrown too.
C# compiler optimizations and empty “try” block
There is some misinformation you’re likely to stumble upon via Google when searching for “C# compiler /optimize+”. Interestingly, the following snippet can be seen on various forums.
The following is a response from a developer on the C# compiler team: We get rid of unused locals (i.e., locals that are never read, even if assigned). We get rid of unreachable code. We get rid of try-catch with an empty try. We get rid of try-finally with an empty try. We get rid of try-finally with an empty finally. We optimize branches over branches: gotoif A, lab1 goto lab2: lab1: turns into: gotoif !A, lab2 lab1: We optimize branches to ret, branches to next instruction, and branches to branches.
The part in bold is incorrect.
Before I dive into a simple app that I wrote to prove that the information is incorrect, there’s a simple logical reasoning to refute the claim. Basically, a function that has had a try/finally block completely removed because of an empty try or finally will behave completely differently than one who hasn’t. Optimizing something doesn’t mean you stop doing important things to save some time
“We get rid of try-finally with an empty try”. Do they really?
For those who still aren’t convinced with the explanation above, I wrote a simple C# class and saved it in a file Test.cs. I compiled the code once from the command line without optimizations (“csc test.cs”) and once with optimizations (“csc /optimize+ test.cs”).
Here’s what Foo looked like in C#:
private void Foo()
{
int x;
try
{
}
finally
{
DoSomething();
DoSomethingElse();
}
}
Nothing much there… Just an unused variable “x”, an empty try, and some code in the finally block.
Here’s the IL without optimizations:
.method private hidebysig static void Foo() cil managed
{
// Code size 22 (0x16)
.maxstack 0
.locals init (int32 V_0) // Here's our unused variable.
IL_0000: nop
.try
{
IL_0001: nop
IL_0002: nop
IL_0003: leave.s IL_0014
} // end .try
finally
{
IL_0005: nop
IL_0006: call void Test::DoSomething()
IL_000b: nop
IL_000c: call void Test::DoSomethingElse()
IL_0011: nop
IL_0012: nop
IL_0013: endfinally
} // end handler
IL_0014: nop
IL_0015: ret
} // end of method Test::Foo
Here’s the IL with optimizations:
.method private hidebysig static void Foo() cil managed
{
// Code size 14 (0xe)
.maxstack 0
.try
{
IL_0000: leave.s IL_000d
} // end .try
finally
{
IL_0002: call void Test::DoSomething()
IL_0007: call void Test::DoSomethingElse()
IL_000c: endfinally
} // end handler
IL_000d: ret
} // end of method Test::Foo
As you can see:
- The compiler got rid of the unused variable when optimizations were enabled
- Notice that the following declaration doesn’t appear in the second IL listing while it does in the first one:
.locals init (int32 V_0)
- Try / Finally is still there
If you’re still questioning why you would have a try/finally with an empty “try” in the first place, you might find an earlier article of mine interesting.
Hope this helps someone in an interview or something
Make a file empty
Found someone using Google to figure out how to clear out the contents of a file and hitting my blog. Well, it’s pretty easy - use FileMode.Truncate when opening the file.
using (FileStream fs = File.Open(filepath, FileMode.Truncate, FileAccess.Write))
{
// Code to write to the file goes here
fs.Close();
}
Which one is faster - FileStream.Position or FileStream.Seek?
FileStream.Position property is implemented in terms of File.Seek (essentially File.Seek(value, SeekOrigin.Begin)). Consequently setting the location of the virtual file-pointer by calling Seek directly instead of calling Position results in slightly faster execution speed. Seek is also better because it has more options.
Switch vs if-else-if
This is an academic question. Which one is better?
private string Foo(int value)
{
string result;
switch (value)
{
case 10:
result = "something 1";
break;
case 110:
result = "something 2";
break;
case 150:
result = "something 3";
break;
case 210:
result = "something 4";
break;
default:
result = string.Empty;
break;
}
return result;
}
or
private string Bar(int value)
{
string result;
if (value == 10)
result = "something 1";
else if (value == 110)
result = "something 2";
else if (value == 150)
result = "something 3";
else if (value == 210)
result = "something 4";
else
result = String.Empty;
return result;
}
Even though both Foo and Bar do the same thing, Foo is better performance wise.
The compiler converts Foo into IL which roughly achieves the same thing as the following pseudo-code.
if value < 110 then if value == 10 then result = "something 1" else goto default_case else if value == 110 then result = "something 2" else if value == 150 then result = "something 3" else if value == 210 then result = "something 4" else default_case: result = String.Empty end if
Foo when converted to IL splits the search space with 110 in the middle which reduces the number of comparisons needed. As a result Foo will be faster than Bar. However, I wouldn’t advise you to worry about performance at this scale. As I said in the beginning, this question was only academic
Switch is just If-Else-If
In an internal meeting of a bunch of developers at my current company, someone made the assertion that the Switch statement in C# (or Select Case in VB.NET) is just a compiler short-cut for writing a chain of If-Then-Else statements.
What do you think? Is that statement - true or false?
Take the following C# function for example:
public string DoSomething(char c)
{
switch (Char.ToLower(c))
{
case 'e':
case 'g':
case 'k':
return "something 1";
case 'a':
case 'd':
case 'h':
case 'r':
return "something 2";
case 'p':
case 'i':
case 'l':
return "something 3";
default:
return "something default";
}
}
One of the ways to deal with the switch statement is for the compiler to treat the above switch statement as a sequence of If-then-else clauses, like so:
char lowerC = Char.ToLower(c);
if (lowerC == 'e' || lowerC == 'g' || lowerC == 'k' )
return "something 1";
else if (lowerC == 'a' || lowerC == 'd' || lowerC == 'h' || lowerC == 'r' )
return "something 2";
else if (lowerC == 'p' || lowerC == 'i' || lowerC == 'l' )
return "something 3";
else
return "something default";
But, if you think about it, there’s a better way…
One can do better by having a lookup table to map each character that you can possibly see, to the address of the corresponding instruction which should be executed when that character is seen. With a lookup table like that, when you see ‘p’ for example, there’s no need to compare it against ‘e’, ‘g’, ‘k’… and all the other characters in the cases that preceded it in the switch statement. As a result, your code will be faster.
There’s a “switch” statement at the IL level which implements the jump-table concept. The generated IL for DoSomething looks like the following:
.method public hidebysig instance string
DoSomething(char c) cil managed
{
// Code size 125 (0x7d)
.maxstack 2
.locals init ([0] string CS$1$0000,
[1] char CS$4$0001)
IL_0000: nop
IL_0001: ldarg.1
IL_0002: call char [mscorlib]System.Char::ToLower(char)
IL_0007: stloc.1
IL_0008: ldloc.1
IL_0009: ldc.i4.s 97
IL_000b: sub
IL_000c: switch (
IL_0063,
IL_0073,
IL_0073,
IL_0063,
IL_005b,
IL_0073,
IL_005b,
IL_0063,
IL_006b,
IL_0073,
IL_005b,
IL_006b,
IL_0073,
IL_0073,
IL_0073,
IL_006b,
IL_0073,
IL_0063)
IL_0059: br.s IL_0073
IL_005b: ldstr "something 1"
IL_0060: stloc.0
IL_0061: br.s IL_007b
IL_0063: ldstr "something 2"
IL_0068: stloc.0
IL_0069: br.s IL_007b
IL_006b: ldstr "something 3"
IL_0070: stloc.0
IL_0071: br.s IL_007b
IL_0073: ldstr "something default"
IL_0078: stloc.0
IL_0079: br.s IL_007b
IL_007b: ldloc.0
IL_007c: ret
}
Here’s what the compiler generated code to do:
- The ordinal value of ‘a’ (i.e. 97) is subtracted from the character passed to the function.
- As a result for characters between ‘a’ and ‘r’, you’d see values between 0 and 17 (both included).
- For each value between 0 and 17, the compiler then specified the label of the instruction that the execution should jump to, in the IL switch statement.
- Notice IL_0059: if the value does not lie between 0 and 17, code has been generated to directly jump execution to IL_0073 and we get ready to return “something default”.
Sweet, isn’t it?
Does the compiler always handle “switch” this way?
Nope. If the range of the values specified in the case clauses is large, creating a table as explained previously, will cause wastage of memory. So a function like the following won’t be utilizing the IL “switch” statement and will be treated like a sequence of “if-then-else” statements. However, for efficiency, the order of comparisons might be different from the order in which “case” clauses were specified in your code (more info).
public string DoSomethingElse(int bla)
{
switch (bla)
{
case 10:
case 45:
case 99:
return "something 1";
case 21:
case 1091:
return "something 2";
case 2048:
case 256:
case 1072:
return "something 3";
default:
return "something default";
}
}
Here’s a link to an article that presents some findings from comparing execution speed of “switch” against “if-else-if”. But like I said earlier, this qualifies as micro-optimization and there’re most probably other things in your code you should be worrying about.
