Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!
26731 Discussions

Visual Studio cannot debug because a debug target has not been specified

zhao__qiao
Beginner
380 Views

Hello,

I was running a project in Visual Studio Community 2015+Intel Fotran XE2017 I got this error message.

The same error occurs both when starting in Debug mode and in Release mode. However the build is successful and the compilation is successful as well.

I've got .dll in the debug file and it seems to work well. Nevertheless this error message worries me because I have not got this error before.

I find my problem alike this one but I'm not sure having understood the solution https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/287867

Could you help me with that? It is possible because this project is written in other Windows system?

Thank you

Qiao

0 Kudos
3 Replies
mecej4
Black Belt
380 Views

I've got .dll in the debug file and it seems to work well.

It is not clear what you mean by that. A DLL cannot be run by itself. There has to be another EXE or DLL that calls entry points in the DLL. At the beginning of the chain an EXE is expected to contain the starting point. The earlier thread that you linked to is quite clear regarding the stance of the VS IDE/debugger concerning projects/solutions.

zhao__qiao
Beginner
380 Views

I use another process software to call this .dll and it works. But I do not understand why I could have this error by running debug and release.

Kevin_D_Intel
Employee
380 Views

If the property setting Fortran > Debugging > Command resolves to a non-executable entity (i.e. like your DLL) then you will receive the message you wrote about.

Perhaps you can set that property setting to refer to your other “process software” so when debugging is initiated for your DLL project it starts that “process software” instead of what currently is likely resolving to the DLL itself (i.e $(TargetPath) ).
 

Reply