Shortly after setting up a RAM disk using the freeware version of Dataram RAMDisk to see whether Visual Studio 2010 might compile a huge solution faster, I began getting the following errors after relocating the system's temp files to the root of the RAM drive:
The "GenerateResource" task failed unexpectedly.
System.TypeInitializationException:
The type initializer for 'Microsoft.Build.Utilities.FileTracker' threw
an exception. ---> System.NullReferenceException: Object reference
not set to an instance of an object.
I dug around and found numerous references to existing bug reports and a few workarounds. I tried unsetting the readonly file system attribute in my solution folder, setting the GenerateResourceNeverLockTypeAssemblies property in my project file to true or false to downgrade some security parameters, but ultimately it was the top answer here that did the trick.
I had set the environment variables for the RAM drive initially to just R:\, referencing the root of the drive. Apparently VS 2010 doesn't like this, so I simply created a new folder on my ram disk named TEMP, and then updated the environment variables accordingly:
Just to rule it out, and also because I hadn't rebooted Windows in a while, I also opened Control Panel => Programs and Features, and performed a Repair on Microsoft .NET Framework 4 Client Profile just in case the framework files might've gotten corrupted somehow, and then restarted.
Problem solved! Now on to see whether Joseph Fluckiger's experimentation which returned lukewarm results on performance of building to a RAM disk holds water for a solution with, say, dozens of projects.
When trying to do a disk and partition backup on Acronis True Image Home 2012 build 7133 to an external USB drive, the backup failed repeatedly with a read error.
Upon contacting Acronis support, at first I got a suggestion that the error had been "fixed" in the latest version, and that I should upgrade to the 2013 version of the software. Conveniently, the support tech I'd been corresponding with provided me with an affiliate link to purchase the new version.
It seemed rather odd that a support tech would provide an affiliate link to purchase an upgraded version of the product rather than help with the customer's current version. I decided, instead, to press the issue and fork over $9.99 for a paid support incident. My case then got reassigned to someone who seemed to be more on the ball, and asked me to take some basic troubleshooting steps, including scanning my C: drive, which happens to be an Intel SSD, with the chkdsk utility, revealed so issues whatsoever.
Subsequent back and forth with the support technician proved largely unhelpful until they asked me to try backing up a single file or folder rather than a whole partition. I then tried backing up the My Documents folder, and it failed quickly with an error stating the system couldn't find the path R:\TEMP, which happened to be associated with a RAM drive I'd had set up until recently.
I remembered that in the time between making my last successful backup using Acronis, I'd uninstalled QSoft RAMDisk, a utility which enables you to use a portion of your system memory as a very fast RAM drive. Trying to create a backup with Acronis since the RAM drive had been uninstalled proved fruitless because Acronis seemingly balked at not being able to find the RAM drive registered with Windows any longer.
Serendipitously, the developer of the RAM drive software released an updated build of their software earlier this month, so I decided to reinstall it and give it a try. I installed the software, then set up a RAM drive with the same drive letter as I'd originally used.
Upon reinstalling the RAM drive and rebooting, the backup proceeded successfully.
The moral of the story appears to be, if you happened to have a RAM drive installed on your system at some point prior to having Acronis installed, you'd best make sure the RAM drive is existant so that Acronis won't complain and decide to no longer complete your backups.
