I am developing windows store apps for the surface tablet.
I am remote debugging onto a surface tablet via the local network. At first I had no issues with this, and then occasionally about one out of every four times it would fail to deploy, and I would get the message:
Error: Unable to connect to the Microsoft Visual Studio Remote Debugging Monitor named 'my_debugging_tablet'. The debugger cannot connect to the remote computer. The debugger was unable to resolve the specified computer name.
Initially when this happened, I would simply deploy the project again and the error would not occur again, or, occasionally, I would close and then re-open the Remote Debugging Monitor on the tablet, but generally this would happen seemingly randomly and not re-occur.
However, lately, it has been happening more and more often (with no changes to my code) and now I have been unable to deploy at all, ever, for a couple of days now (and thus I cannot debug on my tablet.)
The same error message listed above is what displays every time I try to deploy or debug.
I verified in project properties that the target device and remote machine name were set correctly, and each time verified that the connection on both the surface tablet and my host computer were fine (my host machine is Windows 8 on Oracle Virtualbox.)
From project properties, if I attempt to manually "Find" the target device (as it does when you deploy back when this used to work) it is unable to locate my tablet (or anything) on my local network. ("Found 0 connections on my subnet")
My MS developer license registration is up to date as well. Additionally, there doesn't seem to be an issue the local network, as both my host machine and the tablet can "see" other things on the network (printers, etc.)
I can't for the life of me figure this out, because, as I mentioned, there have not been any changes to anything such as developer license registration, network status, code, or anything else that should have affected this.
I originally read your question and thought you were saying the two devices could see each other, except through Visual Studio. I was scratching my head at that.
Visual Studio just uses the OS to resolve names and addresses. I recommend troubleshooting the connectivity problems outside of VS, as the problem is larger than just trouble with remote debugging.
Try nbtstat -n to verify you can see what you expect on your network.
Related
I automate processes on a remote computer. When I start a process from the control room, that works totally fine. But as soon as I minimize or close the remote computer (I don't shut it down, I just close the window), the remote computer crashes. The log contains entries like that elements cannot be found. The reason is, that the remote computer does not even open the applications.
So, what's the reason for that? The computers state is on desktop, so there is no screensaver or logon screen.
Expected result: The robot should work finely even when the remote desktop session is not on screen, like in production environment.
You haven't specified, but the below answer extrapolates your statements regarding how you've "[minimized] or [closed]" your "remote computer" to assume you're leveraging Microsoft's Remote Desktop Connection utility/protocol.
Blue Prism specifically discourages the use of Remote Desktop to manipulate remote Runtime Resources within a Blue Prism-based environment, as the use of the protocol itself causes the methodologies Blue Prism uses to locate elements in the Windows desktop environment to stop working entirely. This is explicitly spelled out in Blue Prism's official documentation on Remote Access Tools:
The following tools have been deemed to be specifically unsuitable for
providing remote access to Blue Prism environments:
Remote Desktop Connection (RDP)
The way that this Windows tool (and other tools that
use the RDP protocol) handle session management is not compatible with
Blue Prism:
The underlying operating system is aware as a connection is established which can, subject to the automation techniques being
applied, result in the executing automation being interupted.
It requires the remote access credentials to be aligned with the credentials used to authenticate the target system against the network
which presents a potential security risk.
As a user authenticates any previously connected users are locked out.
Each connection creates a separate desktop session.
The connection is not maintained throughout a system reboot.
I have code in many Microsoft Access Applications that populate a list with the names of all available printers using code like this:
For Each ptr In Application.Printers
...
While running an application locally, procedures using this code run very quickly.
While running the same application in a Remote Desktop session it takes usually only a few seconds.
For one client, this one line of code takes 90 seconds to execute, but only the first time each day per user, even after the remote desktop session is properly terminated and restarted. The problem then resurfaces for me hours later or the next day.
The Server is Windows Server 2008 R2 Datacenter, SP1
Microsoft Office Professional Plus 2010 14.0.7188.5002
What have I missed?
If you allow the remote RDP session to include your LOCAL printers in that list, then it stands to reason that grabbing the printer list over the network going to be rather slow.
When you launch the RDP client, you can disable this “feature” of the remote system being able to use your LOCAL printer(s) for software running on that remote server. And even worse is your local session might have several printers on YOUR network - this whole process thus can take considerable time - and it can be rather slow.
So disable your local printer use - that option allows the remote server to communicate with and use your local printers - a slow process.
I would suggest you un-check this option when they launch the RDP client:
It turns out that a bad or faulty or somehow uncooperative printer driver set up on the Remote Desktop Server was the culprit. Even when local printers were turned off the 90 second delay was experienced. Removal of the bad printer setup on the server resolved the issue. Using local printers resulted in only a few seconds delay. Everyone's suggestion that the issue might be with Local Printers led to turning them off which then eliminated local printers as the culprit, so thanks all for your input.
I am using worklight 5.0.6 in Eclipse juno on Windows 7.
I made a simple form filling app. I am deploying this app on my PC, Making it a worklight server. I am accessing it from the instance of the app which is running on my phone.
It works fine as long as my Phone and PC are on the same network, that is, on local LAN.
But when I change the network to Internet, the app is not able to connect to the worklight server - which is, again, my PC.
My Questions are:
Where should i put the public IP address to access the worklight server?
Should i change the worklight version to make it work?
Also, I read solutions that you gotta run the "Build and deploy on remote servers" But i couldn't find the option for it, what i found was "Run on Server"
But i really don't know how to proceed after that.
Should i change the worklight version to make it work?
You should upgrade your Worklight from 5.0.6 to a later release regardless of the connectivity problem - it is a very, very, old release.
Also, I read solutions that you gotta run the "Build and deploy on
remote servers" But i couldn't find the option for it, what i found
was "Run on Server"
This is not related to what you are facing. This option is meant to be used as you prepare to move the development environment (the developer workstation) to other environments, such as QA, UAT and Production. This feature is meant to change the connectivity settings in the application. Again, not relevant for you at this time.
But when I change the network to Internet, the app is not able to
connect to the worklight server - which is, again, my PC.
The problem you are experiencing is expected. There is your PC, which acts as the local server, connected to the Internet via your router. And there is the device, also connected to the same network via the router.
As you disconnect the device from the local network, it is no longer able to connect to the server, which is still in the local network.
If you want that work still, you'd need to setup a server with an external IP address that your device will attempt to connect to, and be able to route the request to the Worklight Server... in short, in a development environment it is expected that you will be on the same network.
I have a VSTO-based PowerPoint add-in that runs fine on Office 2007 and Office 2010. I have users running this add-in every day, day-in, day-out.
I'm now working with a new client that uses Citrix for their desktops. I've never really understood exactly how Citrix works, but it appears that no-one has locally-installed software - they just run everything off the Citrix box. It's a very locked-down environment. They use Office 2010 and what appears to be Vista.
Anyway, my add-in is exhibiting strange behavior in this environment. Simply clicking one of my buttons on the ribbon sometimes gives an error (if the "Show addin user interface errors" setting is ON). The error says "An error occurred when calling the callback "ButtonClick".
Other times, clicking the button appears to have no effect at all (although I suspect that it's actually starting to do something and then crapping out before displaying any messages).
I'm confused, because (a) it works elsewhere, and (b) I catch and report exceptions in all my button-click handlers, so I would expect to see an error reported.
Because the environment is so locked down, and it takes literally weeks to get a new version of my add-in rolled out, I don't know how to diagnose this.
Any ideas?
Have you ever used RDP to remote into another Windows machine? To all intents you can consider Citrix to be a much fancier version of RDP. So you have a bunch of servers where users run their apps and desktops, and they connect remotely to them using HDX instead of RDP.
Your customer could be using XenApp or XenDesktop. In XenApp the users run their sessions on Windows 2008 R2 servers, with multiple users sharing each server. XenDesktop is similar except instead of connecting to a server OS, the user connects to their own dedicated workstation image. At a guess your customer is probably using XenDesktop since you say they are running on "Vista".
Diagnosing your problem is going to be tricky without access to a Citrix environment. For my debugging I'll generally install the remote debugging agent on the Citrix machine and debug remotely from my workstation. Occasionally I'll use Windbg or Visual Studio installed directly on the Citrix machine. If your customer is willing to give you access to their environment you can try this.
Other options include:
Add diagnostic tracing to your product.
Citrix provides some compatibility testing services, see: http://citrix.com/partner-programs/citrix-ready/test.html
As to what might actually be going wrong, Citrix does a range of hooking that can cause unexpected behaviour. For XenApp in particular the multi-monitor hooking is the main cause of things going wrong (I am not sure if this applies to XenDesktop as well). If you do a Google search on "citrix disable hooks" you will find a range of links that describe how to disable hooks using the registry. Disabling the hooks in this way certainly works for XenApp. I am not so familiar with XenDesktop, so I don't know if the same techniques apply. I'd certainly recommend trying disabling hooking for PowerPoint to see if your issues go away.
I'm working on a legacy app that needs to be continued in VS 2003; I cannot effectively debug it, though, because when I try to run it, I get the following dialog:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Deploy
Choose the device to target. If the .NET Compact Framework is not already on the selected device, it will be deployed along iwth your application.
Pocket PC 2002 Emulator
Pocket PC Device
Windows CE .NET Device
Windows CE .NET Emulator (Default)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I am running this (VS 2003) in XP Mode (Virtual Machine) on Windows 7. I do not have a connection (from XP Mode) to the device - a Symbol/Motorola PDT 3090 - so I get, "Unable to connect" when trying to run/debug/deploy in VS 2003.
What has been the case up to now is the developer would build the binary, adding debug messages, and then copy the binary over to the device and run it. Rather than continue this method, I would prefer to be able to debug it from within VS 2003. Is there a way to do this? None of the options (Pocket PC 2002 Emulator, etc.) seem to work...the device is attached to the computer via a usb. The Emulators won't work because they don’t have the necessary hardware (barcode scanner). So I need to use one of the *Device options, but have not been able to connect the usb port to XP Mode.
Does anybody have any ideas on how to debug without the constant copying-and-replacing of binaries, and the use of "show message"?
UPDATE
Alternately, if I can't run the app from within VS 2003 / XP Mode as an emulator, it would also be fine to run it on the attached Motorola handheld, attached via usb cable from the cradle to the desktop computer; I prefer the former, for the debugging capabilities afforded, but even the latter would be better than my current predicament (copying the files to the handheld device, detaching it from the computer, attaching it to the belt printer, firing it up, testing and repeat ad nauseum ad infinitum). ASAP (within two hours), I will set a bounty on this question.
UPDATE 2
If I try to run from VS 2003 in an emulator, and select "Windows CE .NET Emulator (Default)", I get:
"Emulator for Windows CE will not run within another copy of Emulator for Windows CE.
You just had to try, didn't you?"
?!? Is it saying this because I'm in a VM (XP Mode) session?
Then I select "OK" (the only option), and get, "There were deployment errors. Continue?" That trick never works; it even causes the build to fail (a rebuild fixes that, though).
UPDATE 3
Perhaps my problem with not being able to debug by connecting to the device itself is related to this msg I saw when booting up this morning (but I don't know what to do about it, IF this is the problem - do I need to search for a new driver for the Motorola MC3100?):
Devices or applications disabled.
Virtual PC/Windows CE Emulator will cause Windows to become unstable. Windows has prevented these drivers from loading. click here for more details.
The "more details" are:
Virtual PC/Windows CE Emulator
Microsoft
--------------------------------------------------------------------------------
Issue Description:
A driver is installed that causes stability problems with your system. This driver will be disabled. Please contact the driver manufacturer for an update that is compatible with this version of Windows.
Contact Information:
Web Site: http://go.microsoft.com/fwlink/?LinkId=26320
Telephone: 1-800-936-5800
That link (http://go.microsoft.com/fwlink/?LinkId=26320) ended up as: "Internet Explorer cannot display the webpage"
UPDATE 4
There is some headway (or perhaps just false hope) on the connecting to the device front:
I have 4 USB ports on my desktop machine. I plugged the USB cable into the 3rd from the top for the first time a bit ago. It then said it was recognized, and ActiveSync was finally able to make a connection.
So I then tried deploying the app again. The fourth option (the default - C.E. Device Emulator) failed as always. So did the penultimate choice (C.E. device). The second option, though (Pocket PC device), seems to possibly be working.
However, I got a cryptic err msg that just said:
#183:
I dismissed that and since then (it's been a good ten minutes now), the bottom of the VS Output windows has been saying "Launching Application" (with a blinking cursor beneath it) and the task bar has been claiming "Deploy started..."
Whether that is really of any value, though, it doesn't appear to be, as I am just "stuck" there...
Windows CE .NET Emulator (Default)
This should be the one you want, if you are running Windows CE.
The Barcode Reader takes the code and converts it to a string for you, so your code will never need to "decode" a barcode.
So, when you are testing your software using the CE Emulator, simply select the textbox you want to read the barcode to, and type that value in using your keyboard.
In your Windows 7 host PC's task bar, right click on the XP Mode VS2003 application. In the menu that appears select "Manage USB Devices".
Select your Windows Mobile device and hit the "Attach" button. Your XP Mode PC should connect via ActiveSync. (This assumes you've installed ActiveSync on the XP Mode VM. If not, you should do that first.)
Try rebooting the virtual machine. (Not the same as closing and re opening it). If that doesn't work, try a different USB port. You may end up reinstalling XP mode.
See also: How to Access USB Devices in Windows Virtual PC for Windows 7