I have done some research on this, but still confused.
Im using Selenium 3 (C#) with a Chromedriver, Nunit 2.6.4, Visual Studio 2015, TFS and TeamCity 9.
I would like to run a Selenium test, using TeamCity, but I want to physically see the test run. I dont want it to run as a background process. I've seem some say something about running the user agent not as a windows service or to run it manually with some script. But this is where I get confused.
Do I have to add additional code to the project or do it some other way, like a batch file. Or is there another way to run the test in a non headless browser?
Im pretty new to this, so please be gentle.
Thanks in advance.
David
If you are running the TeamCity agent as a service they use a "hidden" desktop and you can't see them run.
You can run the the TeamCity agent as a process by opening cmd as administartor, change directory to BuildAgent\bin and write agent.bat start. Then you should be able to see the tests run. Remember to stop the service first
Go to The agent's service.properties and then set "web.app=true". It will be under the agent directory as "D:\BuildAgent3" if agent is installed on D drive.
Restart your agent..
From Now onwards, you should see the browser running in headful mode.
It worked for us in past, but later on we moved on to a Selenium Grid and hence this setting is not in use for us.
Let me know if it helps..!
Related
I am using Visual Studio Community 2022, and I was wondering if you could use another CLI to run/debug a c# console application. (I can't use cmd.exe or powershell because it's blocked by the admins of the device I'm using). Git Bash would be preferred, because it's already installed. Thank you!
Edit: Looks like you can't do this. dotnet run just tries to open the blocked binary, no matter where you run it. I think the admins hate everyone though because they allow you to install lots of things (like Unity, vscode, etc.) but running anything just doesn't work.
Thanks for trying everyone!
use this to run your program in CLI but you cannot debug it if you want to debug use debugger mode of vs2022,
If it's a framework-dependent application (the default), you run it by dotnet yourapp.dll.
Run the project in the current directory:
dotnet run
check Microsoft Docs dotnet run for more options.
CLI: Use Vs2022 Terminal in View->Terminal it may help You to run it.
I'm getting an error trying to use the Docker functionality with my .NET core 2.0 project. I've been getting an error message saying
Visual Studio Container Tools requires Docker to be running before
building, debugging or running a containerized project. For more info,
please see: http://aka.ms/DockerToolsTroubleshooting
I followed the link, and upon realizing I have Windows 10 Home x64, and had to install Docker Toolbox, instead of Docker For Windows. Now it installed this executable called
Docker Quickstart Terminal
Is this the way one is supposed to start up that docker services? I have tried running this executable, and it seems to be working. My containers are running, but the error for Visual Studio Container Tools still persists.
What am I missing? Is having a version of windows higher than Home required in order to use the Docker Container Support within Visual Studio 2017?
UPDATE:
I tried to follow Quetzcoatl's suggestion, and I am still getting the same error within visual studio about those tools. Here is what I ran in the Docker Quick Start Terminal. I tried building the project after Visual Studio successfully opened the project, and was still getting the aforementioned error regarding the container tools.
My devenv.exe file is located at
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\devenv.exe
and my solution file is located at
D:\Development\Visual Studio\Musify2\Musify2\Musify2.sln
UPDATE 2:
I ran some of the suggested commands to try in the docker quickstart terminal and here were the results of those commands quetz
With Docker Toolbox that's a little tricky, but actually the core-2.0 has nothing to do here. It's all about docker, docker-toolbox, and VS.
First of all:
Is this the way one is supposed to start up that docker services? I have tried running this executable, and it seems to be working.
Yes it is. If docker machine/services are running - that's good!
Now, you have to realize that in docker, typically, the information about how/where the docker is running is kept in environment variables. The quickstart script not only starts the docker-machine for you and checks some basic things, it also sets up a couple of environmental variables so that later all commands like docker, docker-compose etc know where to look for the docker virtual machine. In your/our case that information mainly consists of an IP of the VM and a port number that Docker listens on.
.. and your Visual Studio has no knowledge of that, because, I bet on that, you have ran the VisualStudio from StartMenu or from Desktop icon or by double-clicking on a solution file, so it had no chance of getting the environmental variables from quickstart console.
The solution is quite simple: make sure that VS gets that information. That is, make sure it gets that environmental variables, and make sure that it gets the fresh state of them, because the IP/port may fluctuate sometimes. So don't just copy them to your OS settings, because nothing will ever automagically refresh them..
The simplest way I found is to just close Visual Studio, run docker toolbox quickstart console, then run the VisualStudio from within that console, for example, for my VS2017 Community Edition:
Starting "default"...
(default) Check network to re-create if needed...
(default) Waiting for an IP...
(.......snip..........)
## .
## ## ## ==
## ## ## ## ## ===
/"""""""""""""""""\___/ ===
~~~ {~~ ~~~~ ~~~ ~~~~ ~~~ ~ / ===- ~~~
\______ o __/
\ \ __/
\____\_______/
docker is configured to use the default machine with IP 192.168.99.100
For help getting started, check out the docs at https://docs.docker.com
Start interactive shell
quetzalcoatl#LAP049 MINGW32 ~
$ /c/Program\ Files\ \(x86\)/Microsoft\ Visual\ Studio/2017/Community/Common7/IDE/devenv.exe C:\\PATH\\TO\\MY\\SOLUTION.sln
The path is pretty long to write, even with TAB-completion, so usually make a tiny .sh script to run that for me.
BTW! Notice that the path to DEVENV must be unix-like (/c/Program\ Files...), because the mingw shell has to understand that, while the path to SOLUTION must be a normal windows path (c:\projects\foo\bar\..) because VisualStudio will try to read that after starting up.
This is what I did to get vs 2017 working on windows 10 home with docker-toolbox. You follow this and i guarantee it will work. Note this only applies to windows 10 home which doesn’t support native docker for windows application:
Install docker-toolbox on w10 home
Run docker QuickStart terminal once to create the docker-machine. It takes a while. So be patient while it assigns the IP address and other things
Once it’s done it will show you a command prompt. Type ‘docker-machine ip default’. Note down the ip address as you’re gonna need it later
Close the QuickStart terminal window. That was just to initialize the boot2docker.iso image of a tiny Ubuntu linux server into virtualbox app (aka docker-machine aka default vm). If you’re not familiar with virtualization technology or oracle virtualbox stop reading and read up on them first and then start over. But if you do then gladly continue
As I mentioned that your docker-machine instance is a Linux vm and therefore it’s obvious that you can only open projects built using .net core technology. Unfortunately for full .net framework you’ll either need to run Windows containers which are only available on windows 10 pro or build your own windows nano server or 2016 server vm on virtualbox and then use and follow steps for native docker for windows on dockers website. From here on the remainder of this answer will be helpful to those wanting to run core projects on Linux vm / docker-machine only
Open windows power shell in administrator mode and type ‘docker-machine ls’ to confirm that default vm is running. Can also do ‘docker-machine status default’ and it should return ‘running’
Now open virtualbox application which is running your default vm and click on settings. Open “shared drives” tab where you need to make sure ‘c:\Users’ folder on the host machine is mapped/mounted as ‘c/Users’ folder in the vm. Note that this step is super important and missing it will cause a lot of trouble getting it to work successfully
Also a quick note that your solution/project/codebase MUST be saved under ‘c:\Users\‘ for it to work correctly. This is if you want to use it OOTB. I didn’t wanna waste time trying to mount a folder outside the permitted path. But if you’re the adventurous kind, please, by all means try to figure it out and let us know how you did
Now as Quetzalcoatl correctly mentioned vs needs to know about this docker-machine. The only way that happens is if the environment variables are set. Therefore go ahead and run this command ‘docker-machine env default | Invoke-Expression’ in the powershell window. This is the magic sauce getting vs to behave nicely with docker-machine
Go ahead and open vs normally either by dbl clicking your project solution or creating a new project/solution. In Powershell use the 'start' command to open your existing vs solution or a new vs instance. Pro-tip: if you create a new solution DO NOT select the option of Linux docker at the time of picking the project template type. You can totally add docker support once your solution is all setup and ready to go. Matter of fact leave it unchecked and let vs create your solution. This way you’ll get a chance to build and run your solution in IIS Express or Self-hosted modes to see if your core2.0 even works properly
Once satisfied that everything worked and you saw the OOTB homepage now it’s time to add docker support by rt clicking on your project, hovering over Add and then clicking on ‘Add Docker Support’. This will create a new docker project (.dcproj) and add a bunch of docker related files
Now I’m not gonna go into the nitty gritty of docker here however you’ll notice that your project is no longer the startup and the newly created docker project is. That’s perfectly normal and intended behavior. It means you’re setup and ready to fire up your app using docker containers. So go ahead and click on the ‘Docker’ button to see your hard work finally pay off. Again be patient as it takes a while to build images and spin up containers but once it’s done the vs will start and attach the debugger
Here you’ll once again be disappointed and feel worthless because when the browser opens a new window or tab there’ll be a page unreachable error. The reason is the browser address points to localhost which is not the web server anymore. Your “web server” now is your docker container and therefore you’ll need to replace localhost with the IP address you retrieved above. Port number remains as it is. Once you submit the page you’ll be relieved and ecstatic to see the home page/route work. This should also enable debugging in vs. if for some reason it doesn’t then you may need to delete a folder called .vsdbg in c:\Users\ folder and rerun the application.
I'm hoping that someone can help me I'm working on some Coded UI tests and when I try to play them back they run though but I get the below when they are finished.
Is there anything I am missing or do you have any ideas.
I get this from both recorded and hand written tests.
I'm using Visual Studio 2015 enterprise.
I have never seen anything like this, but you can allwais try to:
Reboot VS and try to run the test again
Reboot the PC and try to run the test agin
Make sure you are running VS in administrator mode
If the problem is still there then check the event viewer on the PC where you are running the test:
Right Click My Computer - Manage - Event Viewer - Windows Logs - Application
It is possible that you have some more information regarding that error there!
First of all, im not sure if there is a specific forum thats more suitable for request about Jenkins, but I figured I just post it here.
So, I have this C# project, it right now requires Visual Studio 2015 to build and I would like to automate builds with Jenkins. This is the first time I'm using Jenkins and I was able to set it all up, it fetches the code from the gitlab repository, but right now there is no build action configured. For "fun" i tried to simply make it use a "windows batchfile" as build file and added echo test. Checking the console output it downloads the repository code and then tries to execute the batchfile, result is:
java.io.IOException: Cannot run program "cmd" (in directory "/var/lib/jenkins/workspace/Project"): java.io.IOException: error=2, No such file or directory
This of course makes sense, but I wonder now, is there a way to build a C# project with jenkins on a debian server without resorting to mono or something? I know that people build C++ projects for windows with Jenkins on a linux root, so there has to be some sort of cross compiling possibilities.
If the Visual Studio 2015 is a dealbreaker I can also strap it down to VS13 or even below. Any help is greatly appreciated!
/EDIT
Its probably important to say that Mono is NOT an option. Im using features like WPF that are not available for Mono.
Use Jenkins' MSBuild plugin.
Jenkins.NET is a good blog about using Jenkins in a .NET environment. First post is here.
I've got a PS script that adds firewall rules.
I'm using Process.Start("powershell.exe", "-File "+"\"C:\Program Files (x86)\blah\blah\add-FirewallRule.ps1\"");
This command works fine on my local machine, but in testing I've been running the program on a Windows Server 2008 R2, and the PS script won't run. It runs and works fine if I run it manually from the command line, but my code won't work. All the file paths are correct (i've already checked that and had a co worker check it). When I run the code the PS console doesn't even pop up.
Any suggestions?
Since you are in C#, I'd recommend using the PowerShell Invoke API rather than Process.Start. The API is easy to use and hopefully will give you a better indication of what is going wrong.
Turns out that I wasn't accounting for the automatic redirect caused by running a 32-bit app on a 64-bit system. So all I had to do was go in and set the appropriate execution policy for the 32 bit version of powershell.
Have you tried running as Admin? I believe Process.Start requires elevated privileges that are not available in, say, sandbox mode.