I get the following error using vs2017

Severity    Code    Description    Project    File    Line    Suppression State
Error    LNK1168    cannot open c:\users\owner\documents\visual studio 2017\Projects\Debug\Win32Project1.exe for writing    Win32Project1    c:\Users\Owner\documents\visual studio 2017\Projects\Win32Project1\LINK    1    
 

37 minutes ago, phil67rpg said:

cannot open filename.exe for writing 

(I deleted the path and changed the filename for simpler reading.) Looks like you're trying to edit an EXE file. 

20 minutes ago, Tom Sloper said:

Looks like you're trying to edit an EXE file. 

how do I fix this problem?

Don't try to edit an EXE file. You should be editing source code, not object code.

6 minutes ago, phil67rpg said:

how do I fix this problem?

Most likely you didn't close the last run of your program and the compiler can't write the new version out. Check your taskbar. Maybe check task manager also.

5 hours ago, phil67rpg said:

I get the following error using vs2017

Severity    Code    Description    Project    File    Line    Suppression State
Error    LNK1168    cannot open c:\users\owner\documents\visual studio 2017\Projects\Debug\Win32Project1.exe for writing    Win32Project1    c:\Users\Owner\documents\visual studio 2017\Projects\Win32Project1\LINK    1    
 

Usually this means you have your program running at the same time you are tying to compile it.  The system knows the .exe file is in use so it's telling you you have to close the program before doing the compile so it can write a new version of the exe.  Also I've seen it before that even if your program is no longer running, the system gets confused and thinks the exe is still in use.  If all else fails, reboot your system.

Funnily, Linux lets you change an executable that is currently running (at least on ext-filesystems). The change doesn't affect the file in memory, just next time it is started the new version will be loaded.

The "problem" might be file system/os dependent, or a built-in functionality in visual studio. Is there a logical reason not to change executables on disk that are currently running ? Updates for example depend on that ...

3 minutes ago, Green_Baron said:

Funnily, Linux lets you change an executable that is currently running (at least on ext-filesystems). The change doesn't affect the file in memory, just next time it is started the new version will be loaded.

The "problem" might be file system/os dependent, or a built-in functionality in visual studio. Is there a logical reason not to change executables on disk that are currently running ? Updates for example depend on that ...

I vaguely remember that the exe is, or at least was used to swap in code and/or constant data when memory was tight. Don't quote me on this however.

Yeah ... there was something like that ...

Or another process (anti-virus thing ?) has its thumb on it ?

Anyway:

https://docs.microsoft.com/en-us/cpp/error-messages/tool-errors/linker-tools-error-lnk1168?view=vs-2019

I frequently discover one or two windows from earlier debug runs that were hiding behind the ide window when i close it ... :-)

2 minutes ago, Green_Baron said:

I frequently discover one or two windows from earlier debug runs that were hiding behind the ide window when i close it ... ?

 

Ha, ha, Same here ?