locked
VS2013: Deployment to a specified path on WEC2013 device RRS feed

  • Question

  • When VS2013 deploys an EXE to the WEC2013 device it uses always the path

    \Temp\ProjectName\

    When I change the property "Remote Directory" in the Deployment tab I can see that the EXE is copied with the files mscvp100d.dll and msvcr110d.dll to the specified directory.

    But when the application shall be started with the debugger VS2013 shows the message.

    The application could not be launched for debugging.

    Older Versions of Visual Studio had a property where you had to enter the debuggee path and name. Is this a simple bug my Microsoft in VS2013 and they have just forgotten that property?

    How can one debug a program that is not in the \Temp\ProjectName path?

    Tuesday, July 22, 2014 7:04 AM

All replies

  • It would be interesting to know whether a DEBUG kernel showed the reason for this problem. Any chance you depend on a DLL file but that the deployment of the DLL file is to a different location? Not in the path? I guess this could be a problem where the loader isn't looking in the right locations (HKLM\Loader\SystemPath?).

    Paul T.

    Monday, July 28, 2014 11:59 PM
  • Hello,

    any news?

    I have the same or similar problem, but sometimes it works sometimes not, then i got same message as outlined above:(.

    As far a i see it is *not* related to a path or dependencies in my case!

    Monday, July 13, 2015 10:41 AM
  • Nope, with WEC2013 they pulled a bunch of critical debugging options from the project property pages.  You have stumbled onto one of them -- basically you HAVE to run from the default path and just plan your development around that.  Fortunately I haven't had a scenario where that is a major issue (the main one I can envision is where you have project data files that should be in the same folder as the .exe, but are way to big to fit in RAM)

    The one they really messed up is:  You can no longer specify an executable to launch when debugging a DLL, which makes it flatly impossible to debug a native DLL that is loaded by managed code.

    • Proposed as answer by Paul G. Tobey Wednesday, July 15, 2015 6:34 PM
    Monday, July 13, 2015 2:11 PM
  • The one they really messed up is:  You can no longer specify an executable to launch when debugging a DLL, which makes it flatly impossible to debug a native DLL that is loaded by managed code.

    Does this mean that it is also impossible to debug the unmanaged DLL when the managed EXE is in the same solution?

    Monday, July 27, 2015 6:32 AM