I'm trying to test my automation anywhere solution through Scheduling.
Bot. It is working perfectly in the virtual machine when it is triggered manually.
However when i schedule it through control room. Both object Cloning and Manage windows control are failing, since Virtual Machine is not opened manually.
how to overcome this issue?
yea, so there is a problem with AA running on citrix in the disconnected mode. currently there isnt any resolution to it. did you try running the task using RDP connection from control room option?
Related
Running a automated test against a desktop WPF application works fine on my local machine and on Azure VM Windows Server 2012R2 when accessed via RDP.
However, when the VM is used as build machine, controlled by test agent on TFS or VSTS, all test fails because of the screen resolution is set to 1024x768 screen resolution. The application is not configure to run until this display settings. Is there any way to change the screen settings when we deploy the test agent?
Change VSTS agent session screen resolution when running protractor tests
We've encountered the same issue on our Visual studio + Azure solution. To be able to execute the tests we need a higher resolution on the VM than 1027 x 768. But since it's Azure and you pay for machines that are turned on, we also want to turn them off after each run top keep the cost down (especially helpful when you want to scale up a bit).
Therefore it's a real pain that there is no simple option to let the VM boot in a certain (specified) resolution. If there is something more simple than what I'm going to show you, please let me know, but I could not find any. So I up-voted the idea mentioned by Nessi. What we did as a workaround was the following.
Idea's for possible solution
In essence we used this post as a guideline. The most important things we used from this was the Windows credentials part and the TERMSRV.
Our Setup
Visual Studio Build server
Four Azure VM's, one machine is the selenium-grid-hub the other three are nodes
Our Solution
First we let the Build server start all machines in the resource group (so far so good). Then we created a Powershell script that runs on the build server to the nodes to check and waits for the RDP service to become available. This was needed since it can take up to 10 minutes before we see that this service is active. And finally we trigger a Powershell on the selenium-grid-hub VM to make RDP connections to all nodes in a certain resolution.
In a bit more detail to make sure it all goes automatically and without any manual input needed:
Creating and export/import certificates from each node into the hub
Making sure that the credentials are stored in the credential manager > Windows Credentails (we created one user on all machines to make life a tiny bit easier)
Creating a script for checking if the RDP service is active
We call this script C:\Scripts\RDPServiceRunCheck.ps1 (see example below) in a VS build block with the arguments $(Password) $(Chrome-node) $(Username)
Where all these arguments have been stored in variables on the build server
Here is the code for the script on github
Creating a executable for starting a RDP in a certain resolution
We call this script C:\Scripts\Resolution.RDP.Remoting.exe (see example below) in a VS building block with the arguments "C:\Scripts\$(Chrome-node).rdp" 1600 1200
Where the *.rdp file for each machine was stored (upfront) in this folder and 1600 1200 is the resolution we want to set
Here is the code for the executable on github
This is an older question, so thought it best to throw this out there if it helps anyone.
There is a Screen Resolution Utility AzureDevOps Build/Release task to change the screen resolution of the agent machine. Useful when running UI tests such as Selenium, Coded UI etc.
https://marketplace.visualstudio.com/items?itemName=ms-autotest.screen-resolution-utility-task
Try running the test headless I had the same issue with TFS and this is the only way it works for me
args: [
'--headless',
'--window-size=1920,1040',
],
Try using the below Powershell command, it is a 100% working solution
Set-DisplayResolution -Width 1024 -Height 768 -Force
This is a limitation with Azure VM since it use RDP to set the screen resolution. Refer to this link for details: Why is not possible increase or change display resolution in Azure VM.
The RDP session uses the RDP display driver, not the Microsoft Virtual
Machine Bus Video Device.
Although the RemoteFX feature enables a broader range of graphics
workloads than regular RDP, RemoteFX is not available for Azure VMs.
I am having the same problem. As there is a way to specify a resolution for an RDP session (even for an Azure VM), I created a UserVoice idea to get this desired feature (specify a resolution when running UI tests with "Run Functional Tests" task).
In the meantime, I am using a workaround. Our build VM opens an RDP session in the desired resolution (currently to cover different browser sizes this session runs at 4800x2700) to the test machine with the account, the UI tests are executed with. When there is an active session, the UI tests just connect to that session and uses the resolution that is currently shown.
This way we have a constant RDP session from the Azure build VM to the Azure test VM, but it works :)
My team has an InstallShield configuration that registers a service. Since it's supposed to be automatically started upon a reboot, we can't set it to manual. According to the person responsible for it, InstallShield only gives the option of automatic or manual service setting.
Not being an expert on InstallShield, I'm still trying to help her figure out how to make the registration of the service automatic but not started. I haven't seen any such option in the client.
Am I looking at the wrong spot in InstallShield or is it not doable that way all together? If so, how should one approach the problem?
Assuming a Windows Installer project type in InstallShield, there are 2 different tables at play. ServiceInstall and ServiceControl. It is completely possible to define the service using ServiceInstall with start type Automatic and not actually start the service during the installer. It's the ServiceControl table that controls when to start/stop ( none, install, uninstall, both) a service.
For this situation I'd install the service as automatic and mark it for stop during both and start for none. You may also want to set the REBOOT property to ask for a reboot at the end of the installer.
Another option is to investigate why you can't start it right away. Is this a configuration problem or some other race problem? Often time fixing that will simplify the deployment story and allow her to start it during the install. One example would be if you don't have configuration data yet you have the service spawn off a background process that idles the service and puts a file system watcher on the config data. As soon as the data is there the service goes from idle to active without stopping and starting it.
TFS has this wonderful feature where if you connect to TFS and the project you are working on is not from that connection, it is closed and it tells you to clone.
I have a local TFS2013 on my machine. Due to some strange behaviour on the machine, I'm able to connect using 1 of 3 address
1. http://localhost:8080/tfs
2. http://127.0.0.1:8080/tfs
3. http://myMachineName/tfs
The issue if I am able to connect with localhost then the next time I connect with say 127.0.0.1, I cannot work on the previous project with TFS. The solution closes and it asks me to clone the project again. If I'm able to connect to the previous address, then I can continue with my work.
It appears it see these 3 as different servers.
Is there a place I can change the TFS address for the solution to point to which ever one I'm able to connect to?
You can edit the sln file in a text editor (or you may be able to do it in VS by going File->Source Control->Advanced->Change Source Control)
When connecting to a remote TFS 2010 installation via my Visual Studio 2010, Process tab of Build Definition freezes. Everything seems to be disabled. Is there any work-around?
UPDATE 1:
By freezing I mean:
I can navigate to all tabs: General, Trigger, Workspace, Build Defaults, Process and Retention Policy. Except for Process tab, they all are working as excpected. When I click Process tab, it is showed, but none of parameters are shown, and the tab itself is in gray. Actually nothing could be clicked. It is like that Visual Studio is waiting for something to be completed or loaded.
UPDATE 2:
I have explored that when I leave Visual Studio alone for a long time about 20 or 30 minutes, the Process tab goes normal. That means all parameters appears and can be edited. That seems downloading or getting something from server causes this very very long delay.
You might want to check out exactly what rights you have on that server with regards to administrating builds.
http://intovsts.net/2009/09/03/more-fine-grained-permissions-in-tfs2010/ and
http://msdn.microsoft.com/en-us/library/ms252587.aspx
I think one of the main ones is "edit build definition"
If you don't have rights, then there won't be a workaround.
UPDATE:
The only things I can really think of at this point is to put a sql monitor on the TFS Database and possibly, watch the network traffic to see how the network interface is being used.
It's possible that something is wrong on the database server causing a huge amount of load. The other possibility is that the network is badly configured and running at 1Mb instead of 100Mb+.
Beyond those, I'd say call MS Support and open a trouble ticket. This is by no means normal and is likely indicative of some underlying hardware or installation issue.
Afsharm,
Happend with me too. This happened when i had the build defination open on one VS instance in edit mode and i opened it for editing on another pc. After a while it errored saying "TFS 20391: Locked for blah blah..." I had to close my visual studio instance on both the machines and restart, it worked there after. These are very occassional cases and very hard to replicate. I would suggest restarting your visual studio session and trying again.
PS - Worth checking if some one else have the process template open for edit as well?
HTH.
Cheers, Tarun
I was thinking about installing TFS on my development Window 7 computer so I can have a sandbox to test things in TFS on a project that I know I have control over.
Right now I see the other TFS instances that we have stood (prod10\deve10\tfs08) I don't know if I see those b/c of some setup\config on part of the systems\admin's or b/c they are on a server os, or for some other reason.
My question is, if I do install TFS, will other people see that instance in there available TFS servers when attempting to connect or change connections in Visual Studio? If so it there a way to prevent that, essentially making the instance private (which I guess is kind of an odd request since tfs it is about collaboration).
Thanks
By default your local instance of TFS won't appear on your colleagues available servers. If they attempt to connect to your TFS instance and you haven't granted them permissions to the projects or collections then effectively your local instance will remain private.