My console application is responsible for starting a WCF service in interactive mode (ie. the service does not get installed as a Windows service in that case).
In order for my application to start the latter, the application invokes the compiled executable using the following method:
static bool AutoStartService()
{
var MyProcessFile = System.IO.Path.GetFullPath($"pathToExecutable/MyServiceExe.exe");
Process myProcess = new Process();
myProcess.StartInfo.FileName = MyProcessFile;
myProcess.StartInfo.Arguments = "";
myProcess.StartInfo.WindowStyle = ProcessWindowStyle.Normal;
myProcess.Start();
Thread.Sleep(WaitForTheServiceToStart);
}
return true;
}
Note that this approach works just fine when debugging from Visual Studio.
However, when the console application is invoked from Jenkins (note that I gave Jenkins admin access and it logs in as a normal user), then the service process does not seem to stick or be visible from the Console application. I can tell it at least starts and stops as I can see the logs being written to file.
The Console application is started using a batch command from Jenkins (I also tried using Powershell, but without luck).
Any suggestion on how to do that?
I have tried with both debug and release builds of my Console app C# project, but it makes no difference.
EDIT
I have edited the following properties, but without success:
myProcess.StartInfo.UseShellExecute = false;
myProcess.StartInfo.Environment.Add("BUILD_ID", "dontKillMe");
I am now seeing the following warning, but I don't believe installing the service is the only way to go as this is what I am doing when running this code without Jenkins and it works. Maybe Jenkins does not allow it though?:
Cannot start service from the command line or a debugger. A Windows Service must first be installed (using installutil.exe) and then started with the ServerExplorer, Windows Services Administrative tool or the NET START command.
EDIT2
I went a step further. The reason why I was getting the former message is that the service checks "Environment.UserInteractive" to either run as interactive or to start/run the installed service. For some reasons this flag is always set to false, while it should be true in my case.
Is there a way to fool the service to think that flag is true?
Related
I want to run my long runing python script from my console app.
I use
("my_script.py"), when I shut down console also python script is terminate.
In task manager all(console app and script) is runing under .Net Core Host.
How to run python as completly separated process?
Normally, this would start your python script completely outside of your console application:
System.Diagnostics.Process.Start(#"C:\path\to\my_script.py");
In classic .NET it will invoke the process via a new shell, but in .NET Core, the process is created directly inside the existing executable. There is an option to change this, called UseShellExecute. This is directly from the Microsoft documentation:
true if the shell should be used when starting the process; false if the process should be created directly from the executable file. The default is true on .NET Framework apps and false on .NET Core apps.
This is how you can use it:
var myPythonScript = new Process();
myPythonScript.StartInfo.FileName = #"C:\path\to\my_script.py";
myPythonScript.StartInfo.UseShellExecute = true;
myPythonScript.Start();
When your C# console app terminates, your python script should still be running.
EDIT
Thanks to Panagiotis Kanavos, he made me realize the UseShellExecute has nothing to do with the parent/child relationship between the processes. So I setup a sandbox locally with .NET Core and played around with it a bit and this is working for me:
var myPythonScript = new Process();
myPythonScript.StartInfo.FileName = #"C:\path\to\python.exe"; // the actual python installation executable on the server
myPythonScript.StartInfo.Arguments = #"""C:\path\to\my_script.py""";
myPythonScript.StartInfo.CreateNoWindow = true;
myPythonScript.Start();
When the parent app terminates, my python script is still running in the background.
I have a .NET console application written in C# (myApp.exe), that runs an external application ('bob.exe'). The console application works great when I run myApp.exe manually. The C# code that calls the application is:
System.Diagnostics.ProcessStartInfo procStartInfo =
new System.Diagnostics.ProcessStartInfo("C:\\bob.exe");
procStartInfo.RedirectStandardOutput = true;
procStartInfo.UseShellExecute = false;
// Do not create the black window.
procStartInfo.CreateNoWindow = true;
// Create the process and assign its ProcessStartInfo and start it
System.Diagnostics.Process proc = new System.Diagnostics.Process();
proc.StartInfo = procStartInfo;
proc.Start();
In Windows Server 2003, I created a Scheduled Task that executed 'myApp.exe' on a regular basis. It was set to execute even if the user was not logged in. The Scheduled Task worked and called 'bob.exe' (I was able to verify this by viewing the output files from 'bob.exe')
We then upgraded to Windows Server 2012. I created a Scheduled Task in Windows Server 2012, setting it to execute even if the user was not logged in and configuring it for Windows Server 2003.
I set the Action to call 'C:\myApp.exe', similar to how I had it set up in Windows Server 2003
When the scheduled tasks executes and I am logged in, the 'bob.exe' application is executed from 'myApp.exe'. However, when I am not logged in and the scheduled task executes, 'myApp.exe' is executed but 'bob.exe' is never executed (I can verify this by seeing there are no output files from 'bob.exe'). There are no errors reported by the Scheduled Task and the Last Run Result says "The operation completed successfully. (0x0)".
I found a similar post here but I was unable to resolve my situation. What am I missing?
I had a similar issue with my app calling out 7za.exe to archive db backups. When I ran my app manually it worked fine, but when I scheduled my app via Task Scheduler, the 7z routine would not fire off and didn't give my app a verbose error. I found that adding the directory I ran my app from to the task scheduler's Start in (optional): box corrected my issue.
Program/script: "C:\Program Files (x86)\CustApp\CustApp.exe"
Start in (optional) C:\Program Files (x86)\CustApp\
Note not to use double-quotes on the "Start in (optional)" setting for the directory, it errors when I did.
I had a similar problem with running a Batch file (on WS2008) and the problem was due to the permissions given to the user executing the scheduled task on the folders where the Batch file and the Executable files were set.
I'm not sure if the security of WS 2012 is different, but if I were You I'll try to debug the application (if you have the code) checking for permissions.
HTH
I have an ASP.net website that is hosted on IIS7, within the asp.net code I have a C# statement that launches a .exe on my webserver on a button click. For some reason in visual studio it will launch on the local development server but when I move it to the IIS7 server it will not pop up a black console box on button click. This is what I am doing.
generateSpanish = "/n= " + serverName + "GenerateVoice SpanishVoice";
Process serverSideCommandSpanish = new Process();
serverSideCommandSpanish.StartInfo.FileName = Server.MapPath("Config\myexe.exe");
serverSideCommandSpanish.StartInfo.Arguments = generateSpanish;
serverSideCommandSpanish.EnableRaisingEvents = true;
serverSideCommandSpanish.StartInfo.UseShellExecute = true;
serverSideCommandSpanish.Start();
Again it launches in visual studio( a black console app pops up on the "server") but on my IIS server it does not do the console app popup serverside?
You need to enable the handler for exe's under IIS7. Do this by going to the web site under MMC and select Handler Mappings.
You may be able to get this to work using telling your Process to run PsExec with the -i argument and having PsExec run the .exe you're actually trying to start. The -i argument tells PsExec to execute the target in interactive mode on the desktop of a specified user session.
I am using visual studio 2010, my application has a multiu layer architect,
MainUI, WCFService, BLL and DAL
My MainUI communicated to WCF and WCF further communicates to BLL and DAL, whenever i need to debug BLL and DAL, i first need to attach WCF as a process in Visual studio(everytime). How could i can save myself from this hassle.
How could i set up visual studio in a way that i automatically attach to the service automatically and i could debug my application easily.
Thanks
Configure your solution for multi project start up. I do this for a similar application. VS launches the WCF and client automatically and I can set break points in either.
The start-up order is the order in which you select the projects.
Right mouse click on your solution and select 'choose startup projects'. Then select multiple startup projects and select the projects.
Sample howto start a process and attach it to Visual Studio 2010 with EnvDTE(Version is relevant).
//c:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\PublicAssemblies\EnvDTE.dll
using Process = EnvDTE.Process;
System.Diagnostics.Process p = new System.Diagnostics.Process();
p.StartInfo.FileName = System.AppDomain.CurrentDomain.BaseDirectory + #"\YourProcess.exe";
//Start the process
p.Start();
//Wait for process init
System.Threading.Thread.Sleep(1000);
bool attached = false;
//did not find a better solution for this(since it's not super reliable)
for (int i = 0; i < 5; i++)
{
if (attached)
{
break;
}
try
{
EnvDTE.DTE dte2 = (EnvDTE.DTE)System.Runtime.InteropServices.Marshal.GetActiveObject("VisualStudio.DTE.10.0");
EnvDTE.Debugger debugger = dte2.Debugger;
foreach (Process program in debugger.LocalProcesses)
{
if (program.Name.Contains("YouProcess.exe"))
{
program.Attach();
attached = true;
}
}
}
catch (Exception ex)
{
//handle execption...
}
}
Try using System.Diagnostics.Debugger.Break() in the code. If a debugger is not attached, then running that code will ask to attach a debugger and you can choose the existing instance.
Have you tried System.Diagnostics.Debugger.Launch() in your service you would like the debugger to attach to?
http://msdn.microsoft.com/en-us/library/system.diagnostics.debugger.launch.aspx
In the properties page for the wcf service project, select the Web tab.
Select 'Start External Program' for the start action, and choose MainUI.exe.
Set the working directory as the folder that MainUI.exe is in (probably a bin folder).
Set a break point and press f5 to start debugging.
If I understand correctly, Macro may be answer:
in Vs:
Tools->Macros->record TemporarilyMacro (Ctrl+shift+r)
Attach VS to process as usual (ctrl+alt+p)
Stop recording macro (ctrl+shift+r)
Go to View->Other Windows->Macro Explorer (CTRL+F8)
find your Temporarily Macro (somewhere in MyMacros->RecordingModule) and rename it
Now, go to Tools->Options->Keyboard and find your macro (in "Show Command containing write name of you macro)
in "Press Shortcut keys" bind it to some key shortcut (i have my macro in CTRL+SHIFT+K ;))
Push OK
Be Happy
Have you tried using the WCFSvcHost.EXE that comes with Visual Studio to launch the BLL and DAL service? There is a help file with it. The help file states it best, "Windows Communication Foundation (WCF) Service Host (wcfSvcHost.exe) allows you to launch the Visual Studio debugger (F5) to automatically host and test a service you have implemented. You can then test the service using WCF Test Client (wcfTestClient.exe), or your own client, to find and fix any potential errors." The default installation is C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE. You can configure it to use your MainUI app as the client. The help file WcfSvcHost.chm in the same directory has a section for using a custom client under the Scenarios for using ECF Service Host. If you rather here is the link to help on MS web site: Using WCF Service Host (wcfSvcHost.exe).
If this is for a self-hosted WCF windows service, you need to make your WCF service host configurable to either run in console or as a windows service. When you have run in console turned on, you can start debugging from visual studio.
Create an app setting called "RunInConsole." In your service host startup method, have the following code:
public class MyWindowsService : ServiceBase
{
public static void Main(string[] args)
{
// if configuration says to run in the console, run the service in a console app. otherwise, use windows
// service to host application
if (ConfigurationManager.AppSettings["RunInConsole"] == "true")
{
using (ServiceHost host = new ServiceHost(typeof(MyService)))
{
host.Open();
Console.WriteLine("Press <Enter> to terminate the Host application.");
Console.ReadLine();
}
}
else
ServiceBase.Run(new MyWindowsService ());
}
}
On all environments you deploy to, you'd always have this config setting set to false or else the service will fail to start, but when debugging locally you'd set it to true.
Here is a detained article that explains how to do this...You can customize this macro.
http://sivablogz.wordpress.com/2013/04/08/running-an-application-and-attaching-to-the-process-with-a-macro-in-visual-studio/
Personally I prefer to use Debugger.Launch() as suggested here
in this thread, because it doesn't need for references to the DTE (that's IDE-specific and must be explicitly referenced into the project to be used)
I'm able to successfully uninstall a third-party application via the command line and via a custom Inno Setup installer.
Command line Execution:
MSIEXEC.exe /x {14D74337-01C2-4F8F-B44B-67FC613E5B1F} /qn
Inno Setup Command:
[Run]
Filename: msiexec.exe; Flags: runhidden waituntilterminated;
Parameters: "/x {{14D74337-01C2-4F8F-B44B-67FC613E5B1F} /qn";
StatusMsg: "Uninstalling Service...";
I am also able to uninstall the application programmatically when executing the following C# code in debug mode.
C# Code:
string fileName = "MSIEXEC.exe";
string arguments = "/x {14D74337-01C2-4F8F-B44B-67FC613E5B1F} /qn";
ProcessStartInfo psi = new ProcessStartInfo(fileName, arguments)
{
CreateNoWindow = true,
UseShellExecute = false,
RedirectStandardOutput = true
};
Process process = Process.Start(psi);
string errorMsg = process.StandardOutput.ReadToEnd();
process.WaitForExit();
The same C# code, however, produces the following failure output when run as a compiled, deployed Windows Service:
"This action is only valid for products that are currently installed."
Additional Comments:
The Windows Service which is issuing
the uninstall command is running on
the same machine as the code being
tested in Debug Mode. The Windows
Service is running/logged on as the
Local system account.
I have consulted my application logs
and I have validated that the
executed command arguments are thhe
same in both debug and release mode.
I have consulted the Event Viewer
but it doesn't offer any clues.
Thoughts? Any help would be greatly appreciated. Thanks.
Step 1: Check the MSI error log files
I'm suspicious that your problem is due to running as LocalSystem.
The Local System account is not the same as a normal user account which happens to have admin rights. It has no access to the network, and its interaction with the registry and file system is quite different.
From memory any requests to read/write to your 'home directory' or HKCU under the registry actually go into either the default user profile, or in the case of temp dirs, c:\windows\temp
I've come across similar problems in the past with installation, a customer was using the SYSTEM account to install and this was causing all sorts of permission problems for non-administrative users.
MSI log files aren't really going to help if the application doesn't appear "installed", I'd suggest starting with capturing the output of MSIINV.EXE under the system account, that will get you an "Inventory" of the currently installed programs (or what that user sees installed) http://blogs.msdn.com/brada/archive/2005/06/24/432209.aspx
I think you probably need to go back to the drawing board and see if you really need the windows service to do the uninstall. You'll probably come across all sorts of Vista UAC issues if you haven't already...
Thanks to those offering help. This appears to be a permissions issue. I have updated my service to run under an Administrator account and it was able to successfully uninstall the third-party application. To Orion's point, though the Local System account is a powerful account that has full access to the system -- http://technet.microsoft.com/en-us/library/cc782435.aspx -- it doesn't seem to have the necessary rights to perform the uninstall.
[See additional comments for full story regarding the LocalSystem being able to uninstall application for which it installed.]
This is bizarre. LocalSystem definitely has the privileges to install applications (that's how Windows Update and software deployment in Active Directory work), so it should be able to uninstall as well.
Perhaps the application is initially installed per-user instead of per-machine?
#Paul Lalonde
The app's installer is wrapped within a custom InnoSetup Installer. The InnoSetup installer, in turn, is manually executed by the logged in user. That said, the uninstall is trigged by a service running under the Local System account.
Apparently, you were on to something. I put together a quick test which had the service running under the LocalSystem account install as well as uninstall the application and everything worked flawlessly. You were correct. The LocalSystem account has required uninstall permissions for applications in which it installs. You saved the day. Thanks for the feedback!