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"
Related
I am using Topshelf to create a Windows service which uses the chrome Selenium driver to manipulate and parse various webpages.
While the service code runs fine from a normal (NetCore2) console test application, there's a problem when it runs under the Win32 console app that Topshelf requires.
Unfortunately, I haven't been able to figure out how to debug into the underlying service code. The VS2017 debugger appears to be attached to the Topshelf console app, but won't let me step into the underlying service code, which is in a separate NetStandard2 class library. Specifically, when I come to this line in the Topshelf console app:
var scanEntry = _scanner.Run();
where _scanner is an instance of the object that does the actual scanning, I can't step into the code (i.e., F11 just steps over the line).
I tried inserting the following line into the class library scanning code:
System.Diagnostics.Debugger.Launch();
but it doesn't do anything; the code just keeps merrily executing along.
I suspect this is related to the fact that the scanning code is running in a separate process that Topshelf launches. But I haven't been able to figure out how to identify it through Visual Studio's Attach to Process mechanism.
Pointers on how to debug the underlying service code when it's running under Topshelf would be much appreciated.
Additional Info
When I tried stopping on that _scanner.Run() line, and using the context menu to single step into the class library code (rather than using F11), I got prompted to turn off Just My Code, which I did. The VS debugger then tried to step into the class library code, but complained that it couldn't find the library's symbol file (*.pdb).
Which is really weird, because a symbol file with that name exists in the bin folder for the Topshelf console app.
I tried manually opening the pdb file from the bin folder, but got an error message that "A matching symbol file was not found in this folder".
Is this related to trying to debug a NetStandard2 class library from within a plain old Net console app?
Okay, turns out the problem was related to debugging a mixed NetStandard and NetOriginal code base...
NetStandard class libraries, by default, do not generate debug symbol information usable by NetOriginal apps. You have to go into Project Properties -> Build -> Advanced and change the type of debug information being generated from Portable to Full.
Once I made this change I was able to step into the class library code as per usual.
I found this at a matching symbol file was not found in this folder
I have two C# Applications
TestApp is a console app which call a method decrypt included in AppCrypt
AppCrypt contains this method and needs to log (write on a file)
So far I can modify TestApp and I saw the result on my console but my goal is to edit the code of AppCrypt
I am using VS for both.
Question 1) I cannot find where is written the place where I link the DLL of AppCrypt
Question 2) I can build AppCrypt but I cannot generate a new DLL because I am getting this message
I found on SO that I should add a project Console App or a Winform but I just need to use that function without having a proper app so I dont know if it is my case.
I have built the DLL but it does not seems to be linked in my console app which is TestApp, how can I verify that it is linked?
You are getting that error cause most probably you have set your class library project as Startup project in your solution. Whereas you should set the Console app as your start up.
How to Set a project as StartUp: Right click on your project name and from context menu select Set As Startup Project
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#?
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.
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)