I'm happy to inform you that my blog has found a new home, so write it down:

http://blogs.microsoft.co.il/blogs/dorony/

There are several reasons for this move, and the main one is escaping the limitations of the Windows Live Spaces platoform, such as not not being able to upload files, or search my own blog. The second reason is being a part of development-centered community, and MS Israel is a great one, which hosts some of Israel's best bloggers.

I encourage you to subscribe to my new blog's RSS. Also, if you have any links referring to my blog, I hope you can find the time to update them so that they refer to the newer one.

This is it, then. See you at the new place!

Oren has tagged me to answer the question in the headline. I guess the simple answer would be "Code a lot", since I really feel that's the only way one can become a significantly better developer.

The more complex answer consists with subjects I don't know (or don't have much experience with) that I would like to learn. It wasn't easy coming up with this list, mainly because there I so many things I would like to learn, and I had to focus myself on the subjects that I feel that I will actually get to in the next 6 months. I feel that I have a lot of catching up to do in existing areas and technologies, but there are so many new cool technologies right now, so that I can't really stop myself from digging into some of them.

Things I should do

• Code more. As my team's lead I really don't get to do as much coding as I would like. Management takes most of my time. Lately I have adopted a method in which I stay later everyday in order to get at least one hour of coding before I go home. I also code at home, mainly on weekends. I try to always have at least one pet project to work on at home.
• Be the teacher. I spend a great deal of my time teaching and guiding the programmers in my team, and I'm loving it. Whether it's in a code/design review, or when sitting with them to solve a problem, I think that teaching is my most important job. After all, you're only as good a developer as your team is.
• Agile methodologies. I want my team to become more efficient and more productive. Right now I feel that we have a long way to go, and adopting an agile methodology (such as Scrum) is one of my main targets for the near future.
• Blog more. I promised myself to write at least one post every week, but lately I haven't really kept that promise. I definitely think that writing makes you better as a developer. Simply because when you're blogging, you know you can't bullshit anyone. You have to be sure of your facts and fully understand the subject you're writing about. Also, knowing how to express one's self in writing is an important virtue for any developer (especially if you're a part of team).
• Learn more about GIS. GIS is a main issue for my team, and I really feel I don't know enough about it. The ESRI tools we're using don't really make it easy for you to learn. The documentation is usually lacking (not to mention being able to find a decent book), the APIs are non-intuitive, and you'll be hard-pressed to be able to study at home. Anyone can practice C# with free tools like Visual Studio Express or SharpDevelop, but I'm afraid there's no free version of ArcGIS Server ADF or ArcSDE that I know about. The result of all this is that it is a lot harder to become a GIS professional than a .NET professional - we'll just have to keep taking small steps towards that goal.

Things I want to do

• WPF - This has absolutely nothing to do with my work (we do ASP.NET applications), but that's what make studying it so much fun. I'm deep into the WPF Unleashed book, and I'm telling you - the WPF team should teach classes in writing APIs (well, I guess they already do). You can get so many ideas you can use anywhere, just by learning WPF.
• TDD - Well, that's how I'm coding right now, using VSTS and Rhino-mocks. Still a long way to go, though.
• DDD, OR/M, IoC - I did a little project using the Castle offerings and Ayende's Rhino.Common library, and got hooked on these three design methodologies/patterns. Domain Driven Design and a book about NHibernate are in my reading list for this year.
• VS 2008 Stuff. Well, C# 3.0 and Linq are way too exciting to put aside.

Things I won't do

Well, I guess you can take everything I wrote in the "should" part and reverse it (won't stop coding, teaching or blogging). I will also not stop reading fiction ("Harry Potter books", as Shani would call them). I think that reading something that is not related to programming can gain you a bit of perspective. Also, I'm not ashamed to admit that I rather like the Harry Potter series, so Deathly Hollows will probably take precedence over WPF Unleashed in the next week :)

I'm a forgetful person. I almost never leave a room without coming back to it to take something I left behind. I tend to forget birthdays and other important events. And so I worked up little mechanisms to help me remember stuff, such as writing everything down, and setting reminders in my cell for phone-calls I need to remember to make.

One issue I always had, was going back to a certain piece of code I'm writing, a day or two later. I waste at least 10 minutes trying to remember what exactly I was doing and thinking when I had last stopped. At first I had solved this by writing down the next thing I'm supposed to do before I move on, but I now found a much better solution. I make sure that before I stop coding, I have a failing test that describes the next thing I'm suppose to achieve. For instance, if I need to next implement XML Serialization for an object, I would create a ToXml() method for it, throw a NotImplementedException within, and make sure I have a test that calls this method. This way, the next time I come back to the module, I just run its tests, see what fails, and go on from there.

Recently I had an argument with a friend about what I felt were the most technically-difficult problems in developing software. These are issues that have troubled developers since the early days of programming, and are inherently difficult. I feel that it is unlikely that they'll be completely "solved" by any new technology.  

5. Spatial data. I might be biased about this, because I work with GIS systems, but there's something about data that has a geographic location that makes it 10-times more complicated to work with. It starts with the coordinates themselves (how do you represent them? where do you store them?) and continues with all these tasks you thrust upon this data. You have to see how different layers relate to each other, to see which data is near to other data, find paths, display it on maps, and it really never ends. In fact it is practically impossible to work with geographic data without a special software to help you out a bit. Even then, though, it doesn't get easy.

4. Packaging and versioning. I've talked about DLL Hell before. Every software is nothing but a group of inter-connected packages, or assemblies, if you wish to speak in the .NET lingo. And our need to separate our code into different parts, each with its own version, is a source of whole world of troubles. You always have to make sure that one part can find the other, and that what is found is really what it expects to find. And that other part has dependencies of its own, and so it continues. COM demonstrated this more than anything else, but every technology I've worked with has tortured me in this regard. Whether it was C, Java or .NET.

3. Relational databases. A relational database is in the base of almost every information system. The thing is, they're not well suited to working with object oriented languages. Yes, OR/M tools can make your life easier, but they do not solve this issue completely. You still have to understand what goes on behind the scenes. To know how your data is persisted and when or why it is loaded when it is. And you still have to write queries and tune them. There is just no way for you to be oblivious to the underlying relational model. And this tabular model  has got nothing to do with the way we see the world, the way we see the objects form and connect. That's what makes it so hard - not working with the database itself - but to be able to fit it with our view of the world.

2. Multi-threading. Well, this is a no-brainer. If you've been developing for a while, you probably ran into threading issues a few times. Multi-threading is so useful (and in web-development, a requirement) and yet it is always such a huge headache. The .NET framework makes it a bit easier for you, but you still have to know your way around your locks and signaling to avoid performance or deadlock issues. In fact, I feel that multi-threading today is not easier than it was when I worked with it in C.  The bad news are this is not likely to change any time soon, on the contrary - with the growing popularity of multi-core CPUs multi-threading is probably going to become more and more important.

1. Dates. This might seem weird to you at first. What's so difficult about dates? DateTime is a lovely .NET struct that solves all your problems in this department, right? Wrong. This attitude is exactly what makes dates the most problematic technical issue in software, in my opinion. You should never underestimate the damage of not working correctly with dates can cause. Take Y2K for example. The entire world was panicking because everyone neglected to use a 4-digit year. The world has never panicked because of a threading deadlock, has it? And we've all seen date-related bugs over and over again. There are too many formats, too many cultures and too many options regarding the usage of dates, and every language and system handles this differently, causing developers great head aches. I've seen caching systems failure, database corruption and scripting hell (I mean really, 0-based index for months? The one who's responsible for this Javascript bit was probably drunk at the time), all because of the importance of Time.

So, which issues do you find the most troubling? Share your thoughts.

One of the really great things about the ASP.NET Ajax Extensions library is its client-side capabilities. It allows you to write OOP-Style code with namespaces, classes, inheritance and the works. Still, learning to use it can be a bit annoying. You don't get the intellisense or documentation support as you would with C#, and all in all the Visual Studio javascript editor is nothing to tell the kids about.

Therefore, what I would have liked is to be able to write some code in C#, and see how it gets translated to javascript. Nikhil Kothari's Script# does exactly that. This is in fact a C# compiler that generates javascript instead of IL. Recently, he added support for an ASP.NET Ajax only mode, meaning the javascript that is emitted relies only on Microsoft's standard library (instead of Nikhil's library).

This is a great way to write and learn ASP.NET Ajax client script. You want to know how to use classes and namespaces in ASP.NET Ajax? Just write it in C# like this:

public class Person
    {
        private string firstName;
        private string lastName;
        private DateTime birthDate;

        public Person()
        {
            this.BirthDate = new DateTime(1983,10,18);
        }
       
        public string FirstName
        {
            get { return firstName; }
            set { firstName = value; }
        }

        public string LastName
        {
            get { return lastName; }
            set { lastName = value; }
        }
        public string Name
        {
            get { return FirstName + " " + LastName; }
        }

        public DateTime BirthDate
        {
            get { return birthDate; }
            set { birthDate = value; }
        }
        protected virtual string GetIntroduction()
        {
            return string.Format("Hi, my name is: {0} ", Name);
        }
        public void SayHi()
        {   
            Script.Alert( GetIntroduction());
        }
}

And see how it gets translated to this:

TestScriptSharp.Person = function TestScriptSharp_Person() {
    this.set_birthDate(new Date(1983, 10, 18));
}
TestScriptSharp.Person.prototype = {
    _firstName: null,
    _lastName: null,
    _birthDate: null,

    get_firstName: function TestScriptSharp_Person$get_firstName() {
        return this._firstName;
    },
    set_firstName: function TestScriptSharp_Person$set_firstName(value) {
        this._firstName = value;
        return value;
    },
    
    get_lastName: function TestScriptSharp_Person$get_lastName() {
        return this._lastName;
    },
    set_lastName: function TestScriptSharp_Person$set_lastName(value) {
        this._lastName = value;
        return value;
    },
    
    get_name: function TestScriptSharp_Person$get_name() {
        return this.get_firstName() + ' ' + this.get_lastName();
    },
    
    get_birthDate: function TestScriptSharp_Person$get_birthDate() {
        return this._birthDate;
    },
    set_birthDate: function TestScriptSharp_Person$set_birthDate(value) {
        this._birthDate = value;
        return value;
    },    
    getIntroduction: function TestScriptSharp_Person$getIntroduction() {
        return String.format('Hi, my name is: {0} ', this.get_name());
    },
    sayHi: function TestScriptSharp_Person$sayHi() {  
        alert(this.getIntroduction());
    }
}

Nice and simple, and even uses the javascript naming conventions for us :-). Now we can easily use this script from any aspx file by referencing it with a ScriptManager control.

       <asp:ScriptManager ID="ScriptManager1" runat="server">
            <Scripts>
                <asp:ScriptReference Path="~/App_Scripts/TestScriptSharp.js" />
            </Scripts>
        </asp:ScriptManager>
       <script language="javascript">
                var person = new TestScriptSharp.Person();
                person.set_firstName("Doron");
                person.set_lastName("Yaacoby");
                person.sayHi();
        </script>

In fact, you don't have to limit your usage of Script# for educational purposes only. The next time I'll have to write lot's of client-side code which uses the MicrosoftAjax library, I will probably use Script# for this. It contains most if not all the functionality javascript provides, and it gives me C#-comfort.

To get started with Script# I recommend watching the 10-minute screen-cast in Nikhil's post. Basically you have to download the MSI and create a visual-studio project using the built-in Script# templates.

A few warnings:

1. You probably want to turn ReSharper off when you're using Script#, they don't play very well together.
2. If you're using the "Atlas Class Library" project, make sure you remove any reference to an assembly that starts with ss (such as sscorlib.dll). Those are the assemblies for Nikhil's own script library (which is actually more powerful than the ASP.NET Ajax one, but it is not the standard). The assemblies you need start with aa (mainly aacorlib.dll).
3. It took me a while to find the full documentation for Script#. It can be found here.

Happy scripting!

I've mentioned before that we're using Team Foundation Server as our source control repository and integration server. We have encountered many bugs in the tool, and have quite a few complaints (like how it's so very slowingly slow), but it was still a definite improvement over what we had before (VSS 6 for source control and nothing for integration).

A few days ago an issue had risen that required us to reinstall TFS. Currently we're our own TFS admins in the company, so it is our responsibility to do this procedure. And there was hell to pay.

Anyone who has tried to install TFS, knows it's not easy. You start with a whole bunch of unclear error messages, which you have to google up for solutions. And once you get through one of those, you get another one. And so it continues, until it ends after a few days of trials and errors. In essence, there are very specific steps you have to go through, and if you leave something out, you have to start all over again. Joy.

Now, reinstalling is exactly like that, only worse, since now you have to worry about all that data you already have in the server. It took us two days to reinstall everything (SQL Server, WSS, TFS and relevant service packs and hotfixes) - apparently there's a new line of errors we haven't seen yet if you're reinstalling and not installing on a fresh machine. Once that was over, we tried to restore our database backups (again, there are specific steps you must take). That of course, didn't work. We were unable to connect to TFS. So we figured we did something wrong in the installation process, and so we reinstalled again. And again. Still nothing - all we have to work with is 5 different errors in the event viewer which show up after we attempt a connection to TFS. Needless to say, looking these errors online turned up nothing.

Currently my team is pretty much grounded on the account of no source control to work with. Our only choice seems to be to recreate our team project on a fresh and uncorrupted database, and check-in local copies of our solutions (losing all history in the process). This will allow the rest of the team to go back to coding, while we continue to try and restore our backups to a different server, so we'll at least have access to the history if we need it.

You could argue that we lack the required knowledge about TFS, and that we need some system team to do the installs/restores for us. You'd be right - this is a new product, and we're still in the process of learning it. And yet, I feel that it shouldn't be this hard. I mean, can't it just work? I've never had such issues with any Microsoft software, or even with ESRI's software which is never easy to install and configure.

Now we're in the risk of losing our source code history, and I can't help but feel uneasy to work with a product that I know to be so unstable. The basic thing I can expect from a source control server is to be able to restore its data from backup, should it happen to explode. I can't sleep easily at night if I'm not absolutely certain that I can achieve that. With TFS, my nights are not easy at all, and I can't help but wonder if we did the right choice when we decided to work with V1.0 of the product. Waiting for the stable V3.0 might have been a better idea.

I've been learning WPF for a while now (using WPF Unleashed - a great book by Adam Nathan), and it's really awesome. I'm guessing that soon enough there will be little reason to develop new smart-client applications using WinForms. WPF's API is really well-thought of and easy to work with, and it also makes for such pretty results.

One thing I had an annoying issue with was WPF's commands. Commands are actions in your window (or any other element) that accomplish something and are not specifically related to any button or menu click event.

For example, suppose you have an InkCanvas, which is basically a drawing pad which you can draw stuff on with your mouse, and you want to be able to clear it once in a while.

You could add a "clear" button to the window and clear the canvas on this button's click event, but what if you wanted to have a right-click menu that can do the same? And what if you want it get cleared on "Shift-C"? Using the Click event creates an undesired coupling between the button and the canvas in this case.

So I tried to do this using the Command feature, which allows you to have loose coupling in cases like this. At first, my code looked like this:

<Window x:Class="WindowsApplication1.CanvasExample"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Title="WindowsApplication1" Height="300" Width="300"
    >

  <Window.CommandBindings>
    <CommandBinding Command="ClearCanvas" Executed="ExecuteClearCanvas"/>
  </Window.CommandBindings>
  
  <InkCanvas x:Name="MainCanvas">
    <InkCanvas.ContextMenu>
      <ContextMenu>
        <MenuItem Header="Clear" Command="ClearCanvasCommand" />
      </ContextMenu>
    </InkCanvas.ContextMenu>
  </InkCanvas>
  
</Window>

With the code-behind being:

 public partial class CanvasExample : System.Windows.Window
    {

        public CanvasExample()
        {
            InitializeComponent();
        }

        void ExecuteClearCanvas(object sender, ExecutedRoutedEventArgs e)
        {
            MainCanvas.Strokes.Clear();
        }

    }

The XAML part contains an InkCanvas, and inside it a context menu (a right click menu) with a "Clear" item. This "Clear" Item is bound to a "ClearCanvas" command, which calls the ExecuteClearCanvas method on its Executed event. Seems OK, no?

This would compile, but will not run. A very unpleasant (and unclear) XamlParseException was thrown at me and I had to duck (har har).

I understand that this is a new technology, but man, I hate it when I have to figure out my own stupidity on my own. I scratched my head for a while, and then I went and read some more about WPF commands.

Apparently, what I didn't realize was the wrongness of this line:

<CommandBinding Command="ClearCanvas" Executed="ExecuteClearCanvas"/>

The "Command" attribute here actually expects something that stands for a real object that implements ICommand. This does not mean that I have to implement ICommand on my own, but I do have to add the following lines to my code-behind class:

namespace WindowsApplication1
{
   public partial class CanvasExample : System.Windows.Window
   {
        public readonly static RoutedUICommand ClearCanvasCommand;

        static CanvasExample()
        {
            ClearCanvasCommand = new RoutedUICommand("ClearCanvas", "ClearCanvas",    typeof(CanvasExample));
        }
        ....
    }
}

Here I'm adding the command object to my class, which is an instance of the RoutedUICommand object (this is why I don't have to implement ICommand myself, RoutedUICommand does this already). Now I just have to fix my XAML to refer to this object.

 1 <Window x:Class="WindowsApplication1.CanvasExample"
 2     xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
 3     xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
 4     xmlns:local="clr-namespace:WindowsApplication1" 
 5     Title="WindowsApplication1" Height="300" Width="300"
 6     >
 7 
 8   <Window.CommandBindings>
 9     <CommandBinding Command="local:CanvasExample.ClearCanvasCommand" Executed="ExecuteClearCanvas"/>
10   </Window.CommandBindings>
11   
12   <InkCanvas x:Name="MainCanvas">
13     <InkCanvas.ContextMenu>
14       <ContextMenu>
15         <MenuItem Header="Clear" Command="local:CanvasExample.ClearCanvasCommand" />
16       </ContextMenu>
17     </InkCanvas.ContextMenu>
18   </InkCanvas>
19   
20 </Window>
21 

Instead of the "ClearCanvas" string you see this - local:CanvasExample.ClearCanvasCommand. This is our way to refer to the actual command object we created on our code-behind class. The "local" refers to an XML Namespace, which we declared on line 4 - This allows us to import the WindowsApplication1 namespace to our XAML, so whenever we're using "local" we're actually referring to this CLR namespace. At this point everything worked and I was very pleased.

Now, if I wanted the canvas to get cleared on Shift-C, I would only need to add this to my XAML:

<Window.InputBindings>
    <KeyBinding Command="local:CanvasExample.ClearCanvasCommand" Modifiers="Shift" Key="C"/>
  </Window.InputBindings>

It's important to note that we don't have to create our own command objects for all the command we are using. WPF has many built-in commands, that reside in static classes such as ApplicationCommands and EditingCommands. They contain useful commands such as "Close", "Help" or "Copy" and "Paste".

To conclude, I feel that WPF commands can help you create nicely decoupled applications when you know how to use them. If you don't, don't expect nice error reporting from the current version...

This concludes my first post about WPF. Since I'm really hooked up on this technology, I guess you could expect more in the future. Oh, and This article has more about WPF commands. Enjoy!

You probably heard it a million times. It is one of the golden rules of web-development. Do not rely solely on client-side validation to ensure you get the data that you expect from the browser. Anyone can send you a crafted request that bypasses your script validation. Always validate on the server as well. And yet, I see a lot of commercial sites that ignore this rule, and it is easy as hell to break their logic. In fact, with the following simple steps I will show, you can bypass any javascript-only validation.

Consider the following TestValidation.htm page:

 1 <html >
 2 <head>
 3     <title>Validation Lies To You</title>
 4     <script>
 5         var valid;
 6         function validate() {
 7              valid = document.getElementById('Text').value != "";
 8             if (!valid)
 9                 alert('Not Valid!');
10             return valid;
11         }
12     </script>
13 </head>
14 <body>
15     <form method="post" action="save.aspx" onsubmit="return validate();">
16     <input id="Text" type="text" />
17     <input type="submit"/>    
18     </form>
19 </body>
20 </html>

This html page contains a form, a text box and a button. The validate function checks if the form is valid (in this case that the text box contains a value, but it can do any other validation as well). If it is valid, the form will submit to save.aspx, if it is not - an error message is displayed.

In order to bypass this validation we don't have to craft an http-request or play with the script options of our browser. What we need to do is this:

• Install Firebug. This is a great add-on to Firefox that can help you debug web-sites and javascript easily. And also bypass client side validation.
• Point Firefox to our TestValidation.htm. Hit submit. Err, javascript alert. Can't submit. What can we do?
• Open the Firebug console (via the Tools->Firebug menu or the Firebug icon on the status bar).
• Go to the script tab in the Firebug console and place a breakpoint on line 8 in the code (the "if" statement).
• Now hit the submit button, the breakpoint will hit and the page will halt.

This is where we are:

• We want to change the value for the "valid" variable. We go to the console tab (which is somewhat like the VS debugger "immediate" window) and enter "valid=true".
• Now we go back to the script tab and hit F5. The form posts like a charm.

Now you could say I cheated a little by making "valid" a global variable, and indeed I couldn't find in Firebug a way to change the value of a local variable of a function (the console seems to affect only global DOM elements, unlike the VS debugger "immediate" window). But even if it were a local variable I could write in Firebug the following (before clicking the button):

document.forms[0].onsubmit = function(){return true;}

Or simply:

document.forms[0].submit()

The form would have submitted perfectly in both cases, ignoring the client validation.

So we have arrived at the following conclusions:

1. Client-side validation is not security. Always validate on the server side as well. ASP.NET's default validators do this for you, but if you use CustomValidator remember to handle its Server_Validate event.
2. Firebug is an awesome tool - I wish I had an equivalent for IE (for the meantime I'll have to settle for IE Dev Toolbar).

Happy coding!

We have encountered an interesting issue regarding assembly referencing from an ASP.NET web project in Visual Studio 2005. A developer in my team did the following: he added to a web-site a reference to a GAC installed assembly, lets call it Gac.dll. This GAC installed assembly had a file reference to another assembly which was not installed at the GAC, we shall call it Lib.dll, and we shall assume it is located in c:\lib.

Lets assume Gac.dll has the following code in it:

namespace Gac
{
    public class GacObject
    {
        public void UseLib()
        {
            new Lib.LibObject().DoSomething();
        }
    }
}

And the developer in my team had code similar to this:

protected void Page_Load(object sender, EventArgs e)
 {
        new Gac.GacObject().UseLib();
 }

At this point, Boom. Runtime exception:

Could not load file or assembly 'Lib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=b51b3d0471344dda' or one of its dependencies. The system cannot find the file specified.

Now, in order to understand why this happens, we first have to understand a very important thing:

An assembly does not store the locations of the DLLs it is referencing in its manifest.

That is, the reference in gac.dll to lib.dll would look like this inside the assembly manifest:

.assembly extern Lib
{
.publickeytoken = (B5 1B 3D 04 71 34 4D DA ) // ..=.q4M.
.ver 1:0:0:0
}

No where does it say that we can find Lib at c:\lib. So when on Page_Load we are calling the UseLib method, the CLR has to load the Lib assembly at this point. For that to happen it needs to find it first. The CLR would look for the assembly in several places, including the Bin directory and GAC, but it won't find Lib.dll in neither. And there's no reason for it to know to search in c:\lib. Hence, an exception is thrown to our faces.

Now, why was it important to mention that this is a web project? Won't the same thing happen for, say, a console application? Well, no. Say that we create a console application called MyApp, and reference Gac.dll in it, in which we will have the following code:

class Program
    {
        static void Main(string[] args)
        {
            new Gac.GacObject().UseLib();
        }
    }

Running this will work like a charm. Not because the CLR acts differently for console applications, it is actually because the way Visual Studio compiles this project. In all projects which are not web sites, compiling in VS2005 means running the MSBuild script that is in our .csproj file. This script is actually smart enough to know that since Gac.dll is referencing Lib.dll, we will need it in our output directory (in MyApp case - bin\debug). Therefore it will copy Lib.dll and any other assemblies that Gac.dll is using (that are not installed in the GAC, that is) to this directory. Hence, when we run our program, the CLR quickly finds Lib in our bin\debug directory and everything works.

But when we compile our web site project, this does not happen, as it doesn't run the standard MSBuild script (we don't even have a .csproj file, remember?). It will actually work for assemblies that are not in the GAC - if you try and add a reference to nonGac.dll which is also referencing Lib.dll, Lib.dll will be automatically added to the site's bin directory. Not on compile time, mind you. Visual Studio will do this at the moment we add the reference to nonGac.dll. For some unknown reason, the same doesn't happen for a Gac.dll which is in the GAC, and therefore we get an exception at the moment we try to load Lib.dll.

Once we understand the problem, the solution is quite simple. We have to tell the CLR where to find Lib.dll. There are several things we can do:

1. Manually add a reference to Lib.dll to the site's Bin directory.
2. Add Lib.dll to the GAC (best option, IMO).
3. Tell the runtime where to search for the dll, using a configuration option.
4. Switch to a Web Application Project and get all the standard MSBuild features.

Hopefully this wasn't too confusing. The subject of assembly referencing and binding can give you quite a hell in .NET, so it is critical to have a good understanding of what is going on.

One of the most useful features of .NET 2.0 is anonymous delegates. They allow you to create "wrappers" for code which run before and after the code, handle exceptions in it, and decide whether to run it or not. Consider the following method:

public static void WrapCall(Callback callback)
 {
            try
            {
                callback();
            }
            catch (Exception x)
            {
                ExceptionManager.Publish(x);
                throw;
            }
 }

Which will be called like this:

WrapCall(
                delegate()
                    {
                        DataAccess.UpdateSomething();
                        EmailSender.SendSomething();
                    });

This ensures that the exception wrapping and publishing code is handled in one and only one place, and that is the wrap call method. The user does not have to worry about publishing exceptions to log.

Another use of anonymous delegates can be in the following method:

 public class CallManager
 {
            public static void EnableLoggingForCall(Callback callback)
            {
                if (Logger.EnabledForCurrentThread)
                {
                    callback();
                }
                else
                {
                    Logger.EnabledForCurrentThread = true;
                    callback();
                    Logger.EnabledForCurrentThread = false;
                }
            }
 }

This method job is to ensure that the logger is enabled for a specific method execution. We want to make sure that if it is already enabled, we do nothing, but if it is not, we enable it and then turn it back off (since we turned it on it is our responsibility to turn it off). This is how we'll call it:

CallManager.EnableLoggingForCall(
                delegate()
                    {
                        new CriticalAction().Run()
                    });

But anonymous delegates do not have the prettiest syntax in the world, they can be a bit hard to grasp at first, and you can expect an issue if you write code like this:

CallManager.EnableLoggingForCall(
                delegate()
                    {
                        base.Run();
                    });

Because of the way anonymous delegates are implemented, you can expect a compilation warning about this code. You'll be happy to know, then, that for this scenario we can find an alternative for delegates.

Meet DisposableActions

In this post Oren Eini describes a pattern called DisposableAction. In a similar manner to anonymous delegates, it allows you to ensure certain code is run both before and after the user's code. In some scenarios, we can use it instead of delegates. Our second example, implemented with DisposableAction, will be used like this:

using (CallManager.EnableLoggingForCall())
{
       new CriticalAction().Run(); //base.Run() will also work
}

And the implementation:

 1     public static IDisposable EnableLoggingForCall()
 2     {
 3             if (Logger.EnabledForCurrentThread)
 4                 return new DisposableAction(delegate { });
 5            
 6             Logger.EnabledForCurrentThread = true;
 7             return new DisposableAction(
 8                 delegate 
 9                 {
10                     Logger.EnabledForCurrentThread = false;
11                 });
12    }

So what happened here? As described in Oren's post, a disposable action runs the action attached to it when the Dispose method is called on it. Since the using statement ensures the object it is using gets disposed, we know that lines 3-6 will run before our critical action executes, and that line 10 will run after it executes. This way we have achieved the same thing as we did with an anonymous delegate, but with a simpler syntax and without strange side-affects.

Note that this pattern can only work for the second case I showed here: needing to run some piece of code before and after a block of code is executed. If we had to catch an exception (as we did in the WrapCall example) or have the option not to run the block of code at all (because we want to get the result from the cache, or whatever) we would have to use anonymous delegates. The code in line 10 has no control on the action execution itself, nor can it know if an exception has occurred there.

Still, I find this a very elegant pattern, and I highly recommend using it instead of delegates, when appropriate.

As I've said before, our team has begun doing unit testing. At first we used NUnit and NCover for this purpose, although we have VSTS licenses. This was for the following reasons:

1.  NUnit is faster than VSTS (and that test panel really slows down the IDE... Like it isn't slow enough!).
2. NUnit has more features than VSTS (although for now we're using only the basics anyway) and less bugs.
3. NUnit has more support and lots of googleable knowledge. It is definitely the more mature solution.
4. NUnit feels more "clean" to me. You don't have to create a special test project for it, and it doesn't add any weird solution items. You just create a library project and can start testing.

We are now changing back to VSTS testing, for the following reasons:

1.  Team Foundation Server natively supports it.

OK, so that's only one reason, but it's a pretty damn good one. Since we are already using TFS for our source control and spent quite some time learning it and setting it up, it makes the most sense for us to use it as our continuous-integration server. That's where we'll do our nightly builds, code analysis, etc.

I find this (having to choose the less mature tool) rather annoying, but what comforts me is that thanks to Test Driven.NET the daily work is hardly affected, and you don't have to use that annoyingly slow test window (unless you're really eager to get pretty GUI for your tests).

Life is full of compromises, I guess.

Yesterday I tackled this extremely annoying bug, which kept me annoyed for about 10 hours in a row. We are using a GIS software called ArcGIS Server, which one of its main uses is to supply maps - In our case, images passed to a web-control which comes with the software. Everything worked nice and dandy until we installed our new version on a new production server. The maps would not display and all we got to see is WHITE.

At the following hours I tried, among others, the following approaches:

• Recreating the cache for the maps (X 10 times)
• Moving the output directory around and playing with the permissions for it (X 5 times)
• Uninstalling and Reinstalling ArcGIS Server (X 1 time)
• Banging my head on the desk (X 20 times)

When all failed, I pointed my local machine to the server and moved into debug mode, stripping the map page into its most basic functionality, which still didn't work. No errors appeared in the log. The images did seem to get created on the server, but for some reason I couldn't see them in the client. Don't know why it took me this long, but at about 23:00 o'clock it finally came to me to try using Fiddler in order to understand what's going on in the network level. That's when I saw this:

prodserver/ags_dfdjf.png: Sorry, unable to resolve DNS "prodserver".

• Bang head on the desk (X 100 times)

Stupid, stupid, stupid. Should have pointed the virtual directory for the output images to prodserver.com. Why oh why didn't I notice this sooner? To God the answers.

Bloody url extensions. Who needs them anyway.

(Just had to share this amusing comic from xkcd.  And please ignore the camel casing, they're probably Java people)

I am currently reading Steve McConnell's great Rapid Development book, in which the author marks "wishful thinking" as one of the greatest mistakes one can make in software development. McConnell managed to express in two words the root of most problems in this field, and probably the main cause of most of my own mistakes.

You know how it is. Sometimes you wish yourself to succeed. "Sure I can make it in a week". "So what if we have two weeks to complete a two months work. It will work out". That's you wishing it away. I consider myself a rational person, and still I can look back and see quite a few times in which I behaved very irrationally, thinking everything will be just "be OK". So you ignore that nasty looking bug, only for it to rear its ugly head at the final testing phase, and by then you don't have the time to fix it. Or you agree to add those extra features, thinking they will be rather easy to implement. Or should I say, wishing them to be so. They won't, not because you wished it so, that is.

Ever since I became the team's lead (only a few months ago) I've started forcing myself to do reality checks. Are we really going to make the schedule? What exactly is it going to take for us to succeed? I find it useful, for example, to picture in my mind the week in which we have to install the new version of the software we're developing. What will happen, exactly, during that week? Who will have to do what, what kind of hardware, software licenses, or people we're going to need during that week? What can happen that will prevent one of these things or people to not be there for that week? What will we do in that case? I also became quite paranoid about difficult looking bugs. I've learned that ignoring them, or thinking that "It's because we're using IIS 5, it will be OK when we install it on IIS 6" tend to not solve bugs.

Then I translate all this paranoia into a risk-list, in which I list everything that could possibly go wrong, and ask myself what am I going to do to stop them from going wrong. At first I thought risk management was boring and useless. Now my paranoia-list control my schedule. It's what I base most of my actions on.

The best advice I can give you, and especially to myself, is to never look the other way when you smell a problem. If it smells like a fish then it's probably a fish. You can't wish it into a steak. Plan ahead, manage your risks, be paranoid. When things go wrong, you'll be ready, or at least you'll feel you did everything you could.

A small warning: Do not install the pre-release of ReSharper 3.0 on Visual Studio Orcas. Although the installation works, ReSharper does not handle the C# 3.0 syntax correctly (it really doesn't like x => x+1 syntax), and the intellisense gets all screwed up. Trying to uninstall ReSharper 3.0 resulted in my VS Orcas having an empty "ReSharper" menu, and with the intellisense gone, which I had to fix manually (by scanning the options menu for about an hour for the right option). To add to the fun, my installed ReSharper 2.5, which is installed on VS2005, has lost its highlighting features in the process, so I had to reinstall the 2.5 version. Fun.

You know that feeling that you have too much to learn and too little time? Well, I'm currently attempting to learn the following things:

• Unit Testing and TDD (using NUnit and RhinoMocks mocking)
• Castle Stuff
• ActiveRecord (and through it, a little bit of NHibernate)
• MonoRail (MVC framework for ASP.NET)
• Windsor (IoC container)
• Boo (python-like language for .NET)
• C# 3.0 and LINQ
• SQL Server (but just a bit)
• Working with Resharper (especially template authoring)

I am now trying to a simple web project in which I will incorporate all of this, and it is turning up to be quite fun and challenging.

My strategy is this: Learn almost nothing up front. Try to do something. Get stuck. Learn what I need to solve the problem. So I would learn only the most basic ActiveRecord stuff to start working, but as soon as I hit a road-block (changing the naming strategy for my property-column mapping) I dig in the documentation. This works quite well and prevents me from reading long articles/documentation sections up front. I just take what I need and move on.

Still, this is very time consuming. It also makes me glad I haven't begun doing my masters degree. What I'm studying at home just seems a lot more interesting and useful, and I know that going back to the university will leave me little time, if any, to really learn new technologies.

I'll be the first to admit that I was never a COM programmer, so I had never experienced COM's original DLL hell. From what I hear, it was really gruesome. No standard in DLL versioning, programs overwriting each other's DLLs, and generally the kind of chaos in which stuff don't work and you have no idea what's wrong.

.NET's assemblies, with their standardized naming and versioning, have definitely made our lives easier. Once we have a DLL, we know exactly what version it, and what version of other DLLs it's using. But I feel, that even in .NET, it is still too hard. I have spent hours trying to figure out TypeLoadExceptions/MissingMethodExceptions/'Expected version 1.0.2.32 found something else' exceptions, caused by weird versioning issues.

Not to mention exceptions similar to "InvalidCastException: Cannot implicitly convert type Geometry.Circle to Geometry.Circle. An explicit conversion exits (are you missing a cast?)". No, I'm not missing a cast, it's the same bloody type! Once you've spent a while looking at assemblies' manifest in ILDASM, verifying the versions of their dependencies, you know something is wrong.

And the new Stock project model of ASP.NET has made it even worse. Man, the time we burnt on weird compilation errors, claiming there are different versions of DLLs in the GAC and in the temporary ASP.NET directory... (Side note: together with long compilation times, missing project file, and extremely annoying assembly referencing issues, I would think hard before I would use this kind of project for a new web site. The good old .NET 1.1-like WebApplication project is looking pretty attractive right now).

My point is this: yes, I guess a .NET developer's life, versioning-wise, is not as hard as what a COM developer's used to be. But they're still not peachy at all.

Update: My friend Idan (a link to his hebrew speaking gaming blog) has sent me a link to this interesting post which talks about assembly loading and binding. It also alerted my attention to the fuslogvw.exe tool, which can assist you with the mysterious exceptions I mentioned in this post.

I am rather ashamed to admit that up until now I've never really tried to use Resharper, the very well known Visual Studio add-in. Today I decided to give Resharper 2.5 a try and was really blown away. Comparing Visual Studio 2005 without Resharper to Visual Studio 2005 with Resharper, is like comparing Turbo Pascal to, well, Visual Studio 2005. There's really no match here.

It starts with the little things, like how it always adds a matching brace to any brace you use ({,[,(). It makes you think why the hell isn't this already built in in Visual Studio. Or how the Resharped Intellisense always show the entire list of method overloads, without you having to scroll in the 7 method overloads or resort to MSDN.

But then you get to see the really smart stuff. Like the Refactoring features, which again make VS2005 attempt at this look rather silly. I'm talking about stuff like "Replace Constructor With Factory Method" or "Pull Members Up" (allows you to move a method implementation/declaration to a base class/interface), but also about simpler things such as "Safe Delete" (ever wanted to delete a class and wasn't sure what will break?) or "Convert Method To Property".

And imagine my amazement when I noticed this:

Which gets converted to...

And another extremely cool one:

And I haven't started to talk about the Live Templates, which are like Code Snippets only a lot smarter, or all the navigation features (especially the way it understands inheritance hierarchies), or about the way it marks redundant "using" directives in gray. It really is simply brilliant, and this is me talking after playing with it for about an hour.

Now the only question that remains is how to get the bosses to buy us those 250$ licenses...