My Windows Live Messenger has been having troubles connecting to (whatever it connects to out there) every so often. It usually disconnects at night or over the weekend, and this is the third time in the last couple weeks I’ve come into the office and seen this… (see image below)

I had to click “Cancel” 32 times to get rid of this all of these windows. FAIL:(

I’ve been programming against the .net framework since the late beta of version 1.0 came out. (I had a couple year hiatus when I took a job doing some Linux & C++) however, suffice it to say, I’ve been using the language a long time. I still find it amazing that there are features in the language that have been a round a long time and still manage stumbling across things I’ve never seen before.

Today’s newly learned feature I saw in a blog by bogardj over at LostTechies where he wrote up a little Expressions Cheat Sheet.

In his blog, I notice the “checked” keyword had the blue syntax highlighting. (which usually means it’s a C# keyword)

So, to verify, I copied the word into my C# editor and what do you know… It is a C# keyword. This is probably something most if not all C# programmers out there already know and I, for some reason have missed this.

Here’s a blurb about it on the stack overflow “Hidden features of C#”.

And of course you can get the official details @ http://msdn.microsoft.com/en-us/library/74b4xzyw(VS.71).aspx

I decided to explore this a little. As an academic exercise I wanted to see what the difference would be between using the checked keyword with a cast operation and compare that to the System.Convert.ToByte operation.

Will generate the following error. System.OverflowException : Arithmetic operation resulted in an overflow.

While using the System.Convert class will generate a different error. System.OverflowException : Value was either too large or too small for an unsigned byte. 

And last experiment I threw both of the conversion attempts in a loop and fired up the ANTS Profiler which shows that using the built in checked keyword with a cast operation is faster than using the BCL conversion.

As to which one is better I would probably have to dig deeper into other side affects that one may have over the other… Up front I don’t see any issue with the cast and checked keyword combo.

I’ve pushed the Silverlight Unity/Moq AutoMocker into the moq-contrib project.

Well the other day I need the automocker and ended up running into a bug that was in my old-old-old pre-release version of moq for Silverlight, so I took the time to get the released version and re-compile the automocker.

I published it to the moq-contrib project. Haven’t taken the time to create a binary release, but should be able to get latest build, execute the build.Silverlight.cmd and in the drops\Current-Silverlight should be Moq.Contrib.UnityAutoMocker.Silverlight.dll

Enjoy!

A new version of StatLight has been released!

Major Features Added:

• NUnit support
  • Will work with any version of NUnit compiled to run under silverlight.
    • EX: Jeff Wilcox’s port
• Further MSTest support
• In the previous version (0.4) you could only use StatLight with the March 2009 build of Microsoft.Silverlight.Testing.dll. It will now work with any version.
  (Update: the Silverlight Asynchronous testing style is not currently supported)

Minor Tweaks:

• The debug.assertion creates a failure test event
  • It used to write a message to the console. It will now create a failure event, similar to a test that fails.
• Support for [Ignore]’d tests for each supported framework (MSTest, NUnit, Xunit)

Soon to come:

• Xml report file export
• Basic Cruise Control .net support

I took the new logo for StatLight and created a/an .ico (by going to convertico.com) for use as a FavIcon and so I could fancy up a couple of the windows just for fun. What I ended up figuring out, was how to change the icon for a running console window.

It’s actually pretty easy… Here is the class I wrote and use.

internal class ConsoleIconSwapper : IDisposable
{
    IntPtr consoleWindowHwnd;

    private const int WM_SETICON = 0x80;	// Api constant
    private const int ICON_SMALL = 0;	// Api constant

    [DllImport("user32.dll")]
    private static extern int SendMessage(IntPtr hwnd, int message, int wParam, IntPtr lParam);

    [DllImport("kernel32")]
    private static extern IntPtr GetConsoleWindow();

    public ConsoleIconSwapper()
    {
        consoleWindowHwnd = GetConsoleWindow();
    }

    public void ShowConsoleIcon(Icon icon)
    {
        SendMessage(consoleWindowHwnd, WM_SETICON, ICON_SMALL, icon.Handle);
    }

    public void ChangeIconback()
    {
        SendMessage(consoleWindowHwnd, WM_SETICON, ICON_SMALL, (IntPtr)0);
    }

    public void Dispose()
    {
        ChangeIconback();
    }
}

And here is how I use it.

using (var consoleIconSwapper = new ConsoleIconSwapper())
{
    consoleIconSwapper.ShowConsoleIcon(CoreResources.FavIcon);
    /*
     *  Code Here
     */
}

This is what it looks like when in use…

Before:


During:


After:

Amused by simple things :)

UPDATE: Microsoft’s acknowledged the bug…

We had a scenario (several weeks back) where a co-worker was connecting/changing connection between different sql servers and ended up in a state where the Microsoft SQL Server Management Studio said he was connected to one server however when executing queries it was connected to a different server.

This issue has been in the back of my mind ever since as a “what if this happens when connected to a production database and not my local dev box” issue. (WARNING: SERIOUS DATA CORRUPTION MAY OCCUR, when connected to the wrong server unknowingly)
NOTE: Luckily, we recently gave read-only rights to our dev AD user accounts so this situation couldn’t happen. I know, I know, “why didn’t we have that from the beginning?”……It happens, anyway…

Well, today I had the issue when working between my Dev box and our Test server and it took another developer (Thanks Keith Craig from Vertigo Software) to help me figure out the data I was looking at was not actually the data from the server I thought I was connected to.

Screenshot of the problem:

How to get into that state…

1. Start with a query connected to a remote database.
   NOTE: The two servers in red are the same. (Yay, we’re in a good state)
   
2. Click the “New Query” button to open a new query window.
   
3. Right click in the new empty query window, while it’s loading, and you (might) get the option to Connect. (if you’re fast enough)
   NOTE: This happens if you right click before the window finishes initializing it’s connection to the original server (in this case the remote database server). Usually this dialog gives you the “Change Connection” option when connected, but if you’re fast enough you can get the “Connect” option and the “Change Connection” will be disabled.
    
4. Click “Connect” and choose to the new desired server. In this case I’m going to connect to (local)
   
5. That’s it, I’m now connected to the original server FILES, even though it says I'm connected to the server entered in the dialog above (local).
     

Current Work Around to Avoid this Problem:

PATIENCE

To avoid the issue, wait till the query window has time to finish it’s initialization and has connect to the previous server. Then you can Right-Click –> Connection –> Change Connection…

Hope this helps someone else… because, like I stated earlier… (WARNING: SERIOUS DATA CORRUPTION MAY OCCUR, when connected to the wrong server unknowingly)

My company has been developing out parts of our website using Silverlight to enable some rich client LOB scenarios. Since the companies inception, we developed in a Scrum/Agile manner 3-6 week iterations. However, recently we started experimenting with a more “feature driven” attempt at “lean” approach.

With this new development approach, we made the decision that the trunk of the project’s source will be ready to deploy to production at all times. And as such would develop features out on branches. This is where the problem lies… We started running into a “Maximum file path length…” issue when branching the source. It’s a relatively old project (5 years or so now) with layers of projects/namespaces.

We traced the issue down to files generated by the Visual Studio’s Add Service Reference dialog.

In our case the generated files had the full namespace + service name which were, in some cases, greater than 90 characters long just for the file. Coupled with the fact they were already nested in a directory structure (that helped keep things organized). We ended bumping into the “Maximum file path length…” when trying to branch the project.

After researching a hunch I’d had

Most of those files generated by the tool are garbage and never used, so why does VS generate them, and have to check them into TFS?

Here’s a good post describing the meta data files.
http://www.scottseely.com/blog/09-01-26/Misunderstood_Add_Service_Reference.aspx

I found out that the only thing we cared about was the “References.cs” file in that whole batch of files.

Now, we would like to, and have thought about writing our own code in place of using the VS generated, (I know I’ve heard from the WCF pros at IDesign that you should never use the “Add Service Reference” generated stuff…) however it does what we need with the exception of the super long file names generated and…every time we update the service reference it keeps trying to add the ServiceReferences.ClientConfig back into the project. Since we are not using a config file to store the WCF connection information. We are following a similar path you can read about here (http://geekswithblogs.net/mwatson/archive/2009/02/24/129655.aspx) This way we don’t have to have separate configs for Dev/Test/Production.

The built in VS Service Reference tooling has become more of a hindrance to development than providing any benefit.

What is the solution we came up with to these two issues?

What were the problems again?

1. Files generated by “Add Service Reference” tools are too long for TFS (Not the fault of the tool, more the fault of the (TFS/.net api/win api) for not supporting longer file names…

2. Every time we update/add new service reference it tries to re-add the ServiceReferences.ClientConfig file (DON”T WANT THAT)

After about 1/2 a day looking for alternatives to using the built in tool, and since the wcf svcutil doesn’t generate code Silverlight can use. I stumbled upon this blog Command line WCF Proxy Generation for Silverlight 2 RTM where he figured out how to use the same dll VS uses to generate the source and wrapped it into a little console app… After chatting w/ him on his blog’s Live Messenger plugin, (very cool by the way) he emailed me the exe he’s using in his production app (that had a couple bug fixes since his original blog post. He told me just to use Reflector to get at the source because it was very basic.

And so I did, and ended up with a pretty good solution to the problems above. (Sucks that I spent a day of dev time on this crap, but oh well…)

I wrote a T4 template that will generate all the reference.cs code needed in our Silverlight project. Instead of describing the template itself (since this post has gotten long alredy) I’ll include a project with a sample of how it works.

Some of the features you get using this template are:

1. It solves the two issues stated above
   1. Only one file generated.  (None of the VS generated garbage metadata files)
   2. No re-add of the ServiceReferences.ClientConfig file to the project.
2. With the use of the T4 template (this is in our app, not in the sample below) you can put other logic needed when generating a service reference.
   1. We are using it to update the Web.Config’s WCF aspnet compatibility flag so we can get at the wsdl and setting it back when done updating the service reference…
      <serviceHostingEnvironment aspNetCompatibilityEnabled="true">
3. You can set some properties that will tell the tool to generate the types as “internal” (if you want)

   Note: you have to add the correct InternalsVisibleTo for this to work

   [assembly: System.Runtime.CompilerServices.InternalsVisibleTo("System.Runtime.Serialization")]
   

Here’s the sample project with examples of both a normal reference, and the same reference using the T4 template.

DOWNLOAD SAMPLE PROJECT

Hope this helps someone else…

What is it?

StatLight is your first class TDD/BDD/(Insert your testing style here) tool for Silverlight. Its main focus is developer productivity.

(The website is young, however the tool is ready to go… Download StatLight here)

In the realm of Silverlight, the tooling support has not had the chance to catch up to what you might have come to expect from normal .net development. When developing Silverlight applications using a test driven style, with the current tooling, it can become a little more tedious than one might like.

A number of testing methodologies have sprung up to enable some sort of testing for Silverlight developers; however, few actually run the tests in the browser.

Below is a short list of features StatLight currently has.

Features:

1. In browser runner to test how your code will “actually” run in the wild.
2. TeamCity Continuous Integration support
3. Smooth Console Runner
   1. One time runner (screenshot below)
      
   2. Continuous Integration runner
      1. This runner will startup and watches for any re-builds of your text xap file. Every time you re-build it will pick up the new test xap and immediately start running the tests.
      2. This feature gives the most as far as developer productivity.
      3. I will put out a video to show how best to use it soon…
4. Tag/Filtering support (to narrow down the tests run at a given time)
5. XUnit support leveraging XUnit (Light)
6. MSTest support. (March 09 build)

On the way:

1. Better Documentation and how to/help videos
2. NUnit support leveraging Jeff Wilcox’s NUnit port
3. CruiseControl.net support
4. MSBuild

Download StatLight here

This may be common knowledge when working with a Silverlight DataGrid, or any grid control in .net. However, I fought through this lesson the other week.

We are using Prism V2 in a business application at work. When databinding several grids to a presenter I tried to enable sorting and ran into an issue where the grid wouldn’t sort if the property being bound to was an IEnumerable<T>…

Once I changed the property’s type to a List<T> on the presentation model (and all the correct sorting xaml tags were set) the grid became sortable.

The other strange thing about this was I couldn’t find anything about it on the net… Is this something that is inherent with other data grids?