I have a console app (written in c#) that is passed various arguments from the command line by an external application (an InstallShield exe). Without adding code into the console app or InstallShield exe to log the value of arguments is there any way to see the value of the arguments passed to the console app? (perhaps via some sort of process monitoring app)
Any suggestions would be very helpful!
Cheers
Tim
The excellent and free Sysinternals Process Explorer will do what you want. Highlight the process, right-click, choose Properties, and on the dialog that opens you'll see a "Command line:" section that lists the arguments passed to your executable:
(source: ask-leo.com)
(Image source: Process Explorer - A Free Powerful Replacement for Windows Task Manager)
Related
I build a C# Console application that takes a file in parameter, format it and save the result in an other file. I've built the application successfully using ClickOnce. Now I want to be able to click right on a given file and "Send To" my application. As for other application, I've sent the shortcut to the C:\Users\MyUser\AppData\Roaming\Microsoft\Windows\SendTo repository but unlike other shortcut, my application is hidden from the menu. I've tested on few other PC (also running under Windows 7) and I always get the same behavior.
Do you know if it's caused by ClickOnce? Is there a way to solve this issue?
FYI, I finally bypass the ClickOnce solution and use the plain .exe instead. The post below describe how to achieve it:
Why are my binaries not placed in the /bin/release folder when I build a Windows Service in C#?
When developing a C# project in Visual Studio, I have three options for output type. Console Application, Windows Application, and Class Library. AFAIK, the only difference between a DLL and an EXE, is the EXE should have an entry point defined, and that is called when the file is double clicked. However, when I launch an EXE built from a Console Application, a console window is created. So obviously something is happening other than the CLR getting launched and then calling my Main method. What launches the console window? When I launch an EXE built from a Windows Application, is some other code run also, or is it just my main method?
Your portable executable file(exe) will contain the information about what kind of application it is.
Subsystem flag of the IMAGE_OPTIONAL_HEADER defines what kind of user interface the application is built with.
IMAGE_SUBSYSTEM_WINDOWS_CUI defines the console application, IMAGE_SUBSYSTEM_WINDOWS_GUI defines the windows application and so on.
For more information Peering Inside the PE: A Tour of the Win32 Portable Executable File Format
The output type is a configuration parameter for your project which tells Visual Studio what to do when you compiled. If set to Console Application, it will generate an exe file with the code to launch the console window.
The different between a dll and an exe is more than the main method. Visual Studio generated additional codes in the exe file that creates the console and invoke the main method. For details of how the exe file performs this, refer to http://en.wikipedia.org/wiki/Portable_Executable.
In this link the inquisitor added some notes which mentioned the blog post (2nd link).
Is it possible to build a Console app that does not display a console Window when double-clicked?
http://blogs.msdn.com/b/oldnewthing/archive/2009/01/01/9259142.aspx
The same content as Siram's answer https://stackoverflow.com/a/30084790/2005526 but to assist you with future searches these were the keywords used on google to locate the mentioned resources. "double click exe launches console"
How can I set Windows (or Visual Studio, or my application) so that when I run a console app by hitting F5 from Visual Studio 2010, I can get a 120x50 layout with my choice of font, instead of the 80x25 standard CMD/DOS window?
(even better - anyone know how I can get VS to run console apps in something like Console2 or bash instead of cmd.exe ?)
Run a program from VS as normal (ctrl-f5, or f5, or whatever) and then from the system menu (click the icon in the upper-left corner of the window), choose "Defaults". Alter your settings as you like, and save them. From then on, new windows should be launched according to those settings.
As for running your program in something other than "cmd.exe", you should be aware that "cmd.exe" is not involved at all in the window. The window is a normal console window, and "cmd.exe" didn't create it. In the same vein, "bash" wouldn't be involved, because that's a command shell, not a windowing program.
Cmd.exe and bash (and a whole host of others, including 4nt, command.com, and everything along those lines) are not windowing programs, and they don't create windows. They're console-mode programs, and Windows automatically creates special "console" windows for them to run in. Windows knows they're console-mode programs because there's a flag in the .exe file (which is a file format called PE) that specifies what type of application it is.
Console2 is a program that hosts console applications, and in theory could be used, if Console2 allows you to start it and an external program at the same time. In your project properties, under the "Debug" tab, change the "Start Action" option to "Start external program:" and type in the command line that will start Console2 and your program together.
I have a ClickOnce cmd line app that is throwing an exception on initialise. I can't see details of the exception because the console window closes before I can see it.
I have tried launching (my using the shortcut from the start menu, simply dropping it on to the console window) but it launches a separate console, writes the error to that and closes!
How can I see the error?!
Thanks
Ryan
I recommend tracking down the executable in the ClickOnce cache and double-clicking on it to see if it's a ClickOnce problem or a problem in your application.
The cache is in C:\Users\username\AppData\Local\Apps\2.0\obfuscatedfolder\obfuscatedfolder and from there you'll have to look in the folders for the one with your exe in it.
If it works, then it's a bug in your app. I'd put some messageboxes or logging in your app, or put in a try-catch around the start routine and have it show the exception and prompt the user for input in order to continue.
If it doesn't work, I would install .NET 4 on the machine and enable the enhanced ClickOnce logging and then check out the log file. (Note: The app does not have to target .NET 4, it just has to be installed on the machine.) Here's an article on how to enable enhanced logging for a ClickOnce application.
Here is a little quick & dirty solution:
Use a .bat file.
In the first line launch the shortcut, the second line is just a pause.
start shortcut_name
pause
Here is good link if you're not familiar using with .bat files
I'm going to make a desktop application that will run in the background, meaning no visible window, and I'd like an option called: "Upload Text" to appear when a user right clicks a file.
Can someone point me in the right direction? I also have to make sure that if someone wants to uninstall the program at any point, that the shell modification is also cleanly eliminated.
The app will run Windows XP, Windows Vista and Windows 7. How different are these OS's in handling my shell dilemma?
This is a shell extension. You've tagged this question with the C# tag; you should know that writing shell extensions in a managed language is strongly discouraged:
Unfortunately unmanaged C++ is really
the only way to go here.
Writing in-process shell extensions
in managed code is actually a very
dangerous thing to do because it has
the effect of injecting your managed
code (and the .NET Framework) into
every application on the machine that
has a file open dialog.
The problems occur because only one
version of the .NET Framework can be
loaded in a process at any given time
(other shared components such as java
and msxml have the same property and
thus the same restriction).
If you write your shell extension
using the 2.0 .NET Framework and an
application built with the 1.1 .NET
Framework uses a file open dialog,
your shell extension will fail because
it can not run on an earlier version.
Things can get even worse if your
shell-extension manages to get loaded
in a process before another
applications managed code does: your
extension may force an existing
application onto a different runtime
version than the one it was expecting
and cause it to fail.
Because of these problems we strongly
recomend against using any
single-instance-per-process runtime or
library (such as the .NET Framework,
java, or msxml) in an in-process shell
extension.
That said, people have done it.
Here's a guide to creating shell extensions, using C++.
You could add your app to the SendTo folder.
What about a stand-alone program using SendTo?
Install the exe to "Program Files\mycompany\myprogram" and a shortcut to the exe into the SendTo folder. Then when a user right clicks on a file, selects SendTo, and then selects your program, your exe will be executed by Windows and the full path to the filename will be passed in via argv[1]. If they select n files they will be in argv[1]..argv[n].
If you want your program to be invisible then do not make the default form visible. You could optionally place an icon in the tray so the user could double click on it to see the upload progress. When the upload of argv[1] is complete, process argv[2]...argv[n] if they exists and exit. To cleanly uninstall, remove your program and the shortcut from the SendTo folder.