Skip to content

Visual Studio, Ramdisk and Temp Folder Annoyance

I just tried to compile an old project with new Visual Studio, and run into unexpected, and for me, yet unseen errors. It took some scratching in the head, and googling around to find the reason. So here is thing: if you are using a ram disk for your temporary folder, visual Studio will for some reason choke and refuse to compile.

Noteworthy to say is that I did some fiddling with the system and am now using an imdisk ram drive. Visual Studio however does not seem to like us to use ram disks for some reason.

If I try to compile anything, even simplest “hello world”, I get this error:

1>------ Build started: Project: ConsoleApplication1, Configuration: Debug Win32 ------
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(341,5): error MSB4018: The "CL" task failed unexpectedly.
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(341,5): error MSB4018: 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.
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(341,5): error MSB4018:    at Microsoft.Build.Utilities.FileTracker..cctor()
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(341,5): error MSB4018:    --- End of inner exception stack trace ---
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(341,5): error MSB4018:    at Microsoft.Build.CPPTasks.CL.ComputeOutOfDateSources()
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(341,5): error MSB4018:    at Microsoft.Build.CPPTasks.TrackedVCToolTask.SkipTaskExecution()
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(341,5): error MSB4018:    at Microsoft.Build.Utilities.ToolTask.Execute()
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(341,5): error MSB4018:    at Microsoft.Build.CPPTasks.TrackedVCToolTask.Execute()
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(341,5): error MSB4018:    at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(341,5): error MSB4018:    at Microsoft.Build.BackEnd.TaskBuilder.d__20.MoveNext()
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

Ugly, non-informative and nasty (well if you are into .NET you might know what FileTracker is and so on, but I am not). This message left me totally clueless about what is cause to null exception, and made me spend some time searching over the web and seeing all kind of weird tips, like reinstalling visual studio (yeah sure – I am not spending an hour on that one :-)).

As usually these days, I have found answer on StackOverflow: problem seems to be the moved temporary folder. For some reason Visual Studio is always expecting a folder for temporary files. What I did was just to use x: as a root for all junk (x is my ram disk drive). Even some other applications, like MSPaint 🙂 choked on that one. Solution is to just specify x:\temp as a value of Temp and Tmp environment variables.

This simple thing took at least 2 hours to figure out. One of problems I encountered is that you can’t just change environment variable and restart Visual Studio. It works for PATH variable, but not for TEMP/TMP seems like. One has to restart the computer for this one :-(. Nasty thing is that I tryed to trick VS with a junction in %userprofile%/appdata/local. I created a junction Temp, to point to ram drive, while I still used just whole drive as scratch folder (junction pointing just to x:). It worked if junction was created AFTER the Visual Studio was started, but if system was started from scratch and Visual studio started a new, I got an error message (different one) and compile failed with yet another clueless message different from the first one. Re-createing junction, got VS in sane state again. It was just so weird untill I realized I do have to make a directory on ram disk for Temp folder and to restart the system. Now whole system seems to be happy with new home for temporary files, no need for junctions.

{ 1 } Comments