Visual Studio gone bonkers: 'The directory name is invalid' error when trying to compile

Question

For some very odd reason, my Visual Studio 2008, when trying to compile a C# project, tries to write the output of the executable to a directory with the same name as an executable, at least it seems that that's what the error message implies. After running Compile on any of my projects, CSC.EXE reports the following compiler error:

Could not write to output file 'D:\Projects\Examples\StringBuilderVsString\obj\Release\StringBuilderVsString.exe' -- 'The directory name is invalid. '

When I look inside obj\Release or obj\Debug all intermediate resources, like StringBuilderVsString.pdb are correctly written in that directory. There are no spaces in the directory. The error happens also when running csc.exe from the command prompt.

When running Process Monitor, I only see SUCCESS for files accessed by csc.exe and I don't see any querying or writing to locations that do no exist.

Any ideas on tackling this are welcome.

Badillo

the double projFilename.exe is intentional why? – Galingale

I think he means he intentionally wrote that, but obviously VS is doing something wrong to come up with this. – Royal

@Codesleuth: I meant: I wrote it, because that's where Visual Studio tries to write the output to. It should be without the second name, of course, it shouldn't at all try to write the output to a directory equal to the output executable filename. @Kent: precisely – Badillo

Ah, gotcha. In that case, post the .csproj file; could be illuminating. – Mince

@all: the above comments have become void after I updated the question to a more accurate depiction of the issue. – Badillo

Answer 1

Solved! Thanks for the input, I meanwhile found a solution. The cause is rare, but it may happen to others, so I decided to answer my own question here:

Cause

An incorrect or inaccessible %TEMP% location, or an inaccessible %USERPROFILE% path.

I had moved these paths to a faster SSD drive to speed up compiling. The drive crashed and the OS did not find it anymore (as reported on ServerFault here) and consequently, the moved locations (internet caches, my documents and temp) had become inaccessible.

The error mentioned by Visual Studio is misleading: it has nothing to do with the name of the file (while I'm still wondering why it was querying the executable as a directory), the error was about the %TEMP% location being bad.

Solution

Fix the %USERPROFILE% or %TEMP% environment variables, (in case you forgot, it's here: System > Advanced > Environment Variables).

Note: The typical and default TEMP setting is to use the USERPROFILE environment variable as in the default %USERPROFILE%\AppData\Local\Temp. This works, but only if in the registry, the key under HKCU\Environment\TEMP is of the type REG_EXPAND_SZ and not REG_SZ.

Badillo

I had the same weird problem not been able to add .h file (even though it will add .cpp file) to my VS2015 project with the same error and this fixed my problem as well. I didn't had USERPROFILE environment variable, I set it to c:\Users\<My.Name> and that fixed it. – Collie

Answer 2

Make sure that you have enough free space in your drive, I have experienced the same issue, got it resolved after allocating more free space.

Thi

Good point! Surprised that after so many years this still happens. Did you encounter this error with the newest release of Visual Studio (i.e. 2017)? – Badillo

Yes, The same issue happened to me, Got it resolved after allot more space in the disk. – Thi

Answer 3

In my case, this happens when I try to add a file (Database.mdf) to a folder (App_Data).

Solve it by adding the folder (App_Data) manually before adding the file (Database.mdf)

This happens when .sln registering a folder (that's why it shows up in Visual Studio) while that folder does not actually exist on disk.

Osmometer

Answer 4

I was also getting a similar error Could not write to output file '..........................' -- 'The directory name is invalid. '

I tried deleting folder, changing Environment variables as suggested above (i.e. %USERPROFILE% or %TEMP%), but nothing seemed to work. When I again looked at the output in the Output Pane/Window in VS 2008, I found the following line

"c:\Windows\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets(3397,13): error MSB6003: The specified task executable "cmd.exe" could not be run. Could not find directory path: C:\Users\Administrator\AppData\Local\Temp\2\"

This line led me to the solution. I just created the non existing 2 folder in "C:\Users\Administrator\AppData\Local\Temp" folder.

%USERPROFILE% = C:\Users\Administrator\AppData\Local\Temp

By the way we noticed this only on all of our Cloud instances. Something do with virualization? .. Dont know really

Mosier

If I understand you correctly, you first pointed %userprofile% to a non-existing dir. Of course, the dir it points to must exist. It is also possible that your error comes from a post/pre compiler task that expects a certain folder that simply isn't available on all machines. Normally, folders under %temp% are created by the process that needs them (as it can never be sure they are there the next time around) – Badillo

I dint point %userprofile% to a non-existing dir. %userprofile% was already pointing to a non-existing dir. The post compilation task always existed, but build started failing one day. If post compilation is the problem why would the error show up at the beginning in the first step in Output window under build? The post compilation step does CSS and JS compression using MSBuild and Yahoo.Yui.Compressor – Mosier

Hmm, I'm afraid I haven't got enough understanding of your situation to give you a solid answer to those questions. Consider asking a q. at SO for your specific situation (unless you consider it already solved as per your extra answer in this thread). – Badillo

Answer 5

Move that file to somewhere else and then try running it.It worked for me.

Latchkey

there is already an accepted answer for this question. this might have worked for you, but you are missing a huge amount of detail that an existing answer already gave. – M16