If only we could store all our assemblies in a single folder, say “C:\References” and have our applications use the assemblies in that folder. Well we can, but it requires more work than you think.

Let’s look into a simple example. [The example is intended to display the core issue with assembly versioning, not give lesson in architecture] We have two programs: Program1.exe and Program2.exe. Both programs reference “C:\References\BusinessLayer.dll”. Two Visual Studio Builds produce:

C:\OutputDirectory\Bin\Debug\Program1.exe
C:\OutputDirectory\Bin\Debug\BusinesLayer.dll (v1.0)
AND
C:\OutputDirectory2\Bin\Debug\Program2.exe
C:\OutputDirectory2\Bin\Debug\BusinesLayer.dll (v1.0)

Now, we update Program2.exe with some new functionality. We also update BusinessLayer.dll and deploy it to “C:\References”. A Visual Studio Build of Program2 produces:

C:\OutputDirectory2\Bin\Debug\Program2.exe
C:\OutputDirectory2\Bin\Debug\BusinesLayer.dll (v1.1)

Program 1 still looks like:
C:\OutputDirectory\Bin\Debug\Program1.exe
C:\OutputDirectory\Bin\Debug\BusinesLayer.dll (v1.0)

Woops, we are out of sync. Visual Studio does NOT use our original reference location after the build! It makes a copy of the file FROM that location.

Ok, so Team Foundation Server (TFS) setup for Continous Integration can solve this right? Yes, but TFS requires alot of maintenance and setup for each solution. There’s gotto be another way (and cheaper).

MSDN tells us how to load an assembly outside the bin directory. Our options are GAC, a config file or source code.

GAC: Managing assemblies in the GAC can get a little tricky. Not to mention, Referencing Assemblies from the GAC requires adding registry entries, so lets shelve that idea.
Config file: A config file is nice, but requires adding a version#. That just shifts our sync problem to config files…so lets drop that idea.

What about source code?

If we take the source code from MSDN and wrap it up in an assembly, we can add direct referencing capability to all our applications by deploying this assembly to the GAC. The following code allows one to do just that. Simply take this code and make a DLL out of it. Then, deploy it to the GAC. OR download the one I made and drag-drop it to C:\windows\assembly

using System;
using System.Reflection;

namespace BMackeyUtilities
{
    public class Utility
    {
        public static void ImportAssemblies()
        {
            AppDomain.CurrentDomain.AssemblyResolve += new ResolveEventHandler(MyResolveEventHandler);
        }
        private static Assembly MyResolveEventHandler(object sender, ResolveEventArgs args)
        {
            //This handler is called only when the common language runtime tries to bind to the assembly and fails.

            //Retrieve the list of referenced assemblies in an array of AssemblyName.
            Assembly MyAssembly, objExecutingAssemblies;
            string strTempAssmbPath = "";

            objExecutingAssemblies = Assembly.GetEntryAssembly();//.GetExecutingAssembly();//Get the exe assembly
            AssemblyName[] arrReferencedAssmbNames = objExecutingAssemblies.GetReferencedAssemblies();

            //Loop through the array of referenced assembly names.
            foreach (AssemblyName strAssmbName in arrReferencedAssmbNames)
            {
                //Check for the assembly names that have raised the "AssemblyResolve" event.
                if (strAssmbName.FullName.Substring(0, strAssmbName.FullName.IndexOf(",")) == args.Name.Substring(0, args.Name.IndexOf(",")))
                {
                    //Build the path of the assembly from where it has to be loaded.
                    strTempAssmbPath = "C:\\References\\" + args.Name.Substring(0, args.Name.IndexOf(",")) + ".dll";
                    break;
                }

            }
            //Load the assembly from the specified path.
            MyAssembly = Assembly.LoadFrom(strTempAssmbPath);

            //Return the loaded assembly.
            return MyAssembly;
        }
    }
}

Going back to Program1.exe and Program2.exe. I add myAssemblyInGac.dll to both programs. See how to add a reference to a file in the gac (just add a registry key to HKLM\SOFTWARE\MICROSOFT\.NETFRAMEWORK\AssemblyFolders\ and set the “Default” string value to C:\References). Then, add the following line of code to the first line in Main() in all your programs:

BMackeyUtilities.Utility.ImportAssemblies();

Now, everytime I update BusinessLayer.dll and copy it to “C:\References”, both of my programs are in sync. Imagine the time and frustration this saves with 10+ exe’s!

I know this is alot to swallow so hit me up with questions/comments!!

using System;
using FactoryPattern;

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            RunFactory();
        }

        private static void RunFactory()
        {
            IType[] objects = new IType[2];
            objects[0] = AFactory.MakeType(AFactory.Types.Type1);
            objects[1] = AFactory.MakeType(AFactory.Types.Type2);

            foreach (IType t in objects)
            {
                Console.WriteLine("Name: {0}",t.Name);
                t.DoSomething();
            }
        }
    }
}
namespace FactoryPattern
{
    public class AFactory
    {
        public enum Types { Type1, Type2 };

        public static IType MakeType(Types type)
        {
            switch (type)
            {
                case Types.Type1:
                    return new Type1();
                case Types.Type2:
                    return new Type2();
                default:
                    return new Type1();
            }
        }
    }
    public interface IType
    {
        string Name { get; set; }
        void DoSomething();
    }
    public class Type1 : IType
    {
        private string _name;

        public Type1():this("default")//call Type1(string) constructor
        {
        }

        public Type1(string Name)
        {
            _name = Name;
        }

        #region IType Members

        public string Name
        {
            get
            {
                return _name;
            }
            set
            {
                _name = value;
            }
        }

        public void DoSomething()
        {
            Console.WriteLine("Did something");
        }

        #endregion
    }

    public class Type2 : IType
    {
        private string _name;

        public Type2():this("default2")
        {
        }

        public Type2(string Name)
        {
            _name = Name;
        }

        #region IType Members

        public string Name
        {
            get
            {
                return _name;
            }
            set
            {
                _name = value;
            }
        }

        public void DoSomething()
        {
            Console.WriteLine("Did something else");
        }

        #endregion
    }
}

Here’s a simple example of a C++ DLL and a C# assembly interoperating.

–Inside C++ expose a method to C# with
extern “C” __declspec(dllexport) short Add(long a, long b);

–in C# import the C++ method with
[DllImport(@"C:\Users\Brian\Documents\Visual Studio 2008\Projects\ManagedCpp\Win32TestsTry2\Win32Tests\Win32Tests\Debug\UnmanagedDll.dll", CharSet = CharSet.Ansi)]
static extern short Add(int a, int b);

Now C# can call the C++ just like this:
short answer = Add(1, 1);

Feel free to download the C++ and C# full solution files (Visual studio 2008) I use for this post.

Note, C# and C++/CLI (managed) DLL’s (technically assemblies) can certainly work together too. From the C# project, simply add a reference to the C++ assembly.

The article begins with a metaphor relating programming to war. Basically, programming becomes crossing a “minefield” where the best solution is to stab every square inch of ground with a bayonette in order to avoid death. If I viewed programming in this way I would never get past “hello world” without writing a hundred unit tests for every possible spelling variation, disability, language barrier, and hardware incompatability. Not to mention, I’d be shot by the enemy before crossing any reasonably sized territory.

The fact of the matter is that we all “program by necessity”. We shouldn’t program for every risk in every scenerio. We should be aware of our shortcuts and take the ones that cost the least. Be mindful of the software development triangle while avoiding rigidity.

They go on to say
“Don’t code blindfolded. Attempting to build an application you don’t fully understand, or to use a technology you aren’t familiar with, is an invitation to be misled by coincidences.”

I am reminded of Star Wars Programming:
“All requirements documentation must be agreed to before any design or coding and must be cast in stone with formal signatures and harsh penalty clauses for failure to deliver (see Death Star).”

In order to fully understand an application, we must take the time to plan the requirements and fully understand all technolgies involved from beginning to end. This is impractical. Oftentimes, a single businessman does not fully understand all processes within the company. Meeting a representative of each position is also impractical. Often, scheduling does not a programmer to learn all jobs. Therefore, we usually build programs with an incomplete picture of that which we are automating.

So what can we do? Unfortunetly, a programmer cannot solve all these problems alone. We depend on our superiors to accept our input at face value. The good news is that we have a common interest in creating a successful product. Management should regard programmers as people they work with rather than people that need to be governed. Most programmers want to write great code. Communication needs to be open and often. Programmers and Managers should work together to determine the best approach for a product on a regular basis.

Programmers should be flexible as well. Few enjoy re-writes, but its a necessary task. Write manageable and maintainable code. Management should watch out for turnover and check references on contractors. I’ve seen programmers who write unmaintainable code only to exit the company when the time comes to maintain it. Its difficult (especially for a new hire) to explain why code that worked fine until now, is complete garbage.

There’s so many things that can and do go wrong. The most important thing a business can do is hire honest programmers and listen to them when they say “that’s a bad idea” in regards to technical problems. While, programmers need to keep in mind that businesses have a limited budget and tight schedule.

Above all, strive for perfection with no real expectation of achieving it.

With one exception, app.config files should be added to the project that produces the executable file. When you build the project with the executeable the app.config
will be output in the form “ProjectName.exe.config”. While it is possible to add an app.config to a class library; its a bad idea. The app.config file will not be visible to the executeable
or even the class library within the context of the exe Process.

#Dont do this
It is possible to output an app.config in a class library project and have it useable within an exe. Rename the config file and set the “copy to output directory” to “copy always”. For example, rename the app.config to “FutureExeProjectName.exe.config”. This is bad practice. You are hard coding a library to a single exe, so there’s hardly any reason to have a library in the first place. Libraries are for sharing right?? Not to mention, that you will run into some interesting troubleshooting if you decide to consume the library with another exe in the future.

The exception to the rules comes with visual studio’s “test project” template. These “test project”/unit test projects are actually class Libraries.
These class libraries can be treated just as if they were an exe. MSTest actually handles the execution, but this is invisible to us.

To recap:
1. Always add app.config to the executeable project.
2. If you are unit testing with the “test project” template, then consider the test project the executeable project.
3. Don’t add app.config anywhere else.

“NetConnectionID” from Win32_NetworkAdapter is the same name you will see in IPConfig “Local Area Connection”, for example. You can relate Win32_NetworkAdapter to Win32_NetworkAdapterConfiguration with the “Index”. This is exactly what I’ve done below. From there, you can query anything you want from the Properties list for the Win32_NetworkAdapter or Win32_NetworkAdapterConfiguration see the links for a full list of properties available.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Management;
using System.Configuration;

namespace ConsoleApplication3
{
    class Program
    {
        static void Main(string[] args)
        {
            const string a1 = "Local Area Connection";
            const string a2 = "Local Area Connection 2";

            AdapterInfo adapter1 = new AdapterInfo(a1);
            AdapterInfo adapter2 = new AdapterInfo(a2);
            AdapterInfo[] adapters = new AdapterInfo[2];
            adapters[0] = adapter1;
            adapters[1] = adapter2;

            try
            {
                ManagementObjectSearcher getAdapterNames =
                    new ManagementObjectSearcher("root\\CIMV2",
                    "SELECT Index, NetConnectionID FROM Win32_NetworkAdapter WHERE NetConnectionID = '" + adapter1 + "' OR NetConnectionID = '" + adapter2 + "'");

                foreach (ManagementObject queryObj in getAdapterNames.Get())
                {
                    string ncid = (string)queryObj["NetConnectionID"];
                    UInt32 index = (UInt32)queryObj["Index"];
                    if(ncid == adapter1.ToString())
                    {
                        adapter1.Index = index;
                    }
                    else if (ncid == adapter2.ToString())
                    {
                        adapter2.Index = index;
                    }
                }
                //view list of all available properties for Win32_NetworkAdapterConfiguration at http://msdn.microsoft.com/en-us/library/aa394217(VS.85).aspx
                ManagementObjectSearcher getIPSubnet =
                    new ManagementObjectSearcher("root\\CIMV2",
                    "SELECT IPAddress, IPSubnet, Index FROM Win32_NetworkAdapterConfiguration WHERE Index = " + adapter1.Index + " OR Index = " + adapter2.Index);

                foreach (ManagementObject ipsub in getIPSubnet.Get())
                {
                    UInt32 index = (UInt32)ipsub["Index"];
                    string[] ipAddress = (string[])ipsub["IPAddress"];
                    string[] subnet = (string[])ipsub["IPSubnet"];

                    if (ipAddress == null || subnet == null)
                        continue;

                    if(index == adapter1.Index)
                    {
                        adapter1.IPAddress = ipAddress[0];
                        adapter1.SubnetMask = subnet[0];
                    }
                    else if(index == adapter2.Index)
                    {
                        adapter2.IPAddress = ipAddress[0];
                        adapter2.SubnetMask = subnet[0];
                    }
                }
                foreach (AdapterInfo adapter in adapters)
                {
                    Console.WriteLine("NetConnectionID: {0}\nIndex: {1}\nIPAddress: {2}\nSubnetMask: {3}", adapter.NetConnectionID, adapter.Index, adapter.IPAddress, adapter.SubnetMask);
                }
            }
            catch (ManagementException e)
            {
                Console.WriteLine("An error occurred while querying for WMI data: " + e.Message);
            }

        }
        class AdapterInfo
        {
            public string NetConnectionID { get; set; }
            public UInt32 Index { get; set; }
            public string IPAddress { get; set; }
            public string SubnetMask { get; set; }
            public AdapterInfo(string Name)
            {
                NetConnectionID = Name;
            }
            public override string ToString()
            {
                return this.NetConnectionID;
            }
        }

    }

}

using System;
using System.Runtime.InteropServices;
using System.Security.Principal;
using System.Security.Permissions;
using System.IO;

[assembly: SecurityPermissionAttribute(SecurityAction.RequestMinimum, UnmanagedCode = true)]
[assembly: PermissionSetAttribute(SecurityAction.RequestMinimum, Name = "FullTrust")]
public class TestAuthentication
{
    [DllImport("advapi32.dll", SetLastError = true, CharSet = CharSet.Unicode)]
    public static extern bool LogonUser(String lpszUsername, String lpszDomain, String lpszPassword,
        int dwLogonType, int dwLogonProvider, ref IntPtr phToken);

    [DllImport("kernel32.dll", CharSet = CharSet.Auto)]
    public extern static bool CloseHandle(IntPtr handle);

    [PermissionSetAttribute(SecurityAction.Demand, Name = "FullTrust")]
    public static void Main(string[] args)
    {
        IntPtr tokenHandle = new IntPtr(0);
        IntPtr dupeTokenHandle = new IntPtr(0);
        try
        {
            string userName, domainName;
            // Get the user token for the specified user, domain, and password using the
            // unmanaged LogonUser method.
            // The local machine name can be used for the domain name to impersonate a user on this machine.
            Console.Write("Enter the name of the domain on which to log on: ");
            domainName = Console.ReadLine();

            Console.Write("Enter the username on {0} that you wish to impersonate: ", domainName);
            userName = Console.ReadLine();

            Console.Write("Enter the password for {0}: ", userName);

            const int LOGON32_PROVIDER_DEFAULT = 0;
            //This parameter causes LogonUser to create a primary token.
            const int LOGON32_LOGON_INTERACTIVE = 2;

            tokenHandle = IntPtr.Zero;

            // Call LogonUser to obtain a handle to an access token.
            bool returnValue = LogonUser(userName, domainName, Console.ReadLine(),
                LOGON32_LOGON_INTERACTIVE, LOGON32_PROVIDER_DEFAULT,
                ref tokenHandle);

            Console.WriteLine("LogonUser called.");

            if (false == returnValue)
            {
                int ret = Marshal.GetLastWin32Error();
                Console.WriteLine("LogonUser failed with error code : {0}", ret);
                throw new System.ComponentModel.Win32Exception(ret);
            }

            Console.WriteLine("Did LogonUser Succeed? " + (returnValue ? "Yes" : "No"));
            Console.WriteLine("Value of Windows NT token: " + tokenHandle);

            // Check the identity.
            Console.WriteLine("Before impersonation: "
                + WindowsIdentity.GetCurrent().Name);
            // Use the token handle returned by LogonUser.
            WindowsIdentity newId = new WindowsIdentity(tokenHandle);
            WindowsImpersonationContext impersonatedUser = newId.Impersonate();

            // Check the identity.
            Console.WriteLine("After impersonation: "
                + WindowsIdentity.GetCurrent().Name);

            CheckAccessForImpersonatedUser();

            // Stop impersonating the user.
            impersonatedUser.Undo();

            // Check the identity.
            Console.WriteLine("After Undo: " + WindowsIdentity.GetCurrent().Name);

            // Free the tokens.
            if (tokenHandle != IntPtr.Zero)
                CloseHandle(tokenHandle);

        }
        catch (Exception ex)
        {
            Console.WriteLine("Exception occurred. " + ex.Message);
        }

    }

    private static void CheckAccessForImpersonatedUser()
    {
         //Perform an action to test priviledges
        bool ret = File.Exists(@"C:\myfile.txt");//This will report false if you dont have the correct permissions
    }
}

I’ll leave you with a fairly simple code example to demonstrate the basic usage of AutoResetEvent.

class Program
    {
        static AutoResetEvent[] ares;

        static void Main(string[] args)
        {
            ares = new AutoResetEvent[] { new AutoResetEvent(false), new AutoResetEvent(false) };//Create an event for each thread

            Thread htxThread = new Thread(GetCompanyXCustomers);
            htxThread.Start();

            Thread txtThread = new Thread(GetCompanyYCustomers);
            txtThread.Start();

            WaitHandle.WaitAll(ares);//Wait until we get all the customers

            //continue work
        }

        private static void GetCompanyXCustomers()
        {
            Thread.Sleep(2000);//do work
            Console.WriteLine("Company X customers received");
            ares[0].Set();//signal finished
        }

        private static void GetCompanyYCustomers()
        {
            Thread.Sleep(4000);//do work
            Console.WriteLine("Company Y customers received");
            ares[1].Set();//signal finished
        }

    }

SELECT * FROM [SERVER\MyInstanceName].[DatabaseName].[TableName] (or just [SERVER] for the default instance).

Getting the initial linked server setup can be a little challenging, but the following code syntax worked for me:

EXEC  sp_addlinkedserver @server= [SERVER\sqlexpress], @srvproduct= '', @provider= N'SQLNCLI', @datasrc= [SERVER\sqlexpress]
		EXEC sp_addlinkedsrvlogin
			@rmtsrvname = [SERVER\sqlexpress]
			, @useself = 'FALSE'
			, @locallogin = NULL
			, @rmtuser = 'sa'
			, @rmtpassword = 'uuuu'

This will ensure the same SQL account is used across all linked database calls.

As any beginner should do, I’m reading through the documentation (part of the WDK download). I’ll post the next intersting tidbit that comes along.