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
Related
We have some library projects with a VPI extension. Defined in the DPR with library at start and {$E vpi} at end (Options > output settings > Application > Target file extension: vpi).
library appname;
uses
//...
{$E vpi}
Problem: When I run a debug in a VPI project it works only once. After any change it won't hit the break again. Now showing a "green" breakpoint when you run the app. The only way to get it back to work is by closing and open the IDE.
My Co-worker asked me if I have this problem last year, which I didn't. In his machine "when you change anything in your source, even a space in a comment, the break points won't work till you close and open the IDE again" he said.
We've compared lots of config from the IDE and we didn't find anything.
Now for some "no reason" my computer also stopped working with the debug.
I have looked into this topic "Delphi: why breakpoints from time to time are not usable (green highlighted line on IDE)?" with no luck.
I've tried the Clear unit Cache, un-check and check again the debug info, include TD32, include remote debug, uncheck optimization.
I've asked to other teams and they said that some machines works others don't. But they also don't know why.
Maybe someone here have another trick that may help.
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.
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 am working on an MVC project- for changing the default browser I added a web form and by right-clicking, I changed the default browser, but now when I tried to run the MVC app it showing an error pop up."You need to specify the full path to an executable file"
Can anyone help me to fix it?
Right click on Project file ( .csproj) and select Properties.
Go to the Web tab.
Choose specific page radio button ( its The start external program causing the problem).
I did the same default browser trick that you did and ended up with the same error every time I tried to run the app.
I tried:
Using 'Browse With...' and manually pointing to the exe of one of the browsers
No joy
running devenv /resetsettings
No joy
Installing WoVS Default Browser Switcher and switching between browsers
No Joy
In the project properties changing to 'Don't open a page. Wait for a request from an external application' then changing back to 'Specific Page'
No more error!
As far as I know the last step is all that was needed but just in case a previous step had a side effect I thought I'd list them all.
Hope that fixes your problem, it's a truly awful error.
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.