Visual Studio compiles but the exe isn't there

Question

Source code that compiles fine on other peoples environments won't correctly work in my environment. When I do a rebuild the compile occurs but when visual studio goes to move the exe from /obj/debug/{solution} to /debug/{solution} it cannot find the exe in the /obj/debug/{solution}. To make this even more crazy even after I reinstall visual studio it doesn't work. On other people environments it works find. Please note that this is a windows mobile 6, compact framework 3.5 project, Visual C++ project.

EDIT: Visual Studio 2008 is being used.

EDIT2: After looking at the logs again come to find out it says it is compiling but it isn't really compiling. Interesting enough it doesn't throw any errors until it tries to link the code. When it goes to link the object files, they aren't there and it fails.

Poleyn

Add the Visual Studio version. Maybe it will make a difference. – Kvass

Answer 1

I got TWO Release folders: one in the solution folder and one in the project folder. The former contains the .exe file, the latter does not.

Recur

Thank you so much for bringing this to my attention! – Battology

Answer 2

In the solution properties page, check whether the path you are expecting the exe to be is same as the one specified in Linker -> Output file.

Another obvious mistake could be, check what build configuration you are building. You might be doing a release build and expecting a debug executable file :) I have done this a few times.

Canterbury

Please note that the exact same line of source builds correctly in another PC. Same everything, just a different computer. Also, Visual Studio is set for Debug build. It tries to build it, and you can see in the output that it is building the Debug version. Visual studio throws an error saying something like "Error copying /obj/debug/{solution} to /debug/{solution}, /obj/debug/{solution} doesn't exist". If I look in either directories Visual Studio is correct there is nothing there. But I look in the log and it is compiling it and outputting the EXE. It's crazy. – Poleyn

Answer 3

Maybe VS creates the exe, and before it tries to move it to the final destination your virus scanner grabs it and removes it, or moves it to a save location.

Helianthus

Answer 4

I just wanted to chime in and ask: have you looked for the *.exe file name from the directories above? What I found in my case was it was writing to the directory right above the /release subdirectory. Not sure how I missed that detail, but I did! I suppose it never occurred to me earlier because I saw the buildlog.htm being written to the /release subdirectory, and the very existence of the directory itself. In my case it was compiling, linking, etc. I just wasn't able to see the *.exe in that /release subdirectory.

Pretended

Answer 5

There are two subtly different paths. I was looking here, which doesn't exist:

C:\Users\james\source\repos\CppHelloWorld\Release\CppHelloWorld.exe

The actual exe is here - note the path contains the x64 platform that it was built for:

C:\Users\james\source\repos\CppHelloWorld\x64\Release\CppHelloWorld.exe

In general, the path seems to be:

$PROJECT_PATH\$PROJECT_NAME\$PLATFORM\$CONFIGURATION\$PROJECT_NAME.exe

Workroom

Answer 6

If the exact same solution works on other machines, then it's an environment problem and no amount of looking at the project, linker, etc is going to resolve this. What is different about the environments? Are the same service packs and QFE's applied for not just Studio, but also the OS? Is there a difference in processors (64/32-bit)? Are your permissions the same? Do you have the same SDKs installed?

I'd agree with Shahi that just trying to build a "hello world" app against the same SDK and see if it will compile is valuable info.

Koweit

Answer 7

I had exactly the same problem. Just close Visual Studio and reopen it again (basically restart it) and it should work.

Frederiksberg

Answer 8

In my case, my network security team released an unannounced security update that preventing me from creating any .exe files. I figured that out at midday after trying all the solutions (+ more) here.

Anya

Thanks for mentioning. I just experienced something similar: my AntiVirus flagged the exe as a threat and quarantined it, leaving me clueless why I could not find the .exe in the folder. – Selfservice

Answer 9

Perhaps you do not have write permission to the output folder? If you are running on Vista/7, is your Visual Studio running as elevated?

Adolescence

The workstation is using Windows XP. It had permissions to write. – Poleyn

Answer 10

I've found this to be random for myself in now VS2016. My work around has been to just create another project and copy the contents from the one with out the .exe to the new one. For some reason the new one normally will have the proper .exe and location needed. While this isn't a complete solution at least it's been working for me for the time being.

Noodle

Answer 11

It happened with me today:

TL;DR; You might be using some C# code in your project who belong to a language version which is not supported by the .NET Framework version targeted by your project

Details:

I had two projects in my solution. One project was already existing. I added a new project targeting most recent .NET Framework v4.6.1 supported by Visual Studio(VS) 2017 class library project template. I used some C# language features which is present in C# v7.0. In such a case, VS can compile the project but can't create the output in bin directory.

Eventually I had to merge the new project code files into the existing old project which was targeting .NET Framework v4.5.1.

So I changed the target Framework version to the latest .NET Framework v4.6.1 for the existing projects also. Then the old project also started supporting my newly pasted C# language features.

Emir

Answer 12

In my case, the error appeared after I cloned my solution on a new machine.

I did not realise that the newly-cloned solution had AnyCPU set by default, when in reality my solution only supported x64. The compiler, however, did not return any error.

What pointed me in the right direction was the Output log, highlighted that of the 4 projects my solution was composed of, one of them was always skipped, i.e. only 3 were actually compiled. Scrolling up a bit the log, I noticed some message similar to MSIL mismatch between CPU versions.
Switching from AnyCPU to x64 solved the error for me.

(I then deleted the AnyCPU option from the Configuration Manager to avoid this issue in the future)

Zygote

Answer 13

If you create a new "hello world" WM project, does it work?

If so, you can compare the solution files to check for differences that can cause this.

Kvass

The solution file that isn't working on this workstation works on all other workstations. – Poleyn

Still, since this is machine specific and my suggestion is very easy to test, I would recommend you doing it and see whether there are differences. – Kvass

Answer 14

As far as I could tell, you need to "Save All" before building.

Divulgence