My environments are below.
AWS workspace - windows 10
Visual studio 2017 community edition
I tried to run sample x64 console code on my AWS workspace. But it failed every time. Even if I tried it with VS2015, the result was same.
If switching to x86, it works.
Is it possible to use VS2017 for developing x86 on AWS workspace?
AWS workspace is a kind of VM. So visualstudio debugger is not able to work under the host environment. The only workaround is remote debugging outside the host.
Related
There a lot of stuff regarding dockerizing apps in Visual Studio.I successfully managed to create ,run and debug my net.core app in Visual studio using local docker desktop ,wsl2 and kubernetes systems.
But it totally unclear how my app can be deployed to Windows server ,except azure deployment. How can I set in my visual studio or Windows terminal servers docker and kubernetes server instead of my local ?Just can't find any worth tutorials.
Thanks for help.
I want to remote debug an executable that is running on a Windows XP machine. This machine does not have Visual Studio installed. I am running Visual Studio .NET from another machine on the network. (I'm easily able to remotely debug other XP machines which have Visual Studio .NET installed).
I located the remote debugging tool (msvsmon.exe in this case) copied the folder to a local directory on the machine I wish to debug and ran it. The cmd window indicated that I was running "Visual C++ Remote Debug Monitor (x86) Version 7.00.96"
I attempt to select the machine from VS in order to attach to the process and I received an error:
Unable to connect to the machine . The debugger is not
properly installed. Run setup to install or repair the debugger.
As I'm not able to find debugging tools online that are old enough, I'm not sure how to proceed.
While there is still time, you should get a copy of VS2010 Service Patch 2, and install it, the version of msvsmon.exe in VS2010 is the LAST release which supports XP remote debugging. In my work we develop for XP Embedded, and have a large installed base used in manufacturing globally. Our customers would scream bloody murder if we changed the runtime which would break/damage/shutdown manufacturing. So we are now forced to migrate to VS2019 and yet we build for XP clients. Our new products do run newer Windows Embedded versions, but the legacy products are still in demand, and are XP embedded based. There is no remote debug capability to my knowledge with VS2019, and our firm is not allowed to distribute VS2010 to our clients so they can single step debug. Very frustrating.
When follow the tutorial Run Windows Store apps on a remote machine,Visual Studio 2015 can't connect to the remote debugging tools.
VS2015 finds the remote machine, and it can be selected. However when you will try to run the application on the remote machine, the Remote debugger will simply say "Connection from XXX failed".
Neither it, nor visual studio provide any clue as to what happened.
This happens because the tutorial links an old version of remote debugger.Current version can be found at their Download Center.
Up to date guide:
Deploying and debugging Universal Windows Platform (UWP) apps.
It seems to be Microsoft's custom to have multiple, mutually contradictiong versions of the same documentation.
I'm using TFS 2010 SP1 Lab Management and a variation on the LapDeployTemplate to execute build workflows and unit tests on a Hyper-V VM, managed via SCVMM (per the ALM Rangers Lab Management Guidance doco on codeplex). After configuring all of this, I've created a Test Plan containing test cases that map to automated unit/integration tests that use Moles. I've used tcm.exe import these test cases and get them into the Microsoft Test Manager.
I'm getting the following error when I try to execute test cases remotely on my VM using the LabDeploy workflow:
"The host type 'Moles' cannot be loaded for the following reason: The key 'Moles' cannot be found."
Normally, I've seen this error on machines where Moles isn't installed, but here's my configuration on the VM currently:
Windows 2008 Server R2
Moles 0.94.51023.0 x64
VS2010 Test Agent\Controller x64
VS2010 Build Agent x64
VS2010 Lab Agent x64
Test Settings file is set to use the Default Host type and to have tests execute in x64 on an x64 machine. This is identical to the development boxes we use and they all execute tests fine.
I've already tried an uninstall/reinstall of Moles as well as the test agent on the machine to no avail. Any ideas? Has anyone else ran into this?
Moving my comment to an answer so that I can mark it as answered - I've opened the Moles MSI in ORCA and it turns out that it has Registry conditions that prevent the Moles host agent from installing on a box without a full VS 2010 devenv install. Thus, I had to spoof that registry key to get Moles to install all bits. Once this was done, I got the agent to execute, but fails with errors dealing with environment config, etc. After looking through all of this and the lack of doco online for this scenario, I'm fairly certain it's not been tested nor is supported. I think that the Lab Agent for 2010 + Moles only configuration just doesn't work
I am working on a project that carries out actions against different versions of IIS depending on what is locally installed. I thought I had read that you could debug in different Virtual machine environments through Visual Studio 2010 if you have the VM's available.
I am working in a Windows 7 environment but need to test my code against a Windows 2003 / IIS 6 environment. Am only limited to creating that environment (VM and all necessary development tools) and testing my code locally?
My question wasn't as clear - I want all the benefits of running in debug mode that I would get if I was developing directly in that environment.
I think I found my own answer:
Remote Debugging of a Project Built Locally
http://msdn.microsoft.com/en-us/library/8x6by8d2.aspx
I'm not sure if you can automate it, but you can remotely debug from visual studio to code running on another machine. If I remember correctly, the trick is (if you're on a domain network) to log into both machines with the same user account (I did this in an active directory networked type environment).
It may have changed in 2010 (I'm on 2008 today), but start the debug instance on the remote machine, then from the VS debug menu, choose "Attach to Process", change the transport to "Remote" and enter in the machine name.
You should then be able to attach to the process, and set breakpoints and debug as you would any other session.