I have recently been working with a multiple web project solution in Visual Studio. For ages, I’ve been switching between each web project by stopping debugging, setting the other as the start up project, and then starting debugging again. As you can imagine, this makes testing interoperability between the two quite a drag.

One of my colleagues showed me that if you set a specific port for Visual Studio’s development server, you can then start the main project (in the normal fashion), but then also start the second project by right-clicking on it, and selecting “run” from the debug menu.

This was a good step forward for me, as previously I wasn’t sure it was possible to achieve debugging across two projects if there was no direct reference defined. However, being the person I was, I wasn’t quite satisfied with having to start one project, then manually starting the second once it had started. So I had a bit of a dive through the various properties and configuration screens within Visual Studio and discovered a method that allows you to start multiple projects, in a defined order, by simply hitting F5.

To do it, right click on the Solution, and choose properties from the context menu. Once the new window appears, ensure “Common Properties”->”Startup Project” is selected from the list on the left.
Then, on the right side of the screen, select the “Multiple startup projects” option. Finally, change the “Action” cell in the table for each project you want to start up when you begin debugging.
If you need to specify or change the order in which projects are selected, you can select the table row for that project, and using the up/down arrow on the right of the page, move it up and down in the startup order.

Quite a neat trick that could have saved me a good deal of ball ache in the earlier parts of this project!

I’m now the sole developer working on arguably one of the largest projects for our company, and things are going well. However, I keep falling into traps and pitfalls created by one of the projects last programmers.

One of his “favourite” tricks seems to be creating a business layer method that populates an object based on data retrieved from a database. Nothing odd there.. but it’s when you have the need to re-use one of his functions that you end up falling right into his carefully seeded trap!

For example, we have an object called “CustomerSite”, which as the name suggests, has various properties that pertain to a customer’s site – 15 individual properties to be exact.
Whilst writing an additional management page for the project today, I had the need to get a “CustomerSite” object from the database, based on the site code.
A quick look through our data access methods reveals a pre-written method “GetCustomerSiteBySiteCode”. Excellent; No need to write a new stored proc and no need to write the retrieval C# code!

However, in hindsight I knew this particular programmer had written both the retrieval method and the stored proc, so I should have checked ahead of time, but alas I did not…

So I fire up my new shiny page and all goes well, right up to when my codebehind calls the “GetCustomerSiteBySiteCode” method. At which point, my page throws a wobbly with invalid use of null errors throwing hand over fist.

Initially, I start checking the database to make sure the data is actually fine for the customer site I selected. With that being fine, I check my code to make sure I’m not doing anything daft. Happy that I’ve not, it’s time to place a breakpoint and step on through…

It’s at the point I step into “GetCustomerSiteBySiteCode” that I realise I’ve been stung; Despite the “CustomerSite” object having 15 properties, only TWO of them are being set by this method – the rest are simply set to null.

After altering the method to actually populate all 15 properties, I checked the stored procedure, to find two select statements, the first with all fifteen fields commented out with the note “Probably want to include these fields later, but haven’t the need to use them yet.”

To quote Peter Griffin “This really grinds my gears”. It was the programmer who created the “CustomerSite” object to begin with, and it’s always had all 15 properties from the get go. It’s simply a case of laziness and lack of forethought; there’s every reason to believe that this method would be called elsewhere, especially as when he was working on the project, it was a multi-person project.

Grr.

On the face of it, it sounded like an easy answer. I knew you could disable both the minimize and maximize buttons very easily from within the Visual Studio GUI – so surely there’s an option for the third button; the close button?
Actually, no. Whilst you can remove all three buttons in one go (changing the setting “ControlBox” to false.) and as previously mentioned, you can disable the maximize and minimize buttons (“MaximizeBox” and “MinimizeBox” settings respectively), there is no setting to directly control the Close button.

A quick Google search produced a few varied approaches, but the one I suggested my colleague to implement is as follows:

1
2
3
4
5
6
7
8
9
10

private const int CP_NOCLOSE_BUTTON = 0x200;
protected override CreateParams CreateParams
{
    get
    {
        CreateParams mdiCp = base.CreateParams;
        mdiCp.ClassStyle = mdiCp.ClassStyle | CP_NOCLOSE_BUTTON;
        return mdiCp;
    }
}

This small bit of code simply needs to be placed within your form class; It overrides a property that is already called when a form is initialised, so doesn’t need to be explicitly called.

Some before and after shots:

My initial thoughts were to examine the executing processes and check for the existence of the application in the list:

1
2
3
4
5
6
7
8

    string procName = Process.GetCurrentProcess().ProcessName;           
    Process[] processes= Process.GetProcessesByName(procName);
 
    if (processes.Length == 1)
    {
        //run application
        ...
    }

Now, whilst this works, it is easily “beatable” by simply changing the executable’s name. Doing so will cause the method “GetProcessessByName()” to return only a single match, instead of the current application and any other duplicate instances.

After pondering on the subject for a while, I started to think how threading works, or more precisely, how threading deals with shared resources.

When a thread attempts to access a shared resource, an exclusive lock is applied to that resource until the thread completes it’s task. These locks are actually “Mutex” objects (read more here).

Using a Mutex, I was able to create the following code:

1
2
3
4
5
6
7
8
9
10
11
12
13

    bool isFirstInstance;
    Mutex mx = new Mutex(true,"Global\\MyApplicationName",out isFirstInstance);
 
    if (isFirstInstance)
    {
        //run application
        ...
        mx.Close();
    }
    else
    {
        //application already running
    }

The “Global\\” prefix tells the Mutex to be available across all user instances on the machine, not just the current.

Also, whilst it’s not strictly required to close the Mutex before exiting, as it will be automatically closed when the application ends, I’ve added it in this example for completeness.

In my opinion, this method is more reliable, more robust, and slightly cooler

Now, whilst I agree that cross-thread operations should be handled correctly, and I’m actually glad Microsoft decided to tighten its belt over this when it came to creating the dotNet framework, it just seems very “bloaty” to have to write methods such as the following:

1
2
3
4
5
6
7
8
9
10
11
12
13

delegate void SetFirstNameTextCallBack(string value);
private void SetFirstNameText(string value)
{
   if (txtFirstName.InvokeRequired)
   {
      SetFirstNameTextCallBack cb = new SetFirstNameTextCallBack(SetFirstNameText);
      cb.Invoke(value);
   }
   else
   {
      txtFirstName.Text = value;
   }
}

Ok, you can get a bit cleverer and write delegates and methods that expect a control, property name and property value to be provided, such as this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

delegate void SetControlPropertyCallBack(Control control, string property, object value);
private void SetControlProperty(Control control, string property, object value)
{
   if (control.InvokeRequired)
   {
      SetControlPropertyCallBack cb = new SetControlPropertyCallBack(SetControlProperty);
      cb.Invoke(control, property, value);
   }
   else
   {
      Type t = control.GetType();
      System.Reflection.PropertyInfo propInf = t.GetProperties().First(p => p.Name.ToUpper() == property.ToUpper());
      propInf.SetValue(control, value, null);
   }
}

But it still looks yuck to me.

Over the last few weeks, I’ve been increasingly using lambda and extension methods, and came up with a new way of handling invokes that I actually like!
It involves extending the “Invoke” method, as shown below:

1
2
3
4
5
6
7
8
9
10
11

public static TResult Invoke(this T controlToInvokeOn, Func codeToInvoke) where T : Control
{
   if (controlToInvokeOn.InvokeRequired)
   {
      return (TResult)controlToInvokeOn.Invoke(codeToInvoke);
   }
   else
   {
      return (TResult)codeToInvoke();
   }
}

With this implemented, any time you need to invoke anything, you can do so quickly and elegantly with a little lambda:

1

txtFirstName.Invoke(()=>Text = "test");