I have a solution with multiple start-up projects, and I am trying to relaunch one of them automatically on a nightly basis, while keeping the new process attached to the same debugger.
I was able to restart the process (using Process.Start) and attach the current debugger to it, but it has not been highly reliable so far, and by design, clicking on the Stop button only detaches from the process rather than terminating it.
I am aware the Visual Studio team has released a Visual Studio extension that allows automatically attaching child processes to the current debugger, which may work better than my code, but it would not be portable as it requires a local configuration.
The easiest way to achieve what I need seems to programmatically relaunch the project using the IDE itself, as I would do manually by right clicking on the project and selecting Debug > Start New Instance. I have access to the relevant DTE object in my code (when in development).
Hence, is there any way to make the following pseudo-code work, asking Visual Studio to start debugging a specific project/exe by passing it as a command argument?
DTE.ExecuteCommand("ClassViewContextMenus.ClassViewProject.Debug.Startnewinstance", "ProjectToBeRestarted");
DTE.ExecuteCommand("Debug.Start", "ProjectToBeRestarted");
DTE.ExecuteCommand("Debug.Start", "ProjectToBeRestarted.exe");
I would like to avoid as much as possible manipulating the UI (like storing the original start-up projects, setting an new one, and restoring the start-up projects).
The problem you are facing is there are very few Visual Studio commands that accept arguments as input. This makes sense considering commands typically use the current IDE context (e.g. selection, caret position, etc.) to infer what should actually be done. For instance, the ClassViewContextMenus.ClassViewProject.Debug.Startnewinstance command relies on the currently selected item in the Solution Explorer to know which project to start debugging, and it does not accept an argument.
For reference, you can find the full list of Visual Studio commands accepting arguments here: https://msdn.microsoft.com/en-us/library/c338aexd.aspx
To solve your issue, you will need to use the DTE object to set the current project selection first, and then execute the Startnewinstance command.
DTE.ToolWindows.SolutionExplorer.GetItem("SolutionNameHere\\ProjectNameHere").Select(vsUISelectionType.vsUISelectionTypeSelect)
DTE.ExecuteCommand("ClassViewContextMenus.ClassViewProject.Debug.Startnewinstance")
Note: Depending on your programming language, the double backslash escape may or may not be needed. The final string should only have a single backslash.
Related
I need to measure the time I spend in break mode debugging my Projects.
So I came up with the idea to write a custom VS extension which binds to the
OnEnterBreakMode & OnEnterRunMode debugging events.
This works just fine, but I need to make sure my extension is loaded right at the startup of VS.
Otherwise, the extension might not be loaded when I am already debugging.
Unfortunately Visual Studio 2019 heavily forces the user to use the AsyncPackage base class and
set the BackgroundLoadingFlag. On default VS deactivates extensions which use the deprecated API,
which allows synchronously loading extensions on startup.
Do you have any tips or workarounds on how I can make sure that my extension was loaded when I
start debugging?
So set your package to auto-load when the KnownUIContexts.DebuggingContext is activated, which means your package should be loaded once debugging has started -- there's no reason for you to load at startup if nobody every debugs anything in that session. Once your package loads, subscribe to those events, but also check the current state to see if you already entered break mode and missed the initial event. Rather than trying to "always load before the first event" it's often better to subscribe to events and just check the appropriate property to see if you are already in that state.
(And why do we not allow you to just load synchronously at startup? Because then everybody does that because it's easy, and your Visual Studio takes a real long time to load.)
whenever i use xaml editor designer mode, there will be an instance of XDesProc.exe at Windows Task Manager and it consume very high memory that eventually make the application hangs while i debug.
What I usually do is i will kill it at Task Manager and the program can continue running but designer view will be gone. This problem only exist at particular project but I've no idea where to trace the problem. Any wild guess?
These things to attempt or keep in mind.
Is the latest update for visual studio installed? Even if it is, one may want to run it again and try Repair.
Look at the controls on the screen in question. Can checks to determine if in design time such as DesignerProperties.GetIsInDesignMode(this) be used to circumvent code which shouldn't be run in design time? Check constructors for such places to put that check.
Remove the controls one by one until the designer behaves normally (or within a reasonable speed). That may give you a direction on the issue.
Does the same happen in Blend?
Run it in Visual Studio 2015/Blend 2015, do the same things happen? Note, if money is a factor usage of Visual Studio Community 2015 edition will work.
Visual Studio opens source code on top of the stack when I "break all" while debugging; I want to keep the cursor on the document I'm currently working on, without any other document or window (e.g.: no symbols loaded) being opened.
There is a way to stay on the current document, but that requires creating a Visual Studio add-in and a new UI command in the Debug toolbar. Credits for this answer should actually also go to openshac, who posted a similar SO question and also gave a workaround in his OP by using a macro.
The implementation is fairly simple (it took me a few minutes to have it working). First, in the add-in project, modify the Exec method in the Connect.cs file like this:
public void Exec(string commandName, vsCommandExecOption executeOption, ref object varIn, ref object varOut, ref bool handled)
{
handled = false;
if(executeOption == vsCommandExecOption.vsCommandExecOptionDoDefault)
{
if(commandName == "BreakInCurrentDocument.Connect.BreakInCurrentDocument")
{
// here's where the magic happens
// ******************************
var activeWindow = _applicationObject.ActiveWindow;
_applicationObject.Debugger.Break();
if (_applicationObject.ActiveWindow != activeWindow)
{
_applicationObject.ActiveWindow.Close(vsSaveChanges.vsSaveChangesNo);
}
// ******************************
handled = true;
return;
}
}
}
After creating and registering the add-in, just:
click TOOLS on the Visual Studio's menu
Customize
Commands
Choose the "Toolbar" radio button
Select "Debug"
Add Command...
From the "Addins" category, choose your custom add-in.
That's it.
Latest build of VSCommands extension (free version) available from http://visualstudiogallery.msdn.microsoft.com/a83505c6-77b3-44a6-b53b-73d77cba84c8 has just what you want.
It adds a Break In Current Document button to Debug Toolbar and Debug Menu:
http://vscommands.squaredinfinity.com/Media/VSCommands/BlogPost//blog/breakincurrentdocument.png
It's a feature.. when you do "break all" then it is assumed that your process has hung. The first thing you might be interested in such case is - WHERE. Hence, it's directing you right down to the 'current' place that is being executed. IIRC, this is defacto standard for all low-level debuggers. If you don't want the "no symbols loaded" just mark the 'show disasembly' and it will never pop up again:) (of course, instead, you will see the exact point of stop. And yes, this is also a feature that I myself used many times to debug unknown library code)
On the other hand, if you know where you want the code to stop, place the breakpoint there instead.
On yet another hand (as if we had three), if you want to actually stop the application - stop it, don't break, just stop.
I sense that your actual problem lies in the fact that you use one of the features in a wrong way, and therefore another feature bugs you. Please tell me, what do you use the "break all" for and how/why does it collide with your current text-editing. Why can't you stop or break-at-here instead? Or "detach"?
Anyways, I have to admit that as a feature, there should be some option for turning it off, just for the sake of configurability of the IDE.
EDIT
AAhh.. you're right. I've completely forgot about the glorious edit&continue. I'm not joking/teasing, E&C is a great feature that I wish all other platforms had. I've forgot about it, because... I extensively use lambdas, generics, foreachs and etc features that effectively block edit-and-continue.
Anyways, the point is, since that the edit-and-continue is the golden feature that you'd like to use - the application must be in 'break' mode. However, nevertheless how do 'break'/'pause' etc it, the IDE will assume it that the PAUSE was you goal, not editing, hence it will show you where did you pause the app.
There are a few options in MSVS like "show just my code" that may help you a little, but it will not solve the problem: edit-and-continue during debugging was designed for "small, local edits". Like, if(x>0)throw new uncaught() instead if(x<0)throw new uncaught(). Your app stopped on assertion or breakpoint and is about to crash, first-change exception handler fired off and here's your chance! You unwind the crash handler, correct the code, then run. Everything in the same one method which you had the stop occur in, as a way of just-in-time patches..
This is one of the main problems why can't you add methods, classes, modify generics, etc during E&C session: ie. editing your current lambda or current foreach might be OK, but the IDE would be not able to relocate the flows and execute the new code properly. This is a bit similar to why you sometimes see the "stale code" warning, but with those code constructs it is even harder to analyze, and therefore not implemented. And probably will never hit the top of MS's TO-DO list :/
The current boom in .Net/C# is not 'live development' but 'notaliveyet development' heavily supported by modularity and unit testing, where you put the effort to be able to test most of the features of the application off-line.. But that's a paradigm shift and for small projects or for local desktop development sometimes it is simply an overkill.
I am designing a basic app with multiple forms I seem to be coming across this problem and it will probably be something stupid.
When I make a change to my main form in design mode (like add a button), the button appears in design mode and I can code it but when I build the program it doesn't show up.
Any ideas?
Clean and Rebuild
Make sure you're you're starting a correct form in Application.Run in Program.cs
Most Important of all ..
Save your changes !
And make sure that the build compiles (it might not compile and not ask you if you want it to run the last successful build).
Check out what Microsoft themselves say:
http://vidmar.net/weblog/archive/2005/02/04/999.aspx
The problem was resolved. Just go to taskbar> build >clean rebuild.
Some questions:
If you change the code-behind, does the debugger stop on a breakpoint you put on that change? Also, declare a dummy variable and check if it is visible through the debugger windows such as "Locals", "Autos", "Watch" or "Immediate"?
Did you tamper with Form's default constructor (add parameters, change visibility, that sort of things)?
The form you are changing - are you positive that it is actually a main form (check the Program.Main)?
Does your form include user controls?
Did you try restarting the Visual Studio?
Did you try a full rebuild?
Did you try manually deleting all bin/obj folders then rebuilding?
Is your project actually selected for building under current configuration/platform (investigate the Build check-box under Configuration Manager)?
Did the project successfully build (check the error log)?
Are you running the same configuration/platform that you are building? Are you running the same project that you are building?
Ensure the right project is bold in the Solution Manager or check the start-up project in Solution Manager.
Do you happen to use "Start external program" under debugging options?
OK, this is not exactly an "answer", but answering these questions may produce some clues as to where is the actual problem...
When working with third party systems, especially very configurable systems that dynamically load providers, controllers, components and so on, I sometimes just want to know when a certain object or class is accessed. Normally, I'd place a breakpoint on any potential lines in my source (a nuisance, but it works), but if source is not available:
How can I instruct Visual Studio 2010 Ultimate to break on any and each access to a given class?
Note: as far as my experience goes, this is not generally possible, but I'd like to see it confirmed
Not the most elegant, but if you Ctrl+F public then you can spam between F9 [set breakpoint] then F3 [find next] to set a breakpoint on every public entry point into the class.
You might also want to add breakpoints for protected and internal entry points, and any explicit interface implementations (declarations that don't have public)
You can click Debug > New Breakpoint > Breakpoint at Function. Ctrl-B brings you there directly. It'll allow you to break at a specific function.
During debugging, you can see in the Breakpoints-window whether the method is found and will be hit (red round icon) or not (white with circle icon, as of disabled breakpoint), just as with normal breakpoints.
At one time (pre VS2008) you could set a breakpoint at every line in a file by select all (ctrl-a) followed by set breakpoint (F9).
To set just one on the entry to every method takes, if I recall correctly, a macro. Check out John Robbins' blog as a possible source: http://www.wintellect.com/CS/blogs/jrobbins/
[EDIT: ctrl-A, F9 doesn't work in 2010 or 2008, so it must be an earlier version I remember this from]
I just made a Visual Studio 2010 addin for this. Check this: http://weblogs.asp.net/uruit/archive/2011/08/04/visual-studio-2010-addin-setting-a-class-breakpoint.aspx
Update
This project now lives on Github. Feel free to contribute.