I need Virtual PC (VPC) for testing my Visual Studio 2008/2010 applications, and I want to test and debug it using VPC running a clean install of WinXP (nothing else installed).
Back when I was running WinXP, I could launch a VPC session, do whatever I needed to (install my application, run it, debug scenarios, etc.), then exit without saving any of the changes to my virtual machine's hard drive.
There does not seem to be this option under Windows 7 - or, if there is, I have been unsuccessful in activating it.
Is there a way to make sure changes to my virtual machine are not saved?
Regards,
~Joe
This functionality is enabled by using 'undo disk(s)'. Check out this blog entry for info.
Related
I am currently trying to install my vb6 app on a Windows 8.1 computer via TeamViewer (it's kind of like remote desktop). However, the installation always hangs up after all the files are copied and this message is displayed:
Setup is updating your system
We've tried it on our own Win8.1Pro desktop (via Remote Desktop this time) and Win2008Server(both via Remote Desktop), and it installed just fine.
Right now, we've narrowed it down to one culprit - MyProjectInfo.exe the actual ActiveX .exe. Whether it is me trying to run the .exe for the first time to register it to DCOMCNFG or whether it is the setup.exe running the script $(EXESelfRegister) it just freezes up.
What differences should i look for between 1) our win8.1Pro and win2008server and 2) their win8.1? If it some coding/reference/dependency issue, what could be the cause for why it doesn't error in our desktops?
Thank you for all the help.
Uhmm... this is getting embarrassing.
Avast (present in the other person's Win8.1) was blocking MyProjectInfo.exe from running (which is basically what is does with $(EXESelfRegister).
To properly proceed with registering my ActiveEXE program, I had to turn Avast off for a while. And that was that.
This problem may also occur with other anti-virus scanners as well.
Trying to configure Visual Studio 2013 (pro, FWIW) to debug a VirtualBox host. I followed this guide and set up the host correctly: It works for kernel mode, but not for user mode. Here is the debugger settings:
When I use kernel mode it works (and I'm debugging the kernel successfully):
But I cannot do it for user mode. I ran:
dbgsrv.exe -t tcp:port=53902
and saw that dbgsrv.exe actually runs, but still I get this:
Actually it makes sense, since I never specified the machine name/IP (where should I enter it?).
The firewall is off and the machine is accessible via network (files sharing).
So how to accomplish user-mode-debugging (Windows User Mode Debugger, not Remote)?
Ok, silly me... the "Computer name" must match the VirtualBox host name...
I've tried to find an answer to this before posting this question. I've got a windows service running on another machine. I've written the service in C# and the directory from which the service executable runs holds both executable and debug files (.pdb). I'm attempting to remote debug the service for the first time using VS 2012 Remote debugging. I'm able to attach to the service process successfully. However, as this is my first time I'm not sure what I can do next. I've clicked the pause button and that pauses the service on the line ServiceBase.Run(ServicesToRun) which isnt much use to me. The service has a timer which sets off every 30 seconds and will run the code in the timer event.
My question is ... is there a way of stepping through the code using the debugger in such a scenario.
Do I need to have some debug specific code already in my codebase so that when a debugger attaches it will take me to a place in the code from where i can step through the code?
Thanks,
Andrew.
There are several ways to debug your developed remote application or windows service. If you were in your machine(local) that would be simple to debug.
System.Diagnostics.Debugger.Launch();
But as you are in different machine it depends how your both Machines are connected. Which means you have some limitations on debugging remote application/services.
A Quick search gave me the following result that seemed helpful to me for you,
You can use Remote Debugging Monitor that visual studio use for connecting to remote device and debugging. You can have a clear instruction here on How to: Run the Remote Debugging Monitor.
There's another tool which lets you debug remote application's after a proper setup. But it has some limitations or conditions that you must abide by.
Here is the tool named Remote Tool, you can find a detailed setup process from MSDN here on How to: Set Up Remote Debugging.
It has been clearly quoted there about the prerequisites for using this tool. But still I'm rephrasing those again for quick reviewers.
Prerequisites to use Remote Tool for Visual Studio
To debug on a remote device:
The remote device and the Visual Studio computer must be connected over a network or connected directly through an Ethernet cable. Debugging over the internet is not supported.
The remote device must be running the Remote Tools for Visual Studio 2012.
You must be an administrator to install the remote tools on the remote device. To communicate with the remote tools, you must have user access to the remote device.
Feel free to share if you get to a better and working solution.
Thanks for your response. It reminded me to post my solution here for others like me.
The solution is simple (It always is once you know it).
Ensure that you are running the same code on the target machine as you have open in Visual Studio. It has to be the same assembly and version else the debugger will not hit your breakpoints. Ensure you have your breakpoints setup where you want the debugger to break execution. Then attach to the target machine process and wait for the timer to kick in and run the process where you breakpoint is set.
Hope this helps.
Andrew.
I have program that I want to test on clean Windows installation. For now I have image in VirtualBox and I start program from shared folder, but this is not comfortable and I can't debug.
For debugging I found that I can use Remote Debugging Monitor, but still I want to automate whole process, especially uploading application on virtual machine.
I thought that VirtualPC would be better then VirtualBox, because this application was created by Microsoft. Unfortunately I can't find any info how to connect them.
EDIT:
After research: only possibility is to treat virtual machine as remote computer. There is no easier way. Project need to be published to VM using shared folders. After configuring in Visual Studion new release type for remote debugging all triggers automaticly and working.
I would:
1.Place the program in a pre-defined shared directory, such that it is immediately visible to the virtual machine after redeployment.
2.Remote debugger invokation can be automated - all the parameters, such as users allowed to debug can be passed on the command line.
VirtualBox is quite OK for this task, as it allows you to replace only the disk image with clean one, while leaving the setup, including shared directories intact. I am sure VirtualPC also allows such a thing, but choosing it just because it's also written by Microsoft does not seem like a valid consideration here.
I have two machines in two different domains. On both I have VS 2005 installed. I want remote debug between them. Without authentication it is possible but I want to debug managed code. I don't want to debug directly since it is really crappy machine.
When I try to attach with debugger I get message "The trust relationship between this workstation and primary domain failed." Any idea how to overcome this ? I tried tricks with adding same local username on both machines but with no luck.
EDIT: I have same local users on both machines. I started both VS2005 and Debugging monitor with RunAs using local users. I turned Windows Auditing on debug machine and I see that local user from VS2005 machine is trying to logon. But he fails with error 0xC000018D (ERROR_TRUSTED_RELATIONSHIP_FAILURE)
Gregg Miskely has a blog post on this. You might get it to work if both local accounts have the same user name and password. You might also try dropping your good box from it's domain so that you are going from a workgroup to a domain rather than domain to domain.
I seem to remember that I have sometimes found it useful to use RunAs when you run msvcmon (or whatever it's called this week - the remote debugging stub anyway), to force it to start as the user which you have set up to be the same on both machines.
I would guess that on the machine you're running VS on, you will also need to log in as the local user rather than a domain user (or start VS with RunAs).
I have never understood why this needed to be so hard, given that unmanaged debugging is so much easier, and must expose every security hole that managed debugging could.
The blog post wasn't totally clear that this would work, but I was able to run Visual Studio as my domain account and still debug a process on a machine that was not on a domain.
I have a physical development machine PHYSICAL on a Active Directory domain DOMAIN. I'm logged in and running Visual Studio as DOMAIN\employee.
I have a virtual machine VIRTUAL that is not attached to an Active Directory domain at all. This is the machine running the process I want to debug.
Like the blog post says, create local accounts PHYSICAL\employee (on PHYSICAL) and VIRTUAL\employee (on VIRTUAL). They both must be Administrators and have the same password as DOMAIN\employee.
The remote debugger and the process to debug must be run on VIRTUAL while logged in as VIRTUAL\employee. Then on PHYSICAL while logged in as DOMAIN\employee I can use "Attach to Process..." and connect to VIRTUAL to get a process list.