Here is a very nicely done, informative article about delegates that I should have read (I probably would have gotten to my solution quicker and surpassed my trial and error issues):  http://www.ondotnet.com/pub/a/dotnet/2002/11/04/delegates.htm

I used the following two articles as a basis for my fix:

• http://msdn2.microsoft.com/en-us/library/ms951089.aspx
• http://www.ondotnet.com/pub/a/dotnet/2003/02/24/asyncdelegates.html?page=1

However, I didn’t end up using the MulticastDelegate class at all in my solution.  It’s not really necessary, and I couldn’t get it to work when I tried to extend or inherit from it.  The following article says you can’t anyway, unless you are a compiler or some similar tool:  http://msdn2.microsoft.com/en-us/library/system.multicastdelegate.aspx

This link has a cool helper class for asynchronous delegates, though I didn’t use it:  http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind0302B&L=ADVANCED-DOTNET&T=0&F=&S=&P=31992

Good luck.

FOLLOWUP (05/21/09):  I have some further clarifications about how to properly invoke delegates to a new background thread in this post:

BeginInvoke Methods and OneWay Attribute

So after searching around, I tried a few solutions people said helped them solve the problem.  Some of the simple and straight forward ones I tried were simply restarting the IDE and doing a clean on the solution; I even resorted to a machine reboot.  I next tried all of the applicable solutions from this Microsoft article:  http://support.microsoft.com/kb/329214 (or this one says the same thing basically:  http://msdn2.microsoft.com/en-us/library/ms228633(VS.80).aspx).  I also found another guy that said to try doing a regsvr32 on ole32.dll.  By the way, here is the typical location of mergemod.dll:  C:\Program Files\Common Files\Microsoft Shared\MSI Tools\ and here is the typical location of ole32.dll:  C:\WINDOWS\System32\.

None of it seemed to help my situation.  So I tried uninstalling Visual Studio, and then uninstalling all versions of the .NET Framework with the help of this handy tool:  http://blogs.msdn.com/astebner/archive/2006/05/30/611355.aspx.Then I went ahead and reinstalled everything and gave it a nice machine reboot.  Even this charade proved unsuccessful.

The good news in all of this was that I am still currently the only developer that cannot build this deployment project.  So it is definitely something with my machine that is the problem and not with the actual deployment project itself (we were concerned for a little while about the "multiple folders with the same name" issue mentioned in the Microsoft articles).

So when I get time, I may try to do an OS reinstall and be extra careful of what and when stuff gets installed.  Luckily I have got my personal files on a separate partition, so only the system partition will have to be blown away.  If this proves successful, which it should, I will make an additional note to this post.  Good luck if you ever get this same problem.

FOLLOWUP (01/18/08):  So it turns out that my computer actually crashed a few days later.  When I formatted my hard drive and did a fresh install of Windows, everything seemed to be fine again so I didn’t question the hardware anymore.  Then I turned on the 3GB Windows switch for Windows and everything went haywire.  I removed 2 of my 4 GB of RAM and then everything was fine.  I tried all kinds of combinations with different memory sticks in different memory slots with different totals of RAM.  It seemed I could only run in 3GB Windows mode with 2 GB of RAM; however, in normal Windows mode, I could successfully run with all 4 GB of RAM.  So I opted for the 4 GB and will continue to allow someone else to build the monster deployment project, which he has been able to do every time without any issues using the 3GB Windows switch.

FOLLOWUP (06/17/08):  For the last 6 months, I have tried two or three times to get another machine to build these installers using the 3GB Windows boot switch and modifying the DevEnv.exe executable to be "Large Address Aware"; all of my attempts have been unsuccessful.  Currently, we only have one guy’s laptop that can handle the build and is running stable with the 3GB switch (and we have no clue why it works).  He has been using a local account on his machine for like 9 months and he just recently switched to a domain account.  The interesting thing is that we could no longer build the installers anymore.  But when we went back to using a regular local account (not on the domain), his laptop was able to build the installers again.  With that knowledge, I just now tried building the installers on my machine using a local account; unfortunately, it was unsuccessful.  However, I also don’t have the 3GB switch turned on.  Perhaps the combination of the two is why his laptop is able to build the installers.  I may finish this test of my hypothesis soon, but not right now.

FOLLOWUP (06/18/08):  I got it working!!!  The problem was being logged in with a domain user account for some reason.  I am really not sure why; there must be something different about using a domain user account (perhaps during the login process or some restriction set on our domain user accounts or policies).  I did test it without the changes involving the 3GB switch, but they are necessary as well.  In fact in my setup, I also didn’t put the box on the domain at all, just to be sure.  The box runs very stable as far as I can tell with these modifications to Windows and the Visual Studio executable.

1. I would first back up your boot.ini before making this edit.  It is located right in the root of your C: drive and it is a hidden, system file (so change your folder options to display hidden files).  You will need to add the /3GB switch to the end of the line with the OS that you will be using to build your deployment project, found under the [operating systems] section.  Again, refer to the above link for more information about where exactly to put the switch.
2. It would be wise to also back up your devenv.exe (Visual Studio executable) before making this change as well.  It is located under the C:\Program Files\Microsoft Visual Studio 8\Common7\IDE (or Microsoft Visual Studio 9.0 for VS 2008) directory if you went with the default installation location.  You will need to open a Visual Studio 2005 Command Prompt (or 2008 works too), which loads some custom paths and environment variables different from a standard command prompt.  It’s found by going to Start Menu | All Programs | Microsoft Visual Studio 2005 | Visual Studio Tools.  When the command window comes up, change your directory to where the VS executable is (e.g., cd ..\Common7\IDE).  Next run the following command:  editbin.exe /LARGEADDRESSAWARE devenv.exe
3. Now reboot the machine and try rebuilding the deployment project again.

If you have time, change the whole architecture of your program and development solution; otherwise, good luck.

FOLLOWUP (06/17/08):  You should check out the next blog post after this one about an error I got later using this fix.  We do have a guy’s laptop in our company that is stable using this fix, but I have tried without success to get 2 or 3 other machines to do the same.  It also might have something to do with domain user accounts vs. local user accounts.

FOLLOWUP (06/18/08):  I got it working!!!  The problem was being logged in with a domain user account for some reason.  I am really not sure why; there must be something different about using a domain user account (perhaps during the login process or some restriction set on our domain user accounts or policies).  I did test it without the changes involving the 3GB switch, but they are necessary as well.  In fact in my setup, I also didn’t put the box on the domain at all, just to be sure.  The box runs very stable as far as I can tell with these modifications to Windows and the Visual Studio executable.