I am trying to run automation tests remotely on a windows machine using from Unix box. I am using cygwin and openssh for it.
I am able to run the tests and take screenshots. However, the browsers launch and run in the background.
I cannot change the property of the CYGWIN SSHD service to "Allow interaction with desktop" because I cannot use the Local system account.
Is there any other way to be able to view the UI in the remote window machine while execution is going on?
Related
I have the Remote Containers extension setup so I can jump into a docker container for autocomplete etc. That's working how I want it to.
But it also sets the Terminal window to be inside that environment and I want to instead keep the Terminal window connected to my host machine. I can understand why it's useful to have Terminal from inside the container, but it's not useful for my usecase and it breaks some of my testing tools.
There are 2 commands in VS Code to open terminal windows when using Remote Containers extension:
Terminal: Create New Integrated Terminal will open a terminal window within a container.
Terminal: Create New Integrated Terminal (Local) will open a terminal on your host machine.
Latter doesn't seem to have have a key binding assigned, so you may want to add one.
I am able to execute it via power shell . But not able to directly run from IOT Device raspberry pi.
If there is not available option for execute Console Application from IOT device which is best alternative application platform for this?
IS there any tools availables that convert Console application to Application that can be run on IOT device ?
If you want to directly run the console application when you are in develop,
You can refer to this link to get the steps of running and debugging C++ console application on Windows IoT Core device.
If you use visual Studio to develop your application, you can install Windows IoT Core Project Templates for VS 2017 and then build a background application. Background Applications are applications that have no direct UI(Headless). Once deployed and configured, these applications launch at machine startup and run continuously without any process lifetime management resource use limitations. Hope that can help you.
it's easiest to view console output from a visual c++ app if you launch the app from an ssh session. try using putty to connect to your raspberry pi, and then run your commands in the ssh session. Instructions here To determine whether your visual c++ app is compatible with Windows IoT, you should run the iot core porting tool which is available here
I'm using VS2017 and have made a very simple 'launcher' for various RDP settings files using a Windows Forms application. This just calls Process.Start with a direct link to a .rdp file, or alternatively just straight to mstsc.exe
The application (and RDP sessions) displays and works correctly on standard PCs. However I have run into a problem on high DPI devices such as Surface Books/pros.
The RDP client not scaling correctly is a fairly well known issue, and we have fixed this problem using the manifest/reg change method. This is confirmed working. Double clicking a .rdp config file works correctly too.
( https://www.blackforce.co.uk/2016/04/18/remote-desktop-rdp-resolution-on-a-surface-book )
My own application also displays correctly at the correct scale. However, when I launch RDP using Process.Start, RDP client is scaled badly, as it always was before the manifest fix. I've tried opening the client alone, and with a .rdp file and result is the same. I open the same .rdp file manually, not via my app, and the client is scaled correctly.
Can anyone replicate this, or advise why the mstsc manifest file is ignored when started this way? I've also tried the using ProcessStartInfo to set UseShellExecute but still the same result.
Windows desktop apps, such as RDP, can specify a DPI-scaling mode ("DPI awareness mode") either through a manifest setting or via API calls during initialization. Applications will behave differently whenever the scale factor of the display that they're on changes. You can read more about this here.
I'd speculate (I haven't tried this to confirm this speculation) that the RDP process is using a manifest to declare it's DPI awareness (as Per Monitor DPI aware) and that when you're launching a process through Process.Start that the specified DPI awareness of the app is getting changed... possibly to the DPI awareness of the calling process?
I'd use System Internals Process Explorer to determine the DPI awareness of the RDP app when it runs as expected, and then compare that to the DPI awareness of the RDP app when it's launched from your app. If that is the case, look it to whether you can specify the DPI awareness of the process that you want to start in Process.Start. Another thing that you can try is to set the DPI awareness of your WinForms app to the same DPI awareness of the RDP app (per-Monitor) to see if that helps.
Also, I'm assuming that you're running on an OS > 8.1 as Per-Monitor support was introduced in 8.1.
I am configuring Windows 10 Enterprise (IoT) to run a custom shell, but running into the "Black screen with nothing other than a cursor" phenomena.
My application - a .Net4 Winforms app - is installed and runs fine from the desktop.
I can launch it as a custom shell via a batch file as per the comments here: How to run an application as shell replacement on Windows 10 Enterprise
But setting my app as a custom shell, I just get the black screen.
I note the comments in the above link about applications being signed, but I have tried two mini test applications (also .net winforms), one signed, one not, and both run fine as custom shells. (My application has several dependencies, not all of which are signed, so to sign it would mean going through the ILMerge mill or similar which I would rather avoid if I can.)
I don't expect people to be able to tell me why my app doesn't run (although that would be nice!) but I am looking for ways of diagnosing this. Looking in event logs, etc, is yielding no information whatsoever. My app keeps its own event log, which is not showing any evidence of the app starting.
Thanks in advance
Problem solved:
If a shell application requires elevated permissions, UAC must be turned off. Turning off notifications via the control panel is NOT sufficient, as UAC is still running in the background - it just doesn't notify you! To completely turn off UAC, edit registry entry:
HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System and set the DWORD value EnableLUA to 0
Evidence of UAC behaviour can be found in the windows event log at:
Applications And Services Logs -> Microsoft -> Windows ->UAC
A WinForms program I have developed prints fine and as expected when run as an interactive user. Using the same account but as a scheduled task, the process will run correctly however it prints part of the output in the incorrect font.
The program is a label printer that prints updated pricing labels. It has an option (-s) that the Task Scheduler calls which does not present the GUI but does an update and prints. Executing this as an interactive user through run works correctly (i.e. the correct font is used).
Any clues as to what's happening here? The font that isn't printing correctly is a non-standard system font.
This runs on a server and I thought it might be due to printer redirection but I did a console logon and it worked fine as an interactive process on the console just as it does as interactive through remote desktop.
Interesting problem. Presumably, Windows doesn't load fonts into the non-interactive logon sessions in order to conserve resources.
See this answer for one approach, using the ps tool to create an interactive session when running the task.
I had a very similar issue to yours (running an application through a scheduled task would use the default font but when running locally it would find the custom font I installed) and I found a solution; On Server 2008, there is an issue where custom fonts are not registered immediately after installing for non-interactive users, whereas regular users (i.e. when running on a user actually logged in to the machine) do have the font registered immediately.
The solution that worked for me was to simply restart the machine the font was installed on and the font started working under the non-interactive accounts, as when the computer is turned on it registers correctly. It appears the font installation has a bug where it doesn't register the font correctly for non-interactive users until a reboot.