I need to run a .net application c# or preferably VB that will just perform a given task then close itself.
This app will receive arguments from the command line, process calculations, write result text to a file and then end.
Currently I run it as a console app, therefore the user can see the console black window and then the windoiw vanishes.
How can I get rid of the visual element?
Also, once the project is compiled, how can I include it within another solution so that both projects will be published together with clickOnce?
I need two separate projects in the same solution because one of them (the silent one) must run in x86 mode and the other as x64.
Assuming you're using a recent version of Visual Studio, go into your project properties (Application tab) and change the "Output type" dropdown from Console Application to Windows Application.
Not sure about the click-once requirement, though... haven't been down that road, but it may warrant a separate question.
Run the app as a process and set the window style to hidden.
System.Diagnostics.ProcessStartInfo start = new System.Diagnostics.ProcessStartInfo();
start.FileName = dir + #"\silentApp.exe";
start.WindowStyle = System.Diagnostics.ProcessWindowStyle.Hidden;
https://msdn.microsoft.com/en-us/library/system.diagnostics.process.start%28v=vs.110%29.aspx
Related
Is there a way in Windows to launch a .csx script directly (e.g. by double clicking the file, or from the start menu, or via an app launcher like Launchy) such that the script runs in the background without opening a command line window?
For example, say I have a simple "lowercase.csx" script which simply takes whatever text is in my clipboard, converts it to lowercase, and puts the result back in my clipboard. I want to be able to double click on that .csx file and have that run completely in the background without opening any kind of window.
Currently both ScriptCS.exe and the new csi.exe launcher that comes with VS2015 Update 1 will open a console window when running a .csx file, even if that file doesn't output anything to the console.
Note: I know that a new window isn't opened if you launch a script from a console window. What I want to to launch a script in a non-command line context and have it open no windows.
Note2: The equivalent of what I want in "CS-Script" (a ScriptCS alternative) is to launch the files using "csws.exe".
You can make your own version of csi.exe that runs without a console.
Simply create a new project, make sure the Type is set to WinForms instead of Console, then add the C# Scripting package from NuGet and copy-paste the csi.exe source code.
scriptcs does not support this.
However there is an application that solves this problem: https://gitlab.com/Lions-Open-Source/ScriptCSW
A workaround is to create your own program that launches it in the background for you, like csws.exe would.
Start by creating a console app.
public static void Main(string[] args)
{
var startInfo = new ProcessStartInfo("path to csi.exe")
{
CreateNoWindow = true,
Arguments = args[1],
RedirectStandardOutput = true,
UseShellExecute = false,
};
Process.Start(startInfo);
}
(You'll obviously want to pass the rest of the arguments and check to make sure a file was passed etc, but this should get you started. And I wrote this answer on my Mac as my Windows box is in the shop, so I can't guarantee it'll work.)
Then have the console app not show a window by changing it to a Windows application from a Console application on the project properties screen as described in this question.
Lastly, configure .csx files to always open with your application. Then you can double click them and they'll run with no window.
Create a batch file and add (in this example to csi.exe installed for VS 2019):
#echo off
"C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\Roslyn\csi.exe" "C:\myscript.csx"
If its important to hide the command prompt then see here and here.
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"
I have a large solution containing many projects with one of them being a Setup project. There are also many current versions stored in separate branches. I have a build tool that used to work in .NET 2, but hasn't worked since we upgraded to .NET 4.
Internally, the new .NET 4 version of the build tool uses Microsoft.TeamFoundation.Client.RegisteredTfsConnections.GetProjectCollections() and versionControlServer.GetAllTeamProjects(false) to get a collection of TeamProjects from my TFS source control server.
I then display them visually in the UI and when a user clicks on a particular solution version, the application calls the following to get the latest for that solution version:
workspace.Get(new string[] { serverPath }, VersionSpec.Latest, RecursionType.Full,
GetOptions.GetAll);
The application used to build the solution files and this would include the Setup project. At this stage, the setup project would create an MSI that the application could be installed with. It is this last step that I am having problems with.
I need to be able to programmatically build the solution that the user selected using C# code. The working .NET 2 code for this was as follows:
Process process = new Process();
ProcessStartInfo processStartInfo = process.StartInfo;
processStartInfo.FileName = processName;
processStartInfo.Arguments = string.Format(" \"{0}\" /BUILD \"Release|Any CPU\"",
solutionPath);
processStartInfo.WorkingDirectory = processDirectory;
process.Start();
There is no error when this is run, but it no longer launches Visual Studio and builds the code. Clearly, this was a poor way to do it initially, but I can't find the 'correct' way using the TFS classes.
I also tried running MSBuild.exe directly (similar to the above example), and this does build the solution, but for some reason does not build the Setup project that produces the MSI. Note that I do NOT use any manually created build files.
Unfortunately, useful documentation for the Microsoft.TeamFoundation namespace is hard to find! I'm hoping that someone here has made use of these classes and can direct me to a solution to this problem.
If at all possible, I need to use .NET classes (eg. not Process.Start) as I really need to know when the build has finished as well. I can however set up a FileSystemWatcher object for this if this is asking too much.
msbuild skips the installer projects because it doesn't know how to build them. FinalBuilder shells out to devenv.exe to build these.
Calling `devenv /build "Release|Any CPU" /project "MyInstaller.vdproj" should run the build you need from the command line, without starting the VS GUI. Try it!
With all that said: We, too, use FinalBuilder, and VS Installer is deprecated, so you'll probably want to plan on replacing that.
It turns out that the problem was unfortunately completely unrelated. The .NET 2 code that was to be updated had hard coded 'Program Files' into the devenv.exe file path - however the new computers are 64bit and Visual Studio 2010 is installed into 'Program Files (x86)'!
So this means that the above code sample DOES work and WILL allow me to build the solutions from C#. It's not the object oriented way that I would have preferred to do it, but after all your comments, I'm just glad to have got it working at all.
Thanks for your time everyone.
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 developed an updater application for my windows app. They are different projects under the same solution and they run as different processes. when i run the app it checks for updates at startup (as another process). when i click update button it tries to download files to the installation location. (i am using the .exe in debug folder i don't create setup file) Everything works fine but the main application (app.exe) can't be overwritten because it is used by update process. but in update process i kill app.exe and app.exe goes from task manager too. i couldn't find anything, how main app.exe is used by update. has anyone any idea how update uses main app ? how can i watch it? in which line it starts using the other app?
Rename app.exe
Insert new app.exe
Close running, old app.exe
Start new app.exe
Check for renamed app.exe (in newly started app.exe)
Delete old, renamed app.exe
If the updater app has a reference to the main app exe, it will keep it locked. If that's the case, can you remove the reference to the main app from the update app project? This may need moving some code directly into the updater's source.
To find out who has a hand on your process you should start ProcessExplorer. There are some spy glasses in the menu bar. Just click on it and see which process holds a handle to your app.
Do you need to invent your own? There are existing solutions that you may be able to leverage that already do this. Microsoft ClickOnce supports this if it fits your deployment model.
A quick google search turns up a few things as well:
http://csautoupdater.sourceforge.net/
http://www.codeproject.com/KB/vb/Auto_Update_Revisited.aspx