How can I programmatically restart the Microsoft Test Agent that would be equivalent to pressing the Restart button within the Test Agent Status window? I'm willing to go about it any way possible. Batch file, C# app, Powershell, etc.
Note: Since I am running UI tests, I need to run the Test Agent as an "Interactive Process" and not a "Service"
I had the same problem because of QTAgent handles not properly closed after a test execution and succeeded in restarting the agent by doing the following in a batch file:
taskkill /f /im qtagentprocessui.exe
start "" "C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\QTAgentProcessUI.exe"
Restarting the agent services did not suffice to close the handles...
Hope this can help.
Related
I am building a .NET 6 application in C# using Visual Studio 2022. The application has a worker service that runs a console application. A Group Managed Service Account (gMSA) has been created for me and I can successfully install the service (using PowerShell) under the gMSA credentials on my local PC as well as a staging server. The gMSA passes Active Directory credentials from the service context to my application and works correctly. However, I do not have a way to debug my application using the gMSA account on my local PC.
Using a container or Azure is not an option and because this is a console application, an IIS-based solution is not possible either. I initially thought I would use runas to log into Visual Studio 2022 as the gMSA, but learned that runas would not work with a gMSA and that the preferred method to log into an application as a gMSA would be to use PsExec (64-bit version).
I attempted to do this, but was only able to log in via a command prompt as "nt authority\system" using
C:\psexec\PSExec64.exe -s cmd.exe
When I would attempt to log into the gMSA using
C:\psexec\PSExec64.exe \\local_pc\c$ -i -u gMSA_username -p ~ cmd.exe
no error message was displayed, but also no Microsoft copyright message (which is what is displayed when the command is successful). This seems to suggest the command failed in a way that could not be reflected in an error message. (It is worth mentioning that I also tried using both commands to open up a PSExec pipe and then connect using a gMSA, but I could not get that process to work.)
Adding to this issue is that Visual Studio 2022 no longer offers the "Start external program" functionality under the Debug section of a project's properties. So even if I was able to run a command prompt under a gMSA, I do not know how I could use that knowledge to log into Visual Studio under the gMSA credentials.
I would like to know how to debug my console application running as a service in Visual Studio 2022 using a gMSA. I am willing to do this using PSExec or another method. Any assistance offered will be greatly appreciated.
There were a couple of issues I had to resolve to be able to debug my .NET 6 service running a console application in Visual Studio 2022 using a gMSA. Here is how I got this to work:
At some point while I was trying to resolve my issues, the gMSA membership for my development PC was removed by another person in my IT Department. As it was explained to me, another computer was added to the gMSA, but the PowerShell command that was used overwrote the existing gMSA membership, including my development PC (the command adding a new computer to the gMSA membership should have included my development PC and any other existing gMSA computer members). Once this was resolved, I could tackle other issues.
Because I could find no way to share the gMSA context directly within my development environment (Visual Studio has no means, to my understanding, of running as a system process, gMSA, or an impersonation of a gMSA) I decided to try to attach a debugger to the service while it was running. This did not work until I discovered an SO post on a bug in the Visual Studio Just-In-Time Debugger. Per this post I navigated to
Computer\HKEY_CLASSES_ROOT\AppID\{E62A7A31-6025-408E-87F6-81AEB0DC9347}
in my development PC's registry and changed the value of AppIDFlags from 0x28 to 0x8. This got the Just-Time-Debugger working.
Once these issues were resolved I placed
#if DEBUG
Debugger.Launch();
#endif
in the StartAsync method of my .NET 6 worker service (worker.cs) so that the debugger would function within the gMSA context. After publishing the code to the location on my development computer that corresponds to the executable path accessed by the service I started the service and was prompted to attach the debugger. Upon doing so, I was able to debug under the gMSA context and access Active Directory via the gMSA in my Visual Studio 2022 development environment.
I'm running a .Net Core microservice on Linux (Ubuntu) and am trying to remote debug with Visual Studio over SSH. But the service is run under the user svcuser and my user is mainuser. Main user is in the same group as the service user.
In visual studio, I can see the process that the service is running under, but when I try to attach I get:
One or more errors occurred. Failed to attach to process. The .Net Debugger has insufficient privileges to debug the process. To debug this process, vsdbg must be running with root permissions.
I checked in MS documentation but for Linux all they have is this: https://learn.microsoft.com/en-us/visualstudio/debugger/remote-debugging-dotnet-core-linux-with-ssh?view=vs-2019 which has no info on running the service with a different user
And the only info they have on fixing such a problem is for windows only: https://learn.microsoft.com/en-us/visualstudio/debugger/error-the-microsoft-visual-studio-remote-debugging-monitor-on-the-remote-computer-is-running-as-a-different-user?view=vs-2019
If you have sudo privileges then this is relatively easy, and can be kept secured to those users with sudo privs. Avoids needing to reconfigure users/environments, and allows you to debug any process on the machine regardless of which user account it is running as.
If you use Visual Studio to make an initial attempt to debug you will find that a ~/.vs-debugger folder has been created in the home directory of the user account you were attempting to use. This command will help you locate the vsdbg binary which was installed. You can install VsDbg manually but I find leveraging the automated process is easier. If you are using VSCode this becomes a manual process, and an exercize left for the reader, but I would still use VS2019 IDE to prep the target just to keep things consistent between tools.
find ~ | grep vsdbg
For my installation the binary is located at ~/.vs-debugger/vs2019/vsdbg and this path will most likely change over time.
First, rename the binary to something convenient:
mv ~/.vs-debugger/vs2019/vsdbg ~/.vs-debugger/vs2019/vsdbg-bin
Second, create a script to replace the binary:
touch ~/.vs-debugger/vs2019/vsdbg
chmod 770 ~/.vs-debugger/vs2019/vsdbg
nano ~/.vs-debugger/vs2019/vsdbg
The script content might look something like this, note the full path to vsdbg-bin, the use of $# ensures all command-line args passed to your script are forwarded to VsDbg.
#!/bin/bash
sudo ~/.vs-debugger/vs2019/vsdbg-bin $#
Now retry your debug session from Visual Studio, if you did things correctly you should be able to attach to any remote process on the target machine using SSH->VsDbg. "Works on my machine." ;) This was confirmed with VS2019 16.8.4, .NET 5.0, and VsDbg 16.9.20122.2 debugging an ASP.NET Core application running on Debian 5.4.8 (x64) launched by systemd under a service user account in Azure. "Sweet."
HTH!
We have a big WIX Installer. After the installation, there are around 2800 scripts that should be run to upgrade the database. For that purpose, a special application is created. It just goes to the SQL machine, installs prerequisites like SQL SMO and SQL Sys Clr Types, and executes scripts. This small application is run in custom actions in WIX. Logically, it should be run with elevated privileges. In this custom action, I am using c# Processes to start the app. However, I have tried everything, and the application is still not working properly. It opens the app and app tries to install prerequisites and just exits - nothing is installed. What I have tried:
1. Running process with elevated privileges (process.StartInfo.UseShellExecute = true)
2. Running process with user privileges (standardinput/output with UseShellExecute=false)
3. Running the app with a batch file.
Overall process should be as following:
Installer is run with elevated privileges -> After installation, special application is run to upgrade the database -> the app installs prerequisites -> the app executes scripts.
The interesting part is that application is working properly when I do it manually with cmd. However, when installer's custom action opens cmd.exe (c# Process) and it is still waiting, then manually opening application via cmd is not working. In other words, I have cmd (with elevated rights) opened by installer and another cmd opened by myself manually. Then, manual running the application is not working. As soon as I close the cmd opened by the installer, and run manually the application via cmd that was opened by myself, then again everything is fine, everything is working.
I need a help how can I fix this?
P.S. The installer's prerequisites cannot be extracted and installed separately. We do not have source code of upgrade database application.
After some research, I have found that Windows cannot run two MSI at the same time and therefore, second MSI was silently quitting.
When I run my selenium test (mvn test) from jenkins (windows) I see only the console output. I don't see the real browsers getting opened . How can I configure jenkins so that I can see the browsers running the test?
I had the same problem, i got the solution after many attempts.
This solution works ONLY on windows XP
If you are using jenkins as a windows service you need to do the following :
1) In windows service select the service of jenkins
2) Open properties window of the service -> Logon-> enable the checkbox "Allow service to interact with desktop"
After then you should reboot the service jenkins
Hope this help you :)
UPDATE:
Actually, I'm working on a an automation tool using Selenium on Windows 10, I've installed Jenkins ver. 2.207 as windows application (EXE file), it's running as windows service and ALL drivers (Chrome, FireFox, IE) are visible during test executions WITHOUT performing a mere configuration on the System or Jenkins
I got the solution. I ran jenkins from command prompt as "java -jar jenkins.war" instead of the windows installer version. Now I can see my browser based tests being executed.
If you are already doing what #Sachin suggests in a comment (i.e. looking at the machine where Jenkins actually runs) and still do not see the browsers, then your problem may be the following:
If you run Jenkins as a service in the background it won't open apps in the foreground. You may either try to run it not as a service in the foreground, or run it as a Local System account and check Allow the service to interact with desktop option. In the latter case you may get into permission problems, though.
Update: To make sure this answer is understood properly by others: Jenkins Windows 'native' installation is not really native. It's a wrapper around Java that runs it as a service.
To interact with desktop GUI, you should launch slave agent via JNLP:
https://wiki.jenkins-ci.org/display/JENKINS/Distributed+builds#Distributedbuilds-LaunchslaveagentviaJavaWebStart
After adding the node in Jenkins (configured as Java Web Start launch), just make a startup batch script on the node machine:
java -jar slave.jar -jnlpUrl http://{Your Jenkins Server}:8080/computer/{Your Jenkins Node}/slave-agent.jnlp
(slave.jar can be downloaded from http://{Your Jenkins Server}:8080/jnlpJars/slave.jar)
See more answers here:
How to run GUI tests on a jenkins windows slave without remote desktop connection?
In the case of Windows 7 you should not install jenkins as windows application (because in this recent version, Microsoft decided to give services their own hidden desktop even you enable the functionality "interact with desktop" in jenkins service), you may have to deploy it from a war file as follows:
1) Download jenkins.war from Jenkins official site
2) Deploy it by the command prompt : java -jar {directoryOfJenkinsFile}/jenkins.war
3) Now you can access jenkins administration on http:// localhost:8080
Hope that helps you !
this is an issue for Jenkins. on Windows it is possible to access logon user's session (screen) under system account. to make the UI testing visible, Jenkins needs to bypass UAC (user access
control) at background. this solution works for me with my own service running as system account.
I also faced the same issue earlier in my local machine (Windows 10).
My test was running perfectly from the NetBeans but when I moved to Jenkins it was only running in console mode. I was unable to view the UI.
So for that, you just need to make your local machine as a Jenkins slave by creating a new slave node in your Jenkins and select that node to execute the Jenkins job.
If jenkins installed by windows installer it is showing only Console out put only. To see browsers download jenkins.war file and run java -jar jenkins.war from command line.
Go through this site:
http://learnseleniumtesting.com/jenkins-and-continuous-test-execution/
If you have the following situation,
You are able to login to the remote machine
You don't see the Jenkins agent window
This slave machine is accessed by many users then try the following,
then try the following suggestion.
Login to slave machine
Go to Task manager
Users
Logout all the users
Then login again.
This worked for me.
I need to build a .NET application(x86) remotely using MSBuild.
My application basically has to register for the COM Interop in 64bit Windows 7 system
However since i'm running into some problems due to UAC.
I need to elevate the default permission of MSBuild to Administrator.
How do i do this? How can i remotely open a VSNET Command prompt with Administrative privileges. ?
I'm presently running with the switch in this line
C:\WINDOWS\Microsoft.NET\Framework\v3.5>MsBuild SolutionPath\Solution.sln /t:Rebuild /p:Configuration=Release /p:Platform="x86"
Or
Is there an efficient alternative ?
Thanks
runas command cannot run without manually entering password. Try to use psexec http://technet.microsoft.com/en-us/sysinternals/bb897553 by Mark Russinovich. It can run program on remote PC but also can run at local PC as specified user.
use runas command. http://msdn.microsoft.com/en-us/library/bb490994.aspx
Disable UAC if you don't need it. Use regedit to disable it completely. Disabling UAC using "UAC slider" to "do not notify" was not helpful in my case.