I have two console application projects in a single solution and they are both configured to build to a common directory. The first app calls the second app via
Process proc = new Process();
proc.StartInfo.FileName = "myprocess.exe";
I can change my startup project and debug either one of them individually just fine, but I'm unable to step into the second project from the first project. When I look in build\debug I see the .pdb files for both apps and I know the second app is running completely through its routines. I just can't step into it. I've looked at Attach to Process and Debug:Location but haven't been able to find a solution yet. I've even tried putting them in different VS solutions, but to no avail.
So I need a way to step from the first project into the second project while debugging. Any suggestions would be appreciated.
Thank you.
You can use
Debugger.Launch();
which will bring up the dialog asking if you want to attach a debugger. You won't be able to 'step in' from the existing debugging session since it's attached to a different process.
Related
i have a solution
it has 2 projects inside.
there are an exe and a website.
the issue occurred when clicking F5 to start the debug process.
when i have set the exe to the default StartUp project. The exe can run normally, and the break point can be reached correctly.
however, when i have set the website to the defualt StartUp project. The website can be launched, however the breakpoint cannot reach. also the version isn't the latest one, it looks like it is loading the last succeed version (no error and warning too)
I have to right click the website project and click start new instance in the Debug every time I have modified something!(which is very troublesome)
Thus, I want to know why my F5 isn't equal to the Start new instance, as it is working normally in the other solutions.
I fixed that but the below procedures after struggled from extra many clicks compiling experience.
the cause is that there is unknown reason that the build checkbox isn't checked in the configuration manager. simply check it and everything looks fine again...
hopefully it can save someone time who suffered from this issue in the future
OMG!
when run projects in vs they just show up and disappear instantly
all of project's are c# console app and i ran them before and that was okay
i've try to reset all setting and that didnt work
If you want your console app to whait for input you can put that at the end of your main method
Console.ReadLine();
Then you need to hit enter to exit the console app.
Another possibility while debugging would be to add a breakpoint at the end of your main method.
It was set to something wrong.
Project start up was set to single project, not current project.
I guess we can add this question to the list. Basically It's been taking me twice the time to try something out because everytime I try to debug my app I have to wait about a minute to lauch the app. There are 3 files in order that it complains about.
Resources file (.g)
Program Debug Database
DLL (.dll)
I tried removing the first two, but then it complains about the DLL file. Strangely enough I have never encountered this and I've been using the the WP7 emulator in VS2010 for about a year. Any ideas? Is there possibly a setting or cache that can be deactivated?
Basically when you add images to your project, by default they are added as a resource. By doing this everytime you try to build the project the images are saved in the dll file thus the long wait time. I set 95% of my images to content and have not had the issue since.
I have a VS2010 running on a WTS machine (Windows2008).
I'm trying to attach the debugger into a process. The process is running a WPF client.
The process is presented in the attach to process dialog, but grayed out and the attach button is disabled.
I read through the discussions, and confirmed managed code is enabled for debugger, with no luck. Here are two screenshots representing the current situation (in the first image, the process I'm trying to debug is marked in blue - please note I'm running as admin):
snapshot goes here - but was removed by stack overflow...
After trying the automatic code type selection, I tried the manual way, with no luck. Here is the screenshot:
snapshot goes here - but was removed by stack overflow...
Any help would be appreciated.
Thanks,
Busi
Perhaps you are already attached to the process? Did start debugging before attaching to the process?
Found another cause/solution to this problem, select the 'Show processes from all users' and 'Show processes in all sessions' check boxes and I got two instances of my service, one greyed out (which was always visible) and another I could attach to. hth :).
I ran into the same issue with my windows service.
I could not attach to a running windows service that I built.
My solution has multiple projects with the windows service as the startup project.
I found out that my problem is caused by having the startup project is the same as the windows service.
To solve my problem, I just set a different project as the StartUp Project.
I'm not certain, but there may be a debugger already attached to the process, and that's why Visual Studio won't let you attach it. Are you certain that you're not running the application already in debug mode or do you have another VS instance running?
If you are trying to attach a web service or web app (w3wp.exe) then, try resetting the iis (iisreset). It worked for me.
I get the infamous "Dialogs must be user-initiated" Security Exception when I try to print some stuff in Silverlight. As you can see, the dialog is as user-initiated as can be:
John Papa couldn't help me much out neither, because I don't have any breakpoint set. Mr MSDN thinks it could also be that I'm just taking too long, but this is a demo application just as simple as can be.
Any ideas? I guess it's a Visual Studio quirk, maybe some extensions interfering, as things seems to work when I launch the application outside of it. I first thought maybe the Code Contracts are interfering with their IL weaving, but they are deactivated for this project.
Update: This is just a simple Silverlight application that runs locally from the file system. When I do "Start debugging", Visual Studio creates a hosting HTML file containing the Silverlight app in the Debug resp. Release folder of the project, launches the Internet Explorer with that HTML file and attaches the debugger to it.
Update 2: I also get the same error when I create a web project to host the Silverlight app and create a virtual directory for it on IIS.
I might also want to add that I don't have problems with printing in other Silverlight projects regardless of their hosting scenarios.
Update 3: I downloaded FireFox and it works, I don't get the error when I debug with it. So it seems to have to do with my IE8. I uploaded the solution:
http://dl.dropbox.com/u/10401470/Code/Demos/PrintingDemo.zip
I wonder if anyone can reproduce?
Anyone got an idea to which team I should file a bug report? Silverlight team? IE team? VS Debugger team?
I'm able to reproduce this. You have handled the Click twice, once in XAML another time in code. See your MainPage.xaml
<Button x:Name="PrintButton"
Content="Gotta print 'em!" Margin="8"
Click="PrintButton_Click" />
Don't feel bad about it. I did it last time through a misplaced Print inside a loop.
I've also experienced this strange behaviour. A standard button click event immediately invoking an OpenFileDialog. It would frequently generate the same error when being debugged but would eventually be coaxed in to working when the button is clicked several times.
However when built as a release (or perhaps simply by running the same Xap without a debugger attached to the browser) the problem would go away.
Try to remove
if(SightPaleceListBox.Items.Count > 0)
I had the same problem and found out that the reason was this following line:
cnvsMain.Children.Remove(PrintPagePlaceHolder);
cnvMain is on the page that the user pushed the Print button on (I was trying to remove it from that page in order to add it to the canvas that I was going to print).
My tip: try to comment rows one by one, until you find what row causes the problem. Than try to work around it.