"Unrecoverable Build Error" When Building Very Large VS Deployment Project

So after being able to successfully build that large deployment project I was talking about by using the 3GB switch, a day or two later I began getting an "Unrecoverable build error" message accompanied with a "Send Error Report" dialog.  It didn't kill the IDE process, but did stop the installer build.  I verified that I was able to build other deployment and non-deployment projects without any problems.

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.

View Full Article

Building a Monster VS 2005 (or 2008) Deployment Project

So I don't think I want to get into the details of why we have a solution with over 50,000 unchanging content files in it, but basically we were handed a legacy set of Java/Apache web products and were asked to migrate it to .NET with an aggressive deadline.  Anyway, we try to compress this thing up into an MSI file using a deployment project.  We were getting an error before it would start packaging the files that said "Not enough storage is available to complete this operation" and it would be on a different file every time.  It appears it means the process ran out of virtual memory.

When trying to figure out why, we tried a few things that would sometimes work, most notably, restarting the IDE and/or the whole machine.  Then we came upon the following article that informed us that Windows has a hard-coded 2 GB limit for any given process:  http://www.microsoft.com/whdc/system/platform/server/PAE/PAEmem.mspx

So here are the steps to up the process virtual memory limit to 3 GB and also to make the Visual Studio executable aware of this raised limit:

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.

View Full Article

Linux Quote

I don't know who said it, and I'm not really quoting it verbatim either; but who cares I still like it:

"Linux is great, just like C is great; it's useful, powerful, and can blow your leg off if you're not careful."

View Full Article

InsertGuid Visual Studio Macro

If you ever work on a project or installer that requires you to create some GUIDs frequently, you should make your life easier by creating a Visual Studio macro that will insert a GUID wherever your cursor is. Here's how to do it:

Create the Macro

• Bring up the "Macro IDE" window in Visual Studio by pressing Alt+F11.
• Right-click on MyMacros and select Add Module; alternatively, you can just rename Module1 instead of creating a new module. Enter in GuidModule as the name.
• Copy and paste the following code between Public Module GuidModule and End Module:

REM Insert a new Guid at whatever the cursor has selected
Sub InsertGuid()
   Dim ts As TextSelection = ActiveDocument().Selection
   Dim guid As System.Guid = System.Guid.NewGuid()
   ts.Insert(guid.ToString().ToUpper())
End Sub

• Be sure to save the changes and close the "Macro IDE" window.

Assign a Keyboard Combination

• Back at the main Visual Studio window, go to Tools Options... and then navigate to Environment Keyboard.
• Type InsertGuid into the Show Commands Containing text field and select the macro you just created (Macros.MyMacros.GuidModule.InsertGuid).
• Put the cursor in the Press shortcut keys text field and type a keyboard combination (I have opted to use Alt+G).
• Click on Assign (be careful, as it will replace any existing binding for that key).

View Full Article

Check if the Current User is an Administrator

public static bool IsCurrentUserAdministrator()
{
    AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal);
    WindowsPrincipal principal = (WindowsPrincipal)Thread.CurrentPrincipal;
    return principal.IsInRole(WindowsBuiltInRole.Administrator);
}

View Full Article