Archive for September 2011

Embedding referenced assemblies as an Embedded Resource, and resolving dependencies at runtime.

This was inspired by this question on StackOverflow. First off, this is bad design unless you are designing some sort of setup application. But, specifically for those who still wish to proceed, here is how you do it.

Download Example Code
EmbeddedReferenceApplication.zip

In this example, there are two projects. ‘EmbeddedReferenceApplication.exe’ and ‘EmbeddedReference.dll’. Here are the steps.

  1. Add a hard reference to EmbeddedReference.dll from EmbeddedReferenceApplication.exe
  2. Go to the reference Properties, and set Copy Local = False
  3. Right click your project and add the referenced assembly as a link (Add As Link)
  4. Right click the linked assembly in your project, and set its build output to ‘Embedded Resource’
  5. Modify your code with proper manifest name handling/resolution
  6. See the example code or post comments for more help
using System;
using System.Collections.Generic;
using System.Text;
using System.IO;
using System.Windows.Forms;
using System.Reflection;
using EmbeddedReference;

namespace EmbeddedReferenceApplication {
    class Program {
        static void Main(string[] args) {
            AppDomain.CurrentDomain.AssemblyResolve += AppDomain_AssemblyResolve;
            MyMain();
        }

        private static void MyMain() {
            EmbeddedReference.MessageHelper.ShowMessage();
        }

        private static Assembly AppDomain_AssemblyResolve(object sender, ResolveEventArgs args) {
            string manifestResourceName = "EmbeddedReferenceApplication.EmbeddedReference.dll"; // You can also do Assembly.GetExecutingAssembly().GetManifestResourceNames();
            string path = Path.Combine(Application.StartupPath, manifestResourceName.Replace("EmbeddedReferenceApplication.", ""));
            ExtractEmbeddedAssembly(manifestResourceName, path);
            Assembly resolvedAssembly = Assembly.LoadFile(path);
            return resolvedAssembly;
        }

        private static void ExtractEmbeddedAssembly(string manifestResourceName, string path) {
            Assembly assembly = Assembly.GetExecutingAssembly();
            using (Stream stream = assembly.GetManifestResourceStream(manifestResourceName)) {
                byte[] buffer = new byte[stream.Length];
                stream.Read(buffer, 0, buffer.Length);
                using (FileStream fstream = new FileStream(path, FileMode.Create)) {
                    fstream.Write(buffer, 0, buffer.Length);
                }
            }
        }
    }
}

What this does is subscribes to AssemblyResolve and allows the application domain to resolve your assembly to a custom path – in our case, we resolve to the application directory but we are extracting the assembly first, and returning the resolved assembly. You can use this same code to resolve dependencies and assemblies from custom directories and paths.

A key note is lines 12 and 13. You must not use any code directly in the Main method that would otherwise reference a dependency. What this causes is for your exception to be thrown while Main is compiled, and before it is run. You will never give the application domain a chance to perform dependency resolution. However, a quick fix is to throw it into a helper method called MyMain (call it SubMain or something similar), that would not otherwise reference the dependency until its invoked.

Adding extension method support for .NET 2.0

.NET Framework 2.0 does not support extension methods out of the box, because you cannot reference System.Core that was introduced in .NET 3.5. However, by adding a simple attribute class you can use extension methods in .NET 2.0 as well. Here is the snippet.

namespace System.Runtime.CompilerServices {
    /// <summary>
    /// Mimics the .NET 3.5 extension methods attribute
    /// </summary>
    [AttributeUsage(AttributeTargets.Method)]
    internal sealed class ExtensionAttribute : System.Attribute {
        /// <summary>
        /// Instantiates a new instance of the ExtensionAttribute class
        /// </summary>
        public ExtensionAttribute()
            : base() {
        }
    }
}

Here is an example afterwards using extension methods in one of our applications.

namespace Setup.AppCode {
    using System;
    using System.Collections.Generic;
    using System.Windows.Forms;
    using System.Text;
    using System.Runtime.CompilerServices;

    /// <summary>
    /// Extension methods class
    /// </summary>
    public static class ExtensionMethods {

        public static void DisableAllLinks(this LinkLabel control) {
            foreach (LinkLabel.Link link in control.Links) {
                link.Enabled = false;
            }
        }

        public static void EnableAllLinks(this LinkLabel control) {
            foreach (LinkLabel.Link link in control.Links) {
                link.Enabled = true;
            }
        }

    }
}

And don’t forget to import the namespace that contains your extension methods where you will need them so they appear correctly.

N-Tier Architecture Best Practices, Part 2: 3-Tier Architecture with interfaces and a Data Tier

N-Tier Architecture Best Practices, Part 1: 2-Tier Architecture with just a Data Tier
N-Tier Architecture Best Practices, Part 2: 3-Tier Architecture with interfaces and a Data Tierthis article
N-Tier Architecture Best Practices, Part 3: DLinq / Linq to SQL
N-Tier Architecture Best Practices, Part 4: Entity Framework
N-Tier Architecture Best Practices, Part 5: Unity Framework

Download the Source Code for this Article
N-Tier Architecture (3-Tier)

In the previous article I covered 2-Tier Architecture with just a presentation layer and a data tier. In this article, I will show you how to expand this into a 3-tier architecture that will allow you to utilize your data tier with flexibility. You will need to download the source code from the previous article for this example, because I will be expanding upon it. You should already be very familiar with the code before proceeding.

Now let’s say you wanted to add a library to the project to handle all the rules of the business. This might be something like making sure that all employees in the company have valid pay rates and salaries. So we add a new Class Library project and call it NTier.BusinessRules along with a class called EmploymentValidation.

//-----------------------------------------------------------------------------
// <copyright file="EmploymentValidation.cs" company="DCOM Productions">
//     Copyright (c) DCOM Productions.  All rights reserved.
// </copyright>
//-----------------------------------------------------------------------------

namespace NTier.BusinessRules {
    using System;
    using System.Collections.Generic;
    using System.Linq;
    using System.Text;

    /// <summary>
    /// Validates employees to ensure their profiles meet business rules and standards
    /// </summary>
    public static class EmploymentValidation {
        /// <summary>
        /// Validates the specified pay rate
        /// </summary>
        public static bool ValidatePayrate(float rate) {
            if (rate < 0f) {
                return false;
            }
            return true;
        }
    }
}

Now this is great, because in NTier.Data.DataTier we can validate the employee’s payrate in AddEmployee and UpdateEmployee. So let’s add a reference to NTier.BusinessRules from NTier.Data and add our validation. Note that I will use an elipse ( … ) to represent sections of code we are not changing to help condense this post.

Changes to NTier.Data.DataTier.cs

namespace NTier.Data {
    using System;
    using System.Collections.Generic;
    using System.Data.SqlServerCe;
    using NTier.Data.Objects;
    using NTier.BusinessRules;
    ...
}
public static bool AddEmployee(NTier.Data.Objects.Employee employee) {
    if (!EmploymentValidation.ValidatePayrate(employee.Payrate)) {
        return false;
    }
    ...
}
public static bool UpdateEmployee(NTier.Data.Objects.Employee employee) {
    if (!EmploymentValidation.ValidatePayrate(employee.Payrate)) {
        return false;
    }
    ...
}

Okay, great; if we try to add or update an employee that has a payrate below 0, it will fail and that is what we want. Now this seems great, we just added validation to our project with ease. Now, what if your employee object actually has 50+ properties that need to be validated? Often times you want to keep your object itself simple. This will help you maintain it in the future, so the first thought is to pass the object itself to our validation library. Wait, we can’t!

NTier.Data references NTier.BusinessRules, therefore NTier.BusinessRules can never reference NTier.Data as this would cause a circular dependency. This is where 3-tier architecture using interfaces comes into play. We don’t need to pass the object itself, we can pass a contract that defines that object and stores the valuable information we need to validate. We don’t need anything else, but we need to add another new project called NTier.Common.Interfaces and our IEmployee interface to represent our object.

//-----------------------------------------------------------------------------
// <copyright file="IEmployee.cs" company="DCOM Productions">
//     Copyright (c) DCOM Productions.  All rights reserved.
// </copyright>
//-----------------------------------------------------------------------------

namespace NTier.Common.Interfaces {
    using System;
    using System.Collections.Generic;
    using System.Linq;
    using System.Text;

    /// <summary>
    /// Defines the base properties for an Employee
    /// </summary>
    public interface IEmployee {
        int ID { get; }
        string Email { get; set; }
        string FirstName { get; set; }
        string LastName { get; set; }
        float Payrate { get; set; }
        string Title { get; set; }
    }
}

Now first what we want to do is add a reference to NTier.Common.Interfaces from NTier.Data and derive Employee from IEmployee. Also don’t forget that because NTier.Presentation uses NTier.Data, it must also use NTier.Common.Interfaces, so we add that as a reference as well. Add your references, and make the following change to Employee.cs.

public class Employee : NTier.Common.Interfaces.IEmployee {
    ...
}

Now to resolve the circular dependency we are going to reference NTier.Common.Interfaces from NTier.BusinessRules. Add your reference, then make the following changes to EmploymentValidation.

namespace NTier.BusinessRules {
    ...
    using NTier.Common.Interfaces;

    ...
    public static class EmploymentValidation {
        ...

        /// <summary>
        /// Validates the specified employee
        /// </summary>
        public static bool ValidateEmployee(IEmployee employee) {
            if (string.IsNullOrEmpty(employee.FirstName))
                return false;
            if (string.IsNullOrEmpty(employee.LastName))
                return false;
            if (string.IsNullOrEmpty(employee.Title))
                return false;
            if (string.IsNullOrEmpty(employee.Email))
                return false;
            if (!ValidatePayrate(employee.Payrate))
                return false;
            return true;
        }
    }
}

Now notice that I left in the ValidatePayrate() method. This is because often times you are already using this in various portions of your software, and removing or changing this would be a breaking change that could break the software. So we’ll leave that in. But now you can see that we can pass in an interface of IEmployee and validate everything we need. But first, we need to go back and update our AddEmployee() and UpdateEmployee() methods in our data tier.

public static bool AddEmployee(NTier.Data.Objects.Employee employee) {
    if (!EmploymentValidation.ValidateEmployee(employee)) {
        return false;
    }
    ...
}
public static bool UpdateEmployee(NTier.Data.Objects.Employee employee) {
    if (!EmploymentValidation.ValidateEmployee(employee)) {
        return false;
    }
    ...
}

And, we’re done. We can pass around our IEmployee interface because it is shared among all the core libraries, where before we could not have passed around Employee due to circular dependencies. This is what 3-tier architecture with interfaces provides, flexibility and loose coupling between your libraries. Technically it is still pretty tightly coupled, but much more better than a 2-tier architecture.

Where we are at for September 2011

The last news post we had was ( gasp! ) 3 weeks ago regarding some news about BitFlex, and 4 weeks ago about FaultTrack. We’ve been really busy chugging away at preparing the new website changes for our flagship product and for customers, as well as on FaultTrack itself.

Since we’ve last posted a blog we’ve reworked many parts of FaultTrack and have fixed over 100 known bugs, and are still polishing it for release. Thanks to our private testers we have fixed numerous bugs and issues we would not have encountered otherwise, and some of them were nasty bugs. Never the less, progress is still underway and we are aiming to release this month, and very soon at that. The changes to the website are actually done for the most part, but still need QA tested and polished.

I can disclose some details about FaultTrack, so here we go with the most common question we’ve received. There will be a free edition.

Free Edition

  • 1 Team Collection
  • 1 Team Project
  • Does not come with Tier Instrumentation (read further on)

It was a tough decision if we were even going to have a free edition, but we thought it would be a good thing. Yes, it only comes with one team collection and one team project, but you can still work on a team on that project with unlimited accounts. If you need more than one project or collection, you will need to purchase the Full Edition for each member of the team, however.

Standard Edition

  • Unlimited Team Collections
  • Unlimited Team Projects
  • Tier Instrumentation
  • $39.99 Per Product Key License

Each user who needs access to more than a single Team Project or Collection must have their own unique and purchased product key. So basically, each individual must purchase a $39.99 product key license. This will unlock the full functionality of the application and give each member who has a Standard Edition key full access to work as a team and on multiple projects.

Both the Free Edition and Standard Edition will allow you to utilize user permissions and teams. The core of requiring a product key will be needing more than one Team Collection or more than one Team Project.

What we’ve been doing

We’ve made countless improvements to the user interface, performance and quality of FaultTrack. We’ve reworked some of the user interface a bit and also implemented a few additional features such as fault locking management for administrators, and multiple server management. We also made improvments in the database engine support for both MSSQL (SQL Server) and MySQL. Right now we are supporting SQL Server 2005, 2008, Azure, and 2008 R2, and MySQL 5.5. We will be doing some testing on other versions of MySQL server before release so we will have more information as that comes to pass.

We also are working with some private testers and collecting user experience feedback, and we are taking it very seriously. Based on our private testers feedback we may hold off on releasing or release sooner. But we are still aiming to release this month.

So keep your eyes peeled, because we will have another update soon and maybe even a video for you all featuring everything we’ve done to date to make FaultTrack what it is today.

N-Tier Architecture Best Practices, Part 1: 2-Tier Architecture with just a Data

Before I start off on my lengthy post, this article is what sparked my interest. With that linked for you, this will be split into a 5 part blog series each part covering a specific type of n-tier architecture. If there is not a link to the article it has not been published yet.

N-Tier Architecture Best Practices, Part 1: 2-Tier Architecture with just a Data Tierthis article
N-Tier Architecture Best Practices, Part 2: 3-Tier Architecture with interfaces and a Data Tier
N-Tier Architecture Best Practices, Part 3: DLinq / Linq to SQL
N-Tier Architecture Best Practices, Part 4: Entity Framework
N-Tier Architecture Best Practices, Part 5: Unity Framework

Download the Source Code for this Article
N-Tier Architecture (2-Tier)

In most projects you will have to communicate with other objects or a data tier (database engine, file system, or other data source), and passing your objects around can make for some complicated scenarios. One common rut that many developers find themselves in is circular-dependencies.

What is N-Tier Architecture?
N-Tier Archiecture is a term that refers to the number of assemblies, modules, or services that make up a system that allows its different parts to communicate with one another. An example would be a simple system that has some business objects and a database. You may have a module that handles the communication with the data tier, and also stores your business objects, and then maybe a second module that actually handles the processing of the objects such as input and change. This would be a 2-Tier architecture. A 3-Tier architecture would be something like having a module that stores interfaces that defines your business objects, another module that actually implements the business objects, and then a third module that again handles the input and change. N-Tier architecture can get vastly complex, especially in software applications like video games. Imagine a game engine where you have modules that must communicate with one another for handling rendering, player locations, particle effects, game data, network information. You can easily get into a complex system.

What I will cover

  • 2-Tier with just a data tier
  • 3-Tier with common interfaces, and a data tier
  • Briefly explain DLinq (Linq to Sql)
  • Briefly explain Entity Framework (Linq to Entities)
  • Briefly explain Unity Framework (Data Injection Framework)

Technologies we will be using for this article

  • C# 4.0
  • .NET 3.5
  • SQL Server CE

2TierSolutionStructure N Tier Architecture Best Practices, Part 1:  2 Tier Architecture with just a Data

2-Tier architecture with a Data Tier Project Structure (image to the left)
We are going to create a solution with two projects. The first, ‘NTier.Data’ will act as the Data Tier. Thie purpose of this is to act as the dependency for all other aspects of the software. It will store the database objects, as well as the class that handles communication between the objects and the database. The second will be ‘NTier.Presentation’, which acts as the executable that is actually used by the client as the UI, and in our case is a very simple Console Application.

The database
The database is just a SqlCe database with an Employees table. Our employee object will match the database schema perfectly in terms of its properties (ie. FirstName, LastName, Email, etc).

The code
There are only three class files, here is the code of all three.

//-----------------------------------------------------------------------------
// <copyright file="Employee.cs" company="DCOM Productions">
//     Copyright (c) DCOM Productions.  All rights reserved.
// </copyright>
//-----------------------------------------------------------------------------

namespace NTier.Data.Objects {
    using System;

    /// <summary>
    /// Represents a Employee in the data tier
    /// </summary>
    public class Employee {
        /// <summary>
        /// Gets the Employee's ID
        /// </summary>
        public int ID {
            get;
            internal set;
        }

        /// <summary>
        /// Gets or sets the Employee's email address
        /// </summary>
        public string Email {
            get;
            set;
        }

        /// <summary>
        /// Gets or sets the Employee's first name
        /// </summary>
        public string FirstName {
            get;
            set;
        }

        /// <summary>
        /// Gets or sets the Employee's last name
        /// </summary>
        public string LastName {
            get;
            set;
        }

        /// <summary>
        /// Gets or sets the Employee's payrate
        /// </summary>
        public float Payrate {
            get;
            set;
        }

        /// <summary>
        /// Gets or sets the Employee's title
        /// </summary>
        public string Title {
            get;
            set;
        }

        /// <summary>
        /// Overrides base.ToString()
        /// </summary>
        public override string ToString() {
            return string.Format("{0} {1}, {2}", FirstName, LastName, Title);
        }
    }
}
//-----------------------------------------------------------------------------
// <copyright file="DataTier.cs" company="DCOM Productions">
//     Copyright (c) DCOM Productions.  All rights reserved.
// </copyright>
//-----------------------------------------------------------------------------

namespace NTier.Data {
    using System;
    using System.Collections.Generic;
    using System.Data.SqlServerCe;
    using NTier.Data.Objects;

    /// <summary>
    /// Interactive class between business logic and the data tier
    /// </summary>
    public static class DataTier {

        private static string m_ConnectionString = @"Data Source=.\Northwind.sdf";
        /// <summary>
        /// Gets the connection string for SQL Server CE
        /// </summary>
        public static string ConnectionString {
            get {
                return m_ConnectionString;
            }
        }

        /// <summary>
        /// Adds the specified employee to the data tier
        /// </summary>
        public static bool AddEmployee(NTier.Data.Objects.Employee employee) {
            using (SqlCeConnection connection = new SqlCeConnection(ConnectionString))
            using (SqlCeCommand command = new SqlCeCommand(Properties.Resources.InsertCommandText, connection)) {
                command.Parameters.AddWithValue("@Email", employee.Email);
                command.Parameters.AddWithValue("@FirstName", employee.FirstName);
                command.Parameters.AddWithValue("@LastName", employee.LastName);
                command.Parameters.AddWithValue("@Payrate", employee.Payrate);
                command.Parameters.AddWithValue("@Title", employee.Title);
                try {
                    connection.Open();
                    return command.ExecuteNonQuery() == 1;
                }
                catch (System.Data.SqlServerCe.SqlCeException) {
                    return false;
                }
            }
        }

        /// <summary>
        /// Returns a collection of all the employee's in the data tier
        /// </summary>
        public static IEnumerable<NTier.Data.Objects.Employee> GetEmployees() {
            using (SqlCeConnection connection = new SqlCeConnection(ConnectionString))
            using (SqlCeCommand command = new SqlCeCommand(Properties.Resources.SelectCommandText, connection)) {
                try {
                    connection.Open();
                }
                catch (System.Data.SqlServerCe.SqlCeException) {
                    yield break;
                }
                using (SqlCeDataReader reader = command.ExecuteReader()) {
                    while (reader.Read()) {
                        Employee employee = new Employee();
                        employee.ID = (int)reader["ID"];
                        employee.Email = (string)reader["Email"];
                        employee.FirstName = (string)reader["FirstName"];
                        employee.LastName = (string)reader["LastName"];
                        employee.Payrate = (float)(double)reader["Payrate"];
                        employee.Title = (string)reader["Title"];
                        yield return employee;
                    }
                }
            }
        }

        /// <summary>
        /// Removes the specified employee from the data tier
        /// </summary>
        public static bool RemoveEmployee(NTier.Data.Objects.Employee employee) {
            using (SqlCeConnection connection = new SqlCeConnection(ConnectionString))
            using (SqlCeCommand command = new SqlCeCommand(Properties.Resources.DeleteCommandText, connection)) {
                command.Parameters.AddWithValue("@ID", employee.ID);
                try {
                    connection.Open();
                    return command.ExecuteNonQuery() == 1;
                }
                catch (System.Data.SqlServerCe.SqlCeException) {
                    return false;
                }
            }
        }

        /// <summary>
        /// Updates the specified employee's information in the data tier
        /// </summary>
        public static bool UpdateEmployee(NTier.Data.Objects.Employee employee) {
            using (SqlCeConnection connection = new SqlCeConnection(ConnectionString))
            using (SqlCeCommand command = new SqlCeCommand(Properties.Resources.UpdateCommandText, connection)) {
                command.Parameters.AddWithValue("@Email", employee.Email);
                command.Parameters.AddWithValue("@FirstName", employee.FirstName);
                command.Parameters.AddWithValue("@LastName", employee.LastName);
                command.Parameters.AddWithValue("@Payrate", employee.Payrate);
                command.Parameters.AddWithValue("@Title", employee.Title);
                command.Parameters.AddWithValue("@ID", employee.ID);
                try {
                    connection.Open();
                    return command.ExecuteNonQuery() == 1;
                }
                catch (System.Data.SqlServerCe.SqlCeException) {
                    return false;
                }
            }
        }
    }
}
//-----------------------------------------------------------------------------
// <copyright file="Program.cs" company="DCOM Productions">
//     Copyright (c) DCOM Productions.  All rights reserved.
// </copyright>
//-----------------------------------------------------------------------------

namespace NTier.Presentation {
    using System;
    using NTier.Data.Objects;
    using NTier.Data;
    using System.Collections.Generic;

    internal static class Program {
        /// <summary>
        /// Entry Point
        /// </summary>
        public static void Main() {
            Employee employee = new Employee();
            employee.Email = "danderson@dcomproductions.com";
            employee.FirstName = "David";
            employee.LastName = "Anderson";
            employee.Payrate = 35F;
            employee.Title = "President";
            DataTier.AddEmployee(employee);
            foreach (Employee item in DataTier.GetEmployees()) {
                Console.WriteLine(item.ToString());
                Console.ReadKey(true);
            }
            Console.Write("Press any key to exit...");
            Console.ReadKey(true);
        }
    }
}

Something to note is lines 33, 54, 81, 98 of Employee.cs. I saved the query texts in the project’s resource file to keep the code tidy.

Now you can write Program.cs to act however you want, and play with the code. In my example all I am doing is adding an employee to the table with my name, then enumerating the employees and listing them to the console window. Since each time you run my example it adds an employee with the same information and never removes it, you will have x(f) employees where f is the number of times the application has been launched, in the database with the same information.

What advantage does 2-Tier architecture serve?
Alright, in this 2-tier architecture, the advantage is its simple. That’s all there is to it. For each data tier object (ie. something that would need to be committed into a data source), you can simply create the object with its properties, and write the methods in your data tier class to do the work. The simplicity of being able to just pass your object is what makes it desireable. Also note that you do not have any complex dependencies between assemblies, thus you never have to worry about a circular dependency, and its extremely easy to note where everything is at in your project.

In large projects, your Objects folder would get rather large with data tier objects. Which is fine. The disadvantage of a 2-tier architecture is generally as your application becomes exceedingly complex, the simple structure of the project no longer becomes viable because its just not that flexible. Further down the road if you wanted to refactor your objects out of the data tier assembly into a 3-tier architecture, your data tier breaks because you can no longer pass the reference of the object. Thus bringing us into the next part of the blog series, 3-tier architecture.

When to use 2-Tier Architecture
When your requirements are simple and you have a minimal number of assemblies that must reference your business objects. More so, it is actually easier to explain when not to use 2-tier architecture. I’ve compiled a short list of the most common scenarios you should not use 2-tier architecture for.

  • An assembly needs to reference your business objects, but not have access to the data tier
  • You want to extend your business object with additional functionality, but not expose those new features to the data tier

Those are actually the only two reasons that come to mind immediately. If you have some other reasons you can think of that are good, throw a comment down and I will add it to the list. At any rate, the point is that 2-tier is easy to implement, and pretty easy to manage with little effort. The huge downside is once it becomes large, it will be hard to refactor later on. The next blog in the series will be on 3-tier architecture which I will hope to start writing by Monday.

Using ISynchronizeInvoke to update your UI safely from another Thread.

If you are still using .NET threads to do multi-threading in your applications (compared to the Task Parallel Library or something else), then it is often a mistake of developers on how they update their UI thread. First off, stay the heck away from CheckForIllegalCrossThreadCalls. If you want your application to have unpredictable behavior, throw intermittant exceptions, and have loads of problems then go right ahead. If you want to do things right, read on.

In the early days of .NET, it was common to implement the Invoke pattern which is actually more work than needed. Most if not all WinForms controls for example implement an interface called ISynchronizeInvoke. You can use this to easily update your controls safely from another thread, in a single line of code. Here is the implementation:

//-----------------------------------------------------------------------------
// <copyright file="ISynchronizedInvoke.cs" company="DCOM Productions">
//     Copyright (c) DCOM Productions.  All rights reserved.
// </copyright>
//-----------------------------------------------------------------------------

namespace YourApplication {
    using System;
    using System.Collections.Generic;
    using System.Linq;
    using System.Text;
    using System.ComponentModel;

    /// <summary>
    /// Helper class that allows synchronized invoking to be performed in a single line of code.
    /// </summary>
    internal static class SynchronizedInvoke {
        /// <summary>
        /// Invokes the specified action on the thread that the specified sync object was created on.
        /// </summary>
        public static void Invoke(ISynchronizeInvoke sync, Action action) {
            if (!sync.InvokeRequired) {
                action();
            }
            else {
                object[] args = new object[] { };
                sync.Invoke(action, args);
            }
        }
    }
}

This is just a helper class I usually include in all my WinForms projects as SynchronizedInvoke.cs. But the call is very simple. Let’s say you have a thread that runs a method called “ThreadWork” and you want to set the value of a progress bar you’ve named ‘uxProgressBar’ to 100 at the end of the method.

private void ThreadWork() {
    // Do some work on a thread
    SynchronizeInvoke.Invoke(uxProgressBar, () => uxProgressBar.Value = 100);
}

The key is the first parameter, also called the ‘sync’, is the object you want to invoke on, and the second is just an anonymous method (you can also specify an actual Action). There’s really nothing more to it, but you should also give a read to the article I wrote on using the Task Parallel Library titled ‘Writing thread-safe event handlers with the Task Parallel Library in .NET 4.0‘ which in my opinion is a better way to perform threaded operations and UI updates.