Hi!
I have some PDAs (windows mobile) to test my application. One of them is HTC Touch Dual, and it have some bugs in debugging. There is another ARMv6 device I can use, but it's far far away. So I can't use USB cable, but can use TCP/IP (internet, not intranet).
Do you know, how can I connect to remote windows mobile device to debug application on it?
We tried different ways and now we know this:
ActiveSync is bad. It disables all external connections to device and it's impossible (or just I don't know how) to remotely debug device while it's connected via ActiveSync.
We have created VPN, connected device via wi-fi to remote PC, and setup routes to device be accessible over VPN. At this step device can be connected without ActiveSync (MSDN) from Visual Studio on remote PC. But connection from Visual Studio on my PC was not available - "device not ready". I can ping device, but can't connect it from Visual Studio.
I've checked following things:
binaries versions to connect without ActiveSync to be correct as said in MSDN article above
routers/firewalls don't block anything
device is ready to debug
sniffed packets to device looks similar in case of remote PC connection and my PC connection, but somehow my PC establish only 1 connection, while remote 2
I think, VPN and PDA connection without ActiveSync was very close to get remote debug, but something goes wrong with it. Maybe I just need some sleep now :)
And the questions are:
Do you know, how to debug remote winCE application in a simplier way?
What a problem can be with "VPN method" if it's the simplest way?
Thank you.
You can achieve this via CoreCon... After Microsoft moved from EVC to Visual Studio they deprecated Platform Manager in favour of CoreCon.
Take a look under C:\Program Files\Common Files\Microsoft Shared\CoreCon\1.0\Target\wce400[targetarch].
Basically you run ConmanClient2.exe and then CMAccept.exe which opens a window of time in which you can establish a TCP/IP connection via the IDE.
You can override the need for CMAccept.exe via adding the reg key HKEY_LOCAL_MACHINE\System\CoreConOverrideSecurity=DWORD:0x01.
After CoreCon is running on your target device, you need to point the IDE to the Device via the 'Device Options'/'Properties'/'Transport'/'Configure'/'Use specific IP address'. Simply set the IP to that of the device.
I have found CoreCon much faster and reliable than the old EVC infrastructure - the debugger definitely benefits from it. It has its fair share of limitations, but it doesn't depend directly on ActiveSync which more than makes up for it! :)
Related
I'm developing a website in VS on a Windows Server Azure VM, and remoting in to do my work through Microsoft Remote Desktop for Mac.
The website needs to access a webcam, but I don't have any webcam on the remote windows server!
Is there any way to allow the remote windows server where I'm developing to see my local webcam through Microsoft Remote Desktop, as my local machine is a Macbook Air?
Maybe there's another remote tool for Mac that will allow this? One I have to pay for?
Looking at the settings for Microsoft remote destop for Mac version 10.2.4 how can I set the local resources for USB connections? I don't even see a option for Usb device, just printers, clipboard and Smart cards.
All I see is this below with no options for USB connections
as of Dec 2018:
no, it is simply not possible with the latest Mac beta RDP Client
and a still open demand from user voice
The feature of USB redirection is part of so called RemoteFX and a feature of RDS.
From server side it is possible since Windows Server 2012, newer Versions improved it.
Windows Client (mstsc.exe or remote desktop client) support the USB and Video mapping for since ages, but of course negotiating with the server which features are possible and allowed.
this link gives a nice overview mosty without covering non-Windows:
https://workspot.zendesk.com/hc/en-us/articles/214248563-Configuring-USB-Redirection-with-RemoteFX-in-Workspot
to be afraid, the MS Mac client only supports the usual redirections like audio, printer, clipboard and drive mappings.
there are obviously other RDP clients out there, with experimental USB and webcam redirecting:
at least there is freeRDP which may also run on a Mac
I am developing an application windows 10 on a stationary PC. I also have a tablet windows 10 that once connected to the PC via USB not see debugging (
How to make it accessible?
Ok so I found an article that highlights how to debug a UWP application on a Surface pro using a cable:
Essentially the Visual Studio debugger wants to debug your application via a network, so you are creating a network between your desktop machine and your surface pro.
Below is the guide with the main steps highlighted
https://tomsoderling.github.io/Wired-Debugging-on-Surface/
Hardware Needed
In order to debug over a wired connection, you’ll need a few things:
2 USB to Ethernet dongles. You can find them for pretty cheap on
Amazon.
A length of cat 5 cable to connect the two dongles together.
Connect the dongles together with the ethernet cable, and plug one
dongle into your laptop and the other into the Surface.
Launch the remote debugger program on your surface and configure the following:
No Authentication
Turning this off seems to alleviate a lot of the
hassle of trying to get the debugger to connect to the remote client
app. I debug on a private or wired network and only have the remote
client running when I need to debug, so the lack of security doesn’t
concern me here.
Allow any user to debug
I use this setting because
don’t log into my Windows 10 VM via Parallels so I’ve had an issue
with that. I also use this when my coworker needs to debug on the
Surface.
And then your device should be found in the Auto discover in visual studio
A few useful pieces of information: I'm running Windows 8 Professional on a custom-built rig, and I am using a 'WiFi dongle' to connect my computer to the local router. I am using a home network, not a public/work/school network.
I installed the Windows Phone SDK. Piece of strawberry cheesecake so far. Coded my first simple browser app (as detailed on the Windows Phone Dev site) and hit the Run button, expecting my app to come to life and breathe in links and breathe out websites!
But instead, I got this:
Something happened while creating a switch:
Xde couldn't find an IPv4 address for the host machine.
In this case, the emulator wouldn't run at all. And so, I did my research and found out that the solution was this:
Remove all the switches from Hyper-V Manager's "Virtual Switch Manager", and make a new Internal one called Windows Phone Emulator Internal Switch.
I did, and the error did NOT show up again but it did screw up my WiFi and Bluetooth adapters (which I had to do a system restore to solve) and now both WiFi and Bluetooth peripherals are working again.
However, I got this error instead when running the emulator again:
The Windows Phone Emulator wasn't able to connect to the Windows
Phone operating system:
The emulator couldn't determine the host IP address, which is used to
communicate with the guest virtual machine.
Some functionality may be disabled.
In this case, the emulator did run, but I couldn't find my app anywhere. I did some research again and found that the solution to this was:
Delete the Windows Phone Emulator Internal Switch from Hyper-V Manager's Virtual Switch Manager.
Now, I created the switch to solve the problem in the first place. But I did delete it, for the heck of trying everything out. And no surprise there but, it went back to the first error.
I am now stuck in this paradox and have no idea how to escape it.
Thank you in advance!
follow the following steps to solve this problem
1.go to network and sharing center
2.go to change adapter setting
3.go to v Ethernet (internal Ethernet port windows phone emulator internal switch)
4.right click it and enable it(if already enabled then disable and enable it again).
Remove any Cisco VPN's or similar connections. I have found this VPN client works as a replacement to Cisco https://www.shrew.net/
For me shrew soft version 2.1.7 was the only version that worked.
I want to debug an app remotely on Windows RT (though this applies to any remote debugging, I guess), I don't want to open up my WiFi connection wide or handle complex software configuration every time I connect (firewall etc.).
I thought that maybe by using an Ethernet connection between my Surface and my dev machine, I could make the remote debugging work on top of that. Installing an Ethernet USB dongle on top of Surface seems to be easy, but I can't figure out how to make my dev machine actually find the Surface computer on it.
My set up is simple, dev machine connected to ethernet cable, connected to USB dongle, connected to Surface (Windows RT). Even when disabling WiFi, the remote debugger cannot find the debugee.
Do I need to manually set up the IP address or something?
Do I need to manually set up the IP address or something?
That's what I was thinking. What happens when you try to ping one machine from the the other? Does either machine run a DHCP server? If not you could run a DHCP server (probably on your dev machine) or setup a static IP address. Setting up DHCP may be harder at first but more convenient if you need to connect your tablet to other networks.
For testing it might be helpful to wire both devices to a router so you can configure and test Remote Debugging separately.
I'm trying to track down some bugs on a Windows Mobile 5.0 app. The testers can reproduce these bugs no problem, but I can't. They are using the devices across a wireless network, but I'm always running the app in an emulator, or on the actual device while it's in its cradle. In other words I always have a hard-wired connection.
I'm not sure how to approach this. Boatloads of logging? Is there some way to get Visual Studio to "Start Debugging" across the wireless connection? How does one effectively debug wireless connection issues on a mobile device?
You can get the debugger working over the wireless by manually running conmanclietn2.exe and cmaccept.exe, but the fact that the debugger is then using the connection may well affect your testing (depends on what the issues you're trying to find are). Your best bet is to use logging.
Another option to try is to enable the WLAN connection when you're device is in the cradle (I assume it now switches off the WLAN connection when you cradle it, which is the WM5 default).
If you're using Vista, go to the Windows Mobile Device Center and under Mobile Device Settings go to Connection Settings. Make sure the Allow Data Connections On Device When Connected To A PC option is ticked (I think the option is called the same in ActiveSync in case you're using XP). That way you will have an active WLAN connection when trying to debug through the cradle.