My windows server runs two projects (Node and Golang). Both projects start using cmd commands. Sometimes one of the projects get stopped. So I'm currently trying to implement an solution for that. Which is if one of those projects exited with an error I want to send an email to notify that. I tried Windows task scheduler but send email option is deprecated in Windows 10. Is there any alternatives I can use?
Related
I have a .NET5 solution that is made up of several applications that communicate with each other using named pipes. In particular, there is a central service application (implemented using BackgroundService from Microsoft.Extensions.Hosting) and also an "Agent" that is responsible for launching the main service if it isn't running already, monitoring its status and relaying user commands to it. There are also a number of class libraries shared between the applications.
I've already configured the projects in the solution so they all build to the same output directory and I've set <UseCommonOutputDirectory>true</UseCommonOutputDirectory>.
After I launch the Agent in the debugger, it launches the service.exe using Process.Start() (it is not a Windows service). I can then (manually) attach to that process to debug it, too.
However, I'm wondering if this experience could be made smoother somehow:
Is there a way to set this up so the debugger would automatically attach to the child-process when it launches rather than me having to do it manually?
Is there a way to tell VS that it should also automatically rebuild the service and its dependencies when I launch the agent with F5? I keep forgetting this after making changes to the service...
I am aware that I can set up multiple startup projects so they all launch in the debugger simultaneously and that works for some debugging scenarios but I'm currently looking at a case where I really need the service to be launched by the agent and not separately before.
I have an program which I need to run on multiple PCs (>100) all in same domain and share the same user and password.
If I run a program manually, it opens a console windows where I can see the logs running. I can remote desktop and still be able to see the console windows open and logs running. It helps in debugging as I can see whats going on. Issue is I want to avoid running it manually on all PCs.
I have following requirement
a. It should be able to run program on multiple pcs remotely
b. program should open in foreground where console logs can be seen.
c. launching PC should launch program on PC1 and then (without wait for the program to finish on PC1) it should launch the program on PC2 and so on.
I explored STAF it needs to be installed on all stations. Its heavyweight, needs complex configuration.
I explored power shell , it needs to be enabled on all stations and also probably (read somewhere) has issue with running tasks in foreground.
psexec can run the program but it does it in background, if I use -i option I need to give session id so only it will show the console for a specific remote desktop session. Another major issue with -i is that it will interactive so it waits until the program exits.
Looked a paexe, its simillar to psexe and doesn't solve the issue I am facing with psexe.
Any help is greatly appreciated.
If you have a server, you can put the program on the server and create a shortcut to it (assuming the program is small/simple enough to run on a network share).
You can use One-Click to deploy the programs, and give each of your users a link.
You can change the program into a website for central access.
You can use group policy to deploy the program when a user logs in, assuming you can create a .msi file from it.
We are successfully using the Jenkins CI server on Windows 7. It mainly does compiles using CodeWarrior. Using the Win32::OLE library in Perl to automate the IDE, I recently added a new Unit Test job that compiles then also starts the debugger, runs a test thread on target hardware, then stops. It works fine when I start it from a command line under my user name, however when Jenkins starts the same task the IDE consumes all the CPU and never ends. Under the Windows Task Manager I see the IDE running as a SYSTEM user. I suspect there's a new pop-up message I haven't accounted for in my OLE automation, but can't see it because it's a background task now.
Is there a tool or technique to help debug windows that Jenkins starts as a system user but aren't visible?
You need to run Jenkins not as a Windows service, and then you should see the IDE pop up on your desktop.
I have created a BuildProcessTemplate that invokes a custom compiler. This compiler is normally running inside a command shell. It spawns lots of other processes running in a command shell in order to compile the code in parallel.
Now we are migrating to TFS and would like to trigger the build process from TFS. This works fine using the "InvokeProcess" activity. However, when the InvokeProcess activity is started, the command shells are not shown on the agent computer. They are running in the background. We would like them to be displayed.
Is it possible to somehow tell the InvokeProcess that it should interactively start the process?
Thanks for your help,
Christian
I found the solution...
The Build service on the agent machine needs to be run as an interactive process, not as a service. This can be configured from the TFS Administration Console:
Just tick the "Interactive Process" radio button.
(On this Image both TFS application tier and Build service is on the same machine, which should not be done by the way!)
I have cruise control with Nant running on windows 7 machine .Builds work just fine. But I have a task for which i need to start a batch process which opens up an application window (directX based application) and perform some tasks. But this nant task fails all the time , the very first call for device getdevicecaps fails .this thing works on XP. Please help!
And yes if it helps, I am unable to add any publisher tasks to the cruise control server configuration .
This was not the answer you were looking for.
That's because Windows 7, Vista, and the 2008+ flavors basically shut down the ability to open an interactive window from a service completely. Why? Because opening up a UI and presenting it is a huge security risk -- someone with a lower amount of credentials could in many scenarios do tasks they weren't otherwise allowed to do.
AFAIK, the only way you can get around this is to rewrite the task.