3

Debug (or Release) folder of my Desktop application when copied to another location does not run the exe. It issues no errors, but simply hangs the system for a second or two, but returns to normal straight away, as if nothing had been run.

Does Visual Studio 2015 create dependencies in upper hierarchy of Debug as well? My installer created using Wix was not running the intended exe and i thought it was Wix's problem. But then i tested it by copying the full Debug folder in a temporary subfolder and the app was not running even from there. It can only happen when it has dependencies present in places other than the Debug folder (because system resources (dlls) are accessed from absolute path of C: drive, so they would always be available.

Dia Sheikh
  • 190
  • 2
  • 16
  • 1
    does not run? no errors? – BugFinder Jan 03 '18 at 11:05
  • Is it mobile/desktop app or console application? – YDS Jan 03 '18 at 11:21
  • Add your dependencies (DLL) in bin folder. It will work – Negi Rox Jan 03 '18 at 11:26
  • 1
    In general Visual Studio projects (of various types) put build output into a folder to make debugging work. That's it. To build an installer, you have to find what the actual dependencies are, how they are found at runtime and the best, legal way to deliver them to the target machine. Often, a high-level redistributable installer from the original vendor is a good way. If any are .exes, try a WiX Bootstrapper project. You might need to know how the .NET runtime locates assemblies and use Fusion Log Viewer and how Windows locates DLLs and use Depends' profile mode or ProcMon per @SteinÅsmul – Tom Blodget Jan 04 '18 at 00:39
  • 1
    Great summary Tom - much more to the point than my winding answer. When I need a reminder of module search order, I open Dependency Walker (depends.exe) and then do ``Options => Configure Module Search Order...``. It is certainly outdated, but it is at least a reminder of how folders are scanned in Windows (and every Windows version is different - especially with manifests). And of course [a review of .NET probing](https://docs.microsoft.com/en-us/dotnet/framework/deployment/how-the-runtime-locates-assemblies) is called for when facing these problems (over and over again like we all do). – Stein Åsmul Jan 04 '18 at 02:09
  • 1
    Perhaps running the application via the Visual Studio debugger would help. There are many ways, for example, [launch via Visual Studio](https://msdn.microsoft.com/en-us/library/0bxe8ytt.aspx), or call [`Debugger.Break()`](https://learn.microsoft.com/en-us/dotnet/api/system.diagnostics.debugger.break#System_Diagnostics_Debugger_Break). – Tom Blodget Jan 06 '18 at 00:14

1 Answers1

3

Could there be something wrong in your manifest file or some other settings file? Some relative path pointing to a folder in your source hierarchy? Maybe it is just an image file or some sort of settings file that is missing? Or it might be something completely different.

A I wrote in your other question, one approach for hard-to-debug dependency scenarios is to just bite the bullet and run a thorough procmon.exe session (that is a direct hotlink to the live sysinternals tool share, clicking it will start the download instantly - just so you are aware).

You can see a quick description of how to use this tool in this question: Registering a CPP dll into COM after installation using Wix Msi installer. The key is to set an include filter which will show only events you need to see - basically for your own application.exe should suffice I believe.

Many find this procmon-stuff overkill, and don't want to deal with it - but trust me, it almost always reveals something unexpected (not always useful however).

As before this answer may also be worth a quick skim (on dependencies in general): After creating MSI Installer for WPF app in Visual Studio 2017, EXE does nothing. I would at least try the Dependencies.exe tool - even if it is a bit "beta-ish". You can download from here: https://github.com/lucasg/Dependencies/releases.

And certainly double-check the modules view in Visual Studio which I describe in the linked answer (Debug => Start Debugging, then go Debug => Windows => Modules). It should show whatever was loaded to run your project interactively.

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164