New Things I Learned

Connect to VMWare virtual machines using Remote Desktop

Muljadi Budiman — Fri, 13 Nov 2009 20:42:41 GMT

Had a short training on VMWare on Tuesday, the software development department finally got the official permission (read: get a license) to use VMWare Workstation. I’m no stranger to Virtual Machines (VMs) – started playing with Virtual PC 2005 a fwe years back and I understood the general concepts of hardware virtualization. The biggest problem I have with VMs in general is the slowness; I’d rather develop directly on my PC, which is faster. Can’t say I’ve delved deep into it, but I know enough to utilize it and be dangerous .

Regardless, virtual machines provide a way to simulate multiple computers and I’ve done 3-tier software testing (client to app server using WCF and app server to SQL 2005 backend) to verify our framework can support both 2-tier (client –> DB) and 3-tier deployments. Rarely used it for development, again due to speed.

Fast forward to the current time, I’d like to be able to do some coding on Windows 7; unfortunately Windows 7 is not quite sanctioned yet to be deployed, and it’s a pain to have to dual-boot. I do have Windows 7 at home, but got way too many experimental stuff on it . So, I’m setting up a Windows 7 VM so I can do some coding on it.

Now, nothing wrong with running the VM within VMWare, but I always find that it is a bit sluggish unless I go to full screen mode. If I do so, it’s a bit of a pain to go back and forth between the host and the VM, and it also means that I have to do it at the host. Ideally, I’d like to remote desktop into it (for whatever reason, I also feel remoting into a VM session makes for a snappier UI response).

However, this is not immediately possible to do without some setup; out of the box VMWare provides VNC connectivity, so you can use that but I am spoiled by remote desktop – it is just way nicer than VNC. Of course one of the advantages of VNC is that if someone connects to it, the original don’t lose the view of the PC, so different tools for a different job.

In any case, I’d like to be able to remote desktop into my VMs – there are 2 ways to set this up, one is faster but it is considered as ‘nice’ and may cause problems with typical corporate network setups. Let’s look at the first approach:

The first approach is to set up the VM setting to have it’s network adapter be a Bridged connection. This basically sets the VM to use the host’s network card as if it were its own network card. This also means that the VM will get an IP based on the host network’s settings (usually DHCP-based). Essentially it brings the network connectivity of the VM to be at the same level as the host. Now, in a corporate environment (usually domain-based), this may not be allowed, or you may have trouble with accessing the network at all if your VM is not added to the domain. On a local (home) network, it also means it can communicate with other computers on the same network (good), but if it gets infected with a worm / virus it can also spread to the other computers (bad).

Depending on your environment, bridging may be fine and if you can do that then by setting it to Bridged mode you can then remote desktop to the VM (you have to remember to turn it on within the VM).

However, in my current situation, setting a VM network in bridged mode is not condoned and we have to set it to NAT setup. Each VM that you spun will then get a typical internal IP address (192.168.XXX.XXX); but that means you cannot get to it from the outside. So what to do? The answer was provided in this post by rsa911– I’m just providing the nice UI snapshots (and also as a reminder for me on how I got it to work in the future).

In NAT mode, each VM is given an internal IP address and VMWare essentially becomes the bridge between the host and the VMs that runs in it. Fortunately, you can do port forwarding to these internal IP address. As detailed here, Remote Desktop uses port 3389 to listen to incoming RDP requests. So what we need to do is forward an unused port to each VM’s port 3389 and we should be able to remote into them. Let’s see how that’s done.

To do port forwarding, we need to access the Virtual Network Editor from VMWare Workstation (under the Edit Menu –> Virtual Network Editor). The dialog above should show up – select the network adapter that is set to NAT. Then click on the ‘NAT Settings…’ button, the following dialog will show up:

Click on the ‘Add’ button, and a dialog to map incoming port shows up; the dialog below is filled with the following information:

Listen to port 9997
Any TCP communication to that port, forward it to the VM with IP of 192.168.118.130 on port 3389 (default RDP port)

Tweak it to satisfy your setup – the host port just needs to be an unused port (in this example I use 9997), the VM port needs to be 3389 (unless you’ve changed it) and the VM IP address needs to be the IP address assigned to the VM you’re running (in Command Prompt run ipconfig to easily see this); this is what my output looks like:

When done, click OK and the NAT Settings dialog will show up your port forward:

So now I’ve set up VMWare so any incoming request to port 9997 will be forwarded to port 3389 on the VM that has IP of 192.168.118.130. Remember that for Remote Desktop to work, you still need to make sure your VM has RDP enabled and you have users with passwords added as Remote Users.

The question is then how do you issue the remote desktop request? Well, you use the host’s IP (or machine name) as the target, but you provide the port number as well:

The VMWare is hosted in my laptop (mbudimane6500) and I’m providing the port RDP should use (9997). Remember that in a domain environment it’ll try to login as a domain user (DOMAIN_NAME\username format), so if your VM machine is not part of a domain you have to change the username to use to log in.

If you’ve done everything as mentioned above, now you can remote desktop into your VM machines in a NAT environment . Remember also that you have to do the port forward for every VM that you wanted to remote into – each one will have a different IP address and each one will need to have a different port number. Hope this helps others.

Make SQLExpress DB accessible from other computers

Muljadi Budiman — Wed, 11 Nov 2009 16:08:57 GMT

When I started using SQLExpress 2005, everything works on my development machine – however when I wanted to access the database from another machine (trying to access the sqlexpress database remotely) I was not successful. I discovered the solution way back then, also through Google searches, which still yield a valid result. However, every now and then my peers would ask me this same question again.

Thus I’m creating this blog so I can forward them to this page (instead of talking about it); it’ll also remind me of how to do it if my memory starts to fail me.

By default, SQLExpress installations does not allow remote connections, so we need to change that first. To change it, you have to run the SQL Server Surface Area Configuration tool – as the name vaguely implied, this tool will allow you to configure SQL Server’s Surface (what gets exposed). This tool is installed with your SQL installation (express or not); it should be located in the Microsoft SQL Server 2005 / 2008 program group, under the Configuration Tools subgroup.

When you run this, the following dialog appears:

Select the ‘Surface Area Configuration for Services and Connections’ (as circled above). The next dialog should appear:

Select the Remote Connections node on the tree view (as circled above); the dialog changes to the following:

As you can see, SQL Express by default does not allow remote connections (the text above it also enforces that); so we’d like to change that – select the ‘Local and remote connections’ radio button, depending on your needs you choose to use TCP/IP or named pipes or both, then click the ‘Apply’ button – an alert should show up telling you that the settings will not take effect until the database engine is restarted, we’ll do this last.

We’re not finished yet; what happens right now is that the system is set up to allow remote connections. However, there’s another piece of service that needs to be up before we can connect to it remotely. That service is the SQL Server Browser service. Select the SQL Server Browser node on the left tree view, and the dialog will change to show the following:

Again, by default the SQLBrowser service is disabled, so let’s change that to Manual, click ‘Apply’ (which will enable the ‘Start’ button) then click the ‘Start’ button, which will start the service. OK, we’re almost finished; the last step is to restart the SQL Server service itself, so let’s click on the Service node under the SQLEXPRESS and Database Engine node in the tree view. The dialog will change to the following:

Click ‘Stop’ and then wait for the service stoppage to complete, then click ‘Start’ again. You should be able to connect to your SQLExpress instance from another computer (if it’s the default instance, you would use computername\SQLEXPRESS as the server name). Good luck!

Putting pictures in Windows Live Writer in their original size

Muljadi Budiman — Fri, 06 Nov 2009 21:31:34 GMT

I guess I’m one of those people who rarely reads manual, and outside of technical documentation, I rarely read an application’s user manual. So I’m using Windows Live Writer, and I’m trying to embed a picture in my draft blog post. Well, whenever I do that, the picture always come in scaled down (if it’s even a tad large, like 300 pixels wide), like the picture below:

Well, obviously with technical and text-heavy images, scaling down is bad (can’t read much). I can go to the HTML source, but I can’t seem to rescale the image, even when I took out the width and height property. Pretty weird. So how do I scale it? Clicking on the image in Live Writer shows me the following information on the right-hand pane:

First off pictures that are inserted into Live Writer automatically gets treated as a clickable link. If it’s a regular (non-text) picture, most probably that’s desirable; however in most of my cases, I’d like to put in the actual picture itself and don’t want to make it clickable. So make sure you set the bottom-most combobox (the one under the heading Link to) to None.

On the top side of this info pane, there are 3 tabs; select the ‘Advanced’ tab and the information displayed changes to:

The combobox under the Size heading will also list the original size; select that and your picture now gets shown in its original size. I’m happy ()to have found this since in some of my past blog posts I actually had to set the width/height of the picture manually in the HTML.

Also, with geekswithblogs, to set the tags to associate with your blog post, the bottom part of Live Writer has this ‘Set categories’ combobox – click on it and it’ll show you the tags that you’ve defined in your blog:

My Coding Helpers: Verify exception thrown in Unit Test

Muljadi Budiman — Thu, 05 Nov 2009 21:22:35 GMT

Every now and then, I end up writing and re-writing the same code (or very, very similar) to achieve a functionality that I’ve had before. Sometimes I can remember where I wrote it, so I can just copy and paste. At other times, I have to redo it again since I forgot where it was. So I’d like to put it up on my blog so I have access to it. If anyone else gets to see it and can use it, so much the better for everyone. Of course, I’d also accept criticism to the code too .

So, this is my first one; because I’ve used it for awhile and I ended up having to rewrite it yet again today for a pet project that I have. Now, I understand not everyone likes to do Unit Testing, but I enjoy it every now and then. It is somewhat boring & tedious, but it also gives me some relaxation since I can do very, very simple code and don’t have to think too much – unit test code should not be very complex. In most unit tests, the code will try to go through the path of the tested code and usually try to handle the happy path. I don’t do pure Test Driven Development, but I understood some benefit of what TDD can do.

One advantage of doing TDD is that you will end up also writing tests (and code) that will verify arguments. And since your code has argument checks, then your unit tests also have to verify both success and failure cases of those arguments. Consider the following very simple code:

public class SomeClass
{
   public double SR(double d)
   {
      return Math.Sqrt(d);
   }
}

Essentially you just wanted a wrapper method, instead of calling the function Math.Sqrt() all the time; simple enough. But let’s say that you also wanted to change the default behavior; such that the consuming code should never ever actually call this method with a negative number. If it is a negative number, then you wanted to throw an exception. Easy enough to do…

public double SR(double d)
{
   if (d < 0)
      throw new ArgumentException("Argument can't be negative!");

   return Math.Sqrt(d);
}

As you can see from the code above, the code is still trivial. Of course, now you want to write a unit test for it; there are 2 unit tests you have to create: the successful case and the failure case. So let’s see what the unit tests would look like the following (I’m using Visual Studio’s unit testing framework):

[TestMethod]
public void SRTest_Success()
{
   SomeClass sc = new SomeClass();
   Assert.AreEqual(sc.SR(100), 10.0);
}

[TestMethod]
public void SRTest_Failure()
{
   SomeClass sc = new SomeClass();
   try
   {
      sc.SR(-100);
      Assert.Fail();
   }
   catch (ArgumentException)
   {
   }
}

Again, simple, very trivial methods – however the failure case is rather verbose; you have to create a try-catch block (an empty catch at that too), so another way to do it is to use the ExpectedExceptionAttribute.

[TestMethod]
[ExpectedException(typeof(ArgumentException))]
public void SRTest_Failure()
{
   SomeClass sc = new SomeClass();
   sc.SR(-100);
}

The problem with the above approach is that if you want to be able to catch multiple exceptions (not recommended in creating unit tests, but some people may want to cut corners ), you can’t do it – you can’t apply multiple ExpectedException attributes. Another problem is if your unit test code is rather large, it may have other code paths where there’s an actual failure that will throw an ArgumentException which will pass the test happily but will result in a false positive.

So, I needed a way to be able to catch exceptions in the code itself, but I don’t want to write try-catch blocks all over the place. So I came up with the following helper method to help me verify exceptions are thrown:

public class UnitTestHelper
{
   // Method accepts an action delegate, and a generic Exception type
   public static void VerifyExceptionThrown<TException>(Action action)
      where TException : Exception
   {
      // Verify arguments - action can't be null
      if (action == null)
         throw new ArgumentException("Action to test cannot be null!");

      // Verify arguments - TException cannot be of type Exception
      if (typeof(TException).Equals(typeof(Exception)))
         throw new ArgumentException("TException type cannot be of type Exception");

      // Actually call it
      try
      {
         action();
      }
      catch (TException)
      {
         return;
      }

      // If it gets here, fail the test
      Assert.Fail("Action does not throw the exception expected");
   }
}

The code above is fairly simple; the helper method accepts an Action delegate as a parameter and a generic TException type to be passed and I put in a constraint that has to derive from Exception class. To also be nice and proper, the method also checks its parameters: the action parameter can’t be null, and the generic TException type cannot be of type Exception itself (because it’ll catch all exceptions, which won’t prove/disprove the unit test itself, but modify it as you want). At the end, it’ll fail the unit test, since it should never hit the Assert.Fail method call.

The unit test will look like the following:

[TestMethod]
public void SRTest_Failure()
{
   SomeClass sc = new SomeClass();
   UnitTestHelper.VerifyExceptionThrown<ArgumentException>(() => sc.SR(-100));
}

[TestMethod]
public void SRTest_Failure_AnonymousDelegate()
{
   SomeClass sc = new SomeClass();
   UnitTestHelper.VerifyExceptionThrown<ArgumentException>(delegate() { sc.SR(-100); });
}

I put in 2 methods – the first one uses Lambda Expressions, which may not be used by those that are still using strictly .NET 2.0 framework only, so the second one demonstrates the same call but using anonymous methods. If you’re strictly using .NET 2.0, the Action delegate is not available in the .NET Framework – you have to create your own.

After understanding simple Lambda Expressions, personally for me, the unit test code is more readable, since I don’t need to look at any attributes, and the unit test code can contain further verification of exceptions thrown and also it can have further asserts.

For completeness, the code below is the unit test that tests the VerifyExceptionThrown method. The code demonstrates the ‘eating your own dog food’ mentality: I get to use the method that I’m unit testing itself.

[TestMethod]
public void VerifyExceptionThrown_TestFailure_InvalidExceptionType()
{
   UnitTestHelper.VerifyExceptionThrown<ArgumentException>(() =>
      UnitTestHelper.VerifyExceptionThrown<Exception>(() => { }));
}

[TestMethod]
public void VerifyExceptionThrown_TestFailure_NullAction()
{
   UnitTestHelper.VerifyExceptionThrown<ArgumentException>(() =>
      UnitTestHelper.VerifyExceptionThrown<DivideByZeroException>(null));
}

[TestMethod]
public void VerifyExceptionThrown_TestFailure_ExceptionNotThrown()
{
   UnitTestHelper.VerifyExceptionThrown<AssertFailedException>(() =>
      UnitTestHelper.VerifyExceptionThrown<DivideByZeroException>(() => Debug.Assert(true)));
}

[TestMethod]
public void VerifyExceptionThrown_TestSuccess_DivideByZeroException()
{
   int i = 0;
   UnitTestHelper.VerifyExceptionThrown<DivideByZeroException>(() => i = 5 / i);
}

Coders 4 Charities: Epilogue

Muljadi Budiman — Wed, 21 Oct 2009 20:01:51 GMT

I was involved in the St. Louis Coders 4 Charities event this past weekend; I was part of the TURNERS team that is responsible with helping the Turning Point agency (Warren County Council Against Domestic Violence) create a website. You see, out of the 9 charitable organizations in C4C’s list, Turning Point was the only one that did not have a website.

It was an interesting project, and it allowed me to learn quite a bit of stuff. We recommended Webhost4life to be their webhost provider, asked them to register a domain name of their preference (www.turningpointdvs.com) , and we decided to use SiteFinity as the CMS for their site. All these legwork were done before the starting time on Friday, October 16th.

On the day of the event, we had a great turnout: over 50 volunteers showed up on that first night, of various expertises and skill levels. Kevin Grossnicklaus gave an opening statement and then teams were introduced and proceeded to get together with the agency’s contact person to discuss about the project to be done.

Assembla.com was gracious enough to donate to C4C a web workspace, which allows for bug tracking, source control (SubVersion using Tortoise and VisualSVN), team membership registration and file sharing of project assets. Most of Friday was used for familiarizing ourselves with the tools available and digging a bit deeper into the requirements side that each project needed.

My team had these great individuals as members:

It was a great experience for me altogether; it was amazing to see these volunteers (mostly developers, but we also have Project Managers, Testers, Graphics Artists, etc.) work until very late night, all for these charity organizations, with no rewards whatsoever. It is very, very eye-opening. We closed up on Friday around midnight, opened up again on Saturday from 7:30 AM, again all the way to around 11:30 PM.

We had a closing show-and-tell session on 5 PM Sunday; all of the projects are considered done in principal: some needed to still be uploaded to the webhost, some needed a bit of polish here and there, but the main requests of the project are done. The place was closed around 7:30 PM and everyone went home tired, but elated – it was also evident that people needed a good night’s sleep afterwards.

It was a great event, it benefitted quite a bit of the Greater St. Louis charity organizations, and I am overwhelmed by the outpouring of support from the St. Louis IT community. I’m sure we’ll have another one next year, so hopefully it’ll be even bigger and better than this time around .

Pictures of the event can be found here. I still need to upload my pics, but I’ll add it to the pool.

Coders 4 Charities – St. Louis: October 16th - 18th

Muljadi Budiman — Fri, 02 Oct 2009 16:15:59 GMT

Kansas City held this great event where developers volunteer their time to fulfill the IT needs of charitable organizations back in April 2008. The event was called Coders 4 Charities and it was a great success. It was then made into an annual event, with their last one held last April.

Kevin Grossnicklaus heard about this and he worked with other community leaders in organizing a similar event to be held in St. Louis, thus C4C – St. Louis is born. I volunteered to be part of this great community effort.

C4C – St. Louis is still looking for a few more additional volunteers, the more the merrier, right? If you’re interested in volunteering some of your time and technological skills & knowledge to help a local charitable organization, please go to the website and register. In fact, they’re also currently looking for a couple more people to step up and assume a Team Lead role. There’s also a FAQ page if you have any questions.

Washington University’s Center for the Application of Information Technology (CAIT) has graciously provided the venue for this event; they’re located here. The event will start on late Friday afternoon on October 16th and will continue until the evening of October 18th; food, soda and coffee will be provided throughout the effort. More information can be read at the C4C – St. Louis website.

I look forward to meet other volunteers at this charitable event.

Covariance in .NET 4.0

Muljadi Budiman — Wed, 30 Sep 2009 19:45:10 GMT

On Monday I presented at the St. Louis .NET User Group, and the topic was ‘What’s new in VS2010 and .NET 4.0 Framework’. Within the whirlwind look at all the new and cool stuff coming in the near future, the subject of Covariance and Contravariance support was discussed. Given the time constraint I only spent 3-4 minutes at it. I alluded to the group that the concept of Covariance/Contravariance is rather hard to understand, because it is not as intuitive as it could be; I just asked them to trust me that the support is there.

After the session, talking with some people, apparently the concept is REALLY hard to understand; and in hindsight I should’ve known this too. It took me a good 3-4 hours of fiddling around and research to get the concept embedded in my head so it will take others the same amount of time to understand it too.

Given that the concept is rather hard, I thought I should blog about it so I don’t forget it in the future . In this post, I’ll talk about Covariance only and I’ll post about Contravariance in the future.

Let’s start at the very, very basic level: the word itself. Variance. From this article on Wikipedia, I managed to synthesize that the word variance means ‘conversion of types’. Covariance is the conversion of a type from more specific to more general. Contravariance denotes the reverse: conversion of a type from more general to more specific.

Let’s do a simple case:

private void Test()
{
   string str = "Test";
   ProcessObject(str);
}

private void ProcessObject(object obj)
{
   // Some code...
}

In the code above we have a simple case where the consuming code declares a string, and then passes the string into a method that accepts an object. That is Covariance in action: conversion of a type from a more specific one to a more general one (string to object). Of course, the term doesn’t pop into mind; as developers we just see that the operation is valid since we’re passing a variable to a method that can accept the base type. So, to go 1 step further, the following is also valid:

public class Base
{
}

public class Derived : Base
{
}

private void Test2()
{
   Derived d = new Derived();
   ProcessBase(d);
}

private void ProcessBase(Base b)
{
   // Some code...
}

As you can see, this is simple OOP in action; we’re passing an instance of the Derived class (a more specific type) to a method that can accept the Base class (a more general type). Everything is logical, and makes sense. Covariance in action.

So let’s push further 1 more step; we’re going to do covariance (conversion of type from more specific to more general), but without methods this time.

private void Test3()
{
   string[] strs = new string[5];
   object[] objs = strs;

   objs[0] = "Test";
   objs[1] = 7;  // This will crash the application
}

In the above code, this conversion of arrays is fully legal; however the last line will cause the program to crash. The array conversion from string[] to object[] is not very common, but it does work. However, since you can also use the array to assign values, this conversion is considered to be an unsafe covariance, since it will only work for valid assignment, but it cannot be checked at compile-time.

So, let’s take it 1 step further again:

private void Test4()
{
   List<string> strs = new List<string>();
   List<object> objs = strs;  // Why not?

   // To prevent the following code:
   objs.Add(5);
}

The above code won’t compile, the second line ( List<object> objs = strs; ) will fail with the error that it cannot implicitly convert List<string> to List<object> – it’s how it has been in .NET. The initial question is why is this not allowed? It’s because if we’re allowing the conversion, then the line afterwards (which is very illegal and we don’t want to have that kind of code ever) will crash the application definitely, and it’s not something that can be checked during compile-time. Very similar to the prior example, but developers will use generics more so than arrays, thus this is not allowed.

In both cases, the application will break because both constructs (array and List<T>) allows assigning of values into the container. But what if we don’t allow assigning values? Let’s see if we can create such a scenario:

public interface IOutOnlyList<T>
{
   T this[int index] { get; }
}

public class NewList<T> : List<T>, IOutOnlyList<T>
{
}

private void Test5()
{
   IOutOnlyList<string> strs = new NewList<string>();
   IOutOnlyList<object> objs = strs;  // This should now be valid!

   // Can't assign to objs, can only get value out
   object temp = objs[0];
}

So we’re trying to create a construct just for our own use here: we have an interface (IOutOnlyList<T>) that provides a get-only indexer. We need to have this interface implemented, so we created the NewList<T> class which inherits from List<T> and also implements IOutOnlyList<T>. In the above code (which still won’t compile due to the assignment of strs to IOutOnlyList<object>), we’re showing that with the IOutOnlyList<T> interface, the code cannot make changes to the container; as such it should be legal. There’s no way to write code to break the application now that’s not detectable at compile time.

That’s exactly the argument as to why this type of covariance should be allowed. In .NET 4.0, this is now possible:

If the construct only allows getting the values out only
And the construct does not allow changing the values contained within

The code above will be legal in .NET 4.0, with the following minor change:

public interface IOutOnlyList<out T>
{
   T this[int index] { get; }
}

The change is in the signature of the generic type T, we provide an out keyword. That out keyword tells the compiler that the interface (or class) will only use the generic type T as output, but never as input. This allows the compiler to verify that the interface is indeed conforming to that specification (T is never used as input) and it will then allow covariance for IOutOnlyList<T> from a more specific type (string) to a more generic type (object).

The example so far is for our own interfaces; to allow covariance .NET 4.0 changes the following constructs (by using the out keyword):

IEnumerable<T>
IEnumerator<T>
IQueryable<T>
IGrouping<TKey, TElement> (Covariant for TKey)
Converter delegate (Covariant for the output, Contravariant for the input)
Func delegates from the System namespace (Covariant for the output types only)

Because of these changes, the code below will now work; you can assign variables of type IEnumerable<string> to type IEnumerable<object>. Since the conversion works, you can also use this to pass in parameters into methods as well.

private void Test6()
{
   IEnumerable<string> strs = new List<string>();
   IEnumerable<object> objs = strs;  // IEnumerable can't change values contained

   ProcessObjects(strs);
}

private void ProcessObjects(IEnumerable<object> objs)
{
   // Do something with objs
}

That’s the idea of Covariance in .NET 4.0 and how it is used. Contravariance is the reverse of Covariance, but the explanation takes a bit longer…

Presenting for the St. Louis .NET User Group – What’s new in VS2010 and .NET 4.0

Muljadi Budiman — Tue, 29 Sep 2009 21:53:51 GMT

Last night I had the pleasure of presenting a session on ‘What’s new in VS2010 and .NET 4.0’ for the St. Louis .NET User Group. Got to meet with lots of people there, so greets go to all . I had fun with the session; I liked talking about new technology and it’s pretty neat to see everyone and just mingle around with people in general. Pizza was great (thanks to last night’s sponsor: Quilogy) – I have to also thank Scott Spradlin for allowing me to present to the group.

The session itself has the same presentation slide as my .NET 4.0 session which I presented in St. Louis Day of .NET, which I’ve made available as detailed in this post. I did make a project that tries to also demonstrate some of the new constructs, which I didn’t have time to do when I first presented it. So here it is. It is a simple WinForms application, with 6 buttons, each of which demonstrates:

Using the dynamic keyword to invoke a method, and also to provide a generic Add method which accepts 2 dynamic parameters
Demonstrates support for consuming COM-Interop methods (opening up a Word document). An MSDN howto article on this is available here.
Using the BigInteger structure
Using the Tuples constructs
Demonstrate ConcurrentLinkedList<T> (thread-safe collections are in the System.Collections.Concurrent namespace)
Demonstrate the use of FileDialogCustomPlace to add application-specific one-click shortcuts
It also has other files that demonstrates other features; the variance.cs file contains constructs that shows Covariance and Contravariance.

I hope this may be of use to others.

On a side note, based on the recommendation of speakers at the St. Louis Day of .NET, I’ve created a Twitter account: mulbud. Hopefully I can contribute to Twitterverse in a positive way .

Linq == Deferred Execution == Always Re-execute

Muljadi Budiman — Wed, 23 Sep 2009 13:50:38 GMT

Got bit by a bug caused by me trying to do stuff smartly in Linq. Gentle reminder that Linq expressions are always recalculated. The bit of code is the following:

public static void AddKnownTypes(IEnumerable<Type> knownTypes)
{
   // We only want to collect types that are new (hasn't been registered yet)
   IEnumerable<Type> newTypes = knownTypes.Where(t => !_knownTypes.Contains(t));
   _knownTypes.AddRange(newTypes);

   // Fill in a dictionary of these newly added types
   foreach (Type type in newTypes)
   {
      _types[type.Name] = type;
   }
}

Looking at it, the code seems to be fairly benign; the method accepts a list of types, we only wanted the new ones, so filter using the Where extension method, and then add it to our list and also fill in a dictionary of types.

The bug with the above code is that the foreach body will not be entered (regardless of the types contained in knownTypes or _knownTypes).

In Linq, any queries have its execution deferred; in the case above, the newTypes variable actually has the expression as to what needs to be done. When calling AddRange, we pass in newTypes as the parameter, and the query is executed then and there.

However, in the foreach, newTypes is still the same expression, so when it gets to that foreach line, the expression is re-evaluated again. Guess what – at that point _knownTypes already contains all the types in newTypes , thus the query will return an empty set.

We always think of using a variable to store a value and that value doesn’t change (unless we change it or some other code change it). In this case, it’s actually like a delegate call, which will basically execute a method that will return the value. I’ll be sure to remember this so I don’t get bit by this again.

Edit:

My friend Kevin Grossnicklaus aptly pointed out that Linq operators fall into 2 groups, the ones that have deferred execution and the ones that are not. For instance Sum, Count and just about any of the Enumerable extension methods that return an actual concrete type (ToList and ToArray are 2 other examples) will actually execute the query then and there.

It's when the method returns an IEnumerable<T> then the query gets deferred; which can lead to some frustrating bugs. I'll illustrate some of these bugs in future post .

Methods parameters and return values, what types to use?

Muljadi Budiman — Fri, 18 Sep 2009 19:03:34 GMT

I’m trying to be a better developer, so I try to make sure I follow best practices as much as I can. At times when I’m just creating simple methods though, every now and then I get somewhat hung up as to what do I use as types for my input parameters and return values. You see, it is something that is so basic, we create methods all the time, but most of the time, we don’t pay much attention to it since we’d just like to continue on with the task at hand. So I’m writing this to remind myself that writing methods, sometime is not as straightforward as it seems…

A colleague was code-reviewing some project files and noticed that we have a same-intentioned method (same name, similar code on what it does but somewhat different input & return values) in 3 different classes. Of course, the placement of the code itself is erroneous, but let’s attribute that to hectic development and developer’s unfamiliarity of existing classes / methods. So, this colleague would like to have only 1 of these methods, essentially combining them. This is what the method looks like:

public static Collection<Piece> GetMembers(EntityCollection<Piece> pieces)
{
   Collection<Piece> result = new Collection<Piece>();

   foreach (Piece piece in pieces)
   {
      if (piece.IsMembers)
      {
         result.Add(piece);
      }
   }

   return result;
}

Now, the method itself is fairly simple; it accepts an EntityCollection<Piece>, (which is a collection type that we have created for our purposes) and then gets all the entities that passes the IsMembers check. In the other 2 places, the method differs as follows:

public static Collection<object> GetMembers(Piece[] pieceList)
{
    Collection<object> result = new Collection<object>();
    // Same Code here...
}

public static List<Piece> GetMembers(EntityCollection<Piece> pieces)
{
   List<Piece> result = new List<Piece>();
   // Same Code here...
}

As you can see, the difference is in the return values and input parameter types. The code inside is almost identical. I can also relate with the developers that made these methods; when we create methods, we usually just take everything at face value. In most cases when the method was written, the developer has a need for it and the collection that is used by that particular is an EntityCollection, thus easily enough, the method created accepts an EntityCollection as well. All too often, this is how we write methods, in general, especially simple helper methods. Similarly, it just so happens, the consuming code at the time just needed a Collection<Piece>, so the method was created returning that same type.

Of course, looking at the above examples, this means the method is only useful if the particular input & output are that same exact type, thus from a junior developer’s perspective, it may seem to be fine to just create variants of this method; especially since .NET allows methods overloading. Keep in mind that in my scenario, these methods are not even in the same class! So the task now becomes, how can we collate all these into one nice method that can be reused? Hopefully it won’t get changed much (if at all) afterwards?

If you’re at all familiar with interfaces, after seeing these methods, the solution is very, very obvious. The solution should be something like the following:

public static IList<Piece> GetMembers(IEnumerable<Piece> pieces)
{
   Collection<Piece> result = new Collection<Piece>();

   foreach (Piece piece in pieces)
   {
      if (piece.IsMembers)
      {
         result.Add(piece);
      }
   }

   return result;
}

The input parameter is now of type IEnumerable<Piece> and the return value is of type IList<Piece>. It is very, very obvious; but how did we get here? By looking at the disparate methods in existence, we (somewhat intuitively) know that by using interfaces, we can condense the various methods into one. Careful readers would realize that it breaks consumers of the second variant, since the second variant returns a Collection<object> but returning that as a type is bad practice anyway since the object we’re processing will always be Piece.

The question then would be, how can we get to create this method without first going through the types of consumers that is going to call it? Over time, I created some generalization rules which in hindsight seem to work fairly well. The rules for types in methods are as follows:

Input parameters types should be of the most BASIC type that is needed by the code within the method; an interface whenever possible
Return values should be of the most ADVANCED type possible; an interface whenever possible.

The idea behind the 2 rules are fairly simple; in the example the method code only needs to go through each item in the passed in collection and as such IEnumerable<T> fits perfectly. The code would have worked with IList<T> or ICollection<T>, but since no other methods are needed from those interfaces, between the 3 candidates we’ll choose the most BASIC type. By using the most basic type, if a consumer happens to only have access to an IEnumerable<Piece> (maybe they get it from some LINQ manipulations) this method can still be called.

For the return value, the reasoning is a bit more complex: the method can just return a type of Collection<Piece> and that can be made to work with any consuming code. After all Collection<T> implements IList<T>, ICollection<T>, and IEnumerable<T> and their non-generic variants. However, if we choose to return an actual concrete type we may possibly have trouble in the future if we needed to return something else.

One recent example of changing return values that I had encountered was with the advent of WPF; WPF has great support for data binding – but to make sure 2-way data binding works entities have to implement INotifyPropertyChanged and collections have to implement INotifyCollectionChanged. So we ended up having to change most of our methods that returns a List<T> to return ObservableCollection<T>. The methods that returned List<T>, we have to change the consumer code to store the return value as IList<T> to make it work.

So that was one lesson that I took to heart, so I try to make public methods (and even private methods as much as possible) to have interfaces are turn values. I hope that answers the question as to why I chose to return an interface versus returning an actual concrete class.

The secondary explanation that is required then is why did I chose to use an IList<T>, rather than an IEnumerable<T>? With interfaces, I have the chose between IList<T>, ICollection<T>, and IEnumerable<T>. The rule I have is that return values should be of the most ADVANCED type as possible, so I chose IList<T>. Why? That’s because in the case we have here, the collection is generated and returned – it’s not being kept, it doesn’t affect any state and in essence the returned value can be used directly by the consuming code. With that in mind, having the most advanced type returned allows consumers to immediately use the return value. If the caller wanted to remove the last entry in the list, since we’re returning an IList<T>, the caller can do it using the returned value. If we had chosen to return an IEnumerable<T>, then the caller have to create its own list and then do the removal process. So the benefit is for the consuming code, since they can act on the return value better given the more advanced type being returned.

Following my generalized rules, if the Piece entity implements an interface (say IPiece), I would change the method to return IList<IPiece> and accepts IEnumerable<IPiece>. However, this usually means most of your code should operate on the IPiece interface and rarely do so on the actual concrete Piece class itself.

Every now and then when I create methods, I go through this same thought process. I hope to make this more seamless for me in the future, so I will automatically always generate methods that are easy to consume. Hopefully this can be of use to other people.