What is the best way to debug a namespace extension using Visual Studio? It's not convenient to use regsvr32 to register and unregister the extension and to restart the Explorer for each and every build. Attaching the debugger to the extension would be a nice benefit.
Is there a simple way to debug a namespace extension using Visual Studio?
If you start explorer with something like explorer.exe /separate,::{desktopguid}\::{yourguid} you should get a separate process for that window and it should pick up new registry entries (or existing entries if you just leave them in there, you could then add a GetWindowThreadProcessId(GetShellWindow(),...)!=GetCurrentProcessId() check and not load in the "main" shell process).
There are also some registry values you can set to change the behavior of explorer: DesktopProcess, SeparateProcess and BrowseNewProcess
To close down the shell without killing the process in taskmgr, use this old shutdown trick: Click Start, and then Shut Down. Hold down Ctrl+Alt+Shift and click Cancel
Related
Say I have one instance of Visual Studio running where I have opened few windows like Unit Test Explorer, Resharper TODO explorer and so on and to take advantage of multiple monitors I have moved these windows out of visual studio to different monitors.
Now if I open different solutions in new instances of Visual studio (say from Visual Studio > Recent items jump lists) all the new instances also open with similar windows in each instance, even though I don't really need those in those new instances. These clutter my work space and I have hunt and close these one by one.
This continues until I close all the news Visual studio instances, close all the windows on the first one instance I had and close that instance as well.
I understand this behavior stems from the fact that the new instances inherit the opened windows etc. configuration from the first opened instance.
Is there any way to prevent the same windows from opening on subsequent instances of visual studio?
Or may be a configuration to launch visual studio with default windows?
Or quick way to kill all these unwanted windows?
I looked through the VS > Options > Environment > Startup and Tabs and Windows etc., devenv.exe command lines but don't find anything useful.
While the solution provided by #Richard to establish your "baseline" window layout, then save that (Window | Save Window Layout) and apply the layout using Window | Apply Windows Layout | name or the assigned shortcut helped as a workaround, I see Microsoft Visual Studio 2019 now comes with a preview feature, Autohide tool windows at startup,
that addresses this problem.
When enabled, any new instances of Visual Studio open only Solution Explorer and not any other windows opened on previous instances. This also improves startup performance noticeably.
Visual Studio introduced a blocking Start Window instead of a non-blocking Start Page.
Considering how extensible Visual Studio is, is there a way to have VS2019 display a non-blocking Start Page.
The new Start Window is quite annoying, less informative, displays all projects, not just solutions, pinning is not up to previous standards, and no additional information. Most annoying is the blocking aspect.
I am thinking that there is some sort of extension or setting that Microsoft has somewhere, which can re-enable the Start Page and disable the Start Window.
Alternatively if it is not possible, is it possible to just disable the start window and have the main application appear, when the app starts or when a user closes a solution/project?
--
Another hope with this post is that Microsoft sees this request and maybe modifies their code and offers users an option at the start, much like color theme and default code set, as to whether they want app blocking or app non-blocking for the start area.
In Tools > Options > Environment > Startup > On startup, open: select "Empty environment".
Visual Studio will start without showing the modal Start Window.
Start Page on startup extension restores the traditional Start Page in VS 2019.
Start Page: Please give it back! and Make the Visual Studio 2019 start window non-modal are open issues concerning your other points.
I have a asp.net application. Some times I need to put many breakpoints. I know usage of F5, F10, F11 to navigate between line of code. If I want to bypass all the breakpoints for time being but want to keep all breakpoints alive for future, how can I do this?
Use Debug->Windows->Breakpoints window, you may disable (by using checkbox) or delete any/all breakpoints from there. You may also configure custom VS shortcut for this VS 2012 Add Shortcuts for "Disable all breakpoints" and "Enable all breakpoints"?.
Alternatively if you use local IIS you may run application without debugger attached, then if you want to start debugging use Debug->Attach to, select w3p.exe and start debugging (I use this setup often).
Can someone please explain to me what goes to the Output window in VS? Where do the messages there come from and do they have other use other than for debbuging?
Thanks.
The Output window is a set of text panes that you can write to and read from. Visual Studio defines these built-in panes: Build, through which projects communicate messages about builds, and General, through which Visual Studio communicates messages about the integrated development environment (IDE). Projects receive a reference to the Build pane automatically through the IVsBuildableProjectCfg interface methods, and Visual Studio offers direct access to the General pane through the SVsGeneralOutputWindowPane service. In addition to the built-in panes, you can create and manage your own custom panes.
Output Window (Visual Studio SDK)
This panel shows the actual info, that is spit from your application to the console (no matter debug or run mode). Also building, rebuilding and cleaning your project is described as operations there.
Check F1 for more info ;)
By default it either shows output from the build process, or debugger output. You can use OutputDebugString to display text in the output window while debugging.
There's not much else you can do with it without using an Add-In for Visual Studio.
I have a pre-alpha GUI program that I'm dogfooding and want to run under the debugger (for when things go wrong ;), but I don't want to have to launch a new copy of Visual Studio for each instance of the application. Can this be done?
I don't expect to actually be debugging more than one instance at a time, but I still want the debugger in the look for all of them. Also, I'm starting the application a few dozen time a day, so it would have to be easy to do.
You can start an instance of the same, or different projects multiple times in one instance of Visual Studio. Here is how: Right click on any project in Solution Explorer, go to the Debug context menu item, and click Start new instance.
You can view and manipulate all your running processes from the Processes window (menu Debug → Windows → Processes). The menu item (and the Processes window) is only available when the application is running (under Visual Studio).
This can be done.
If you have the Professional version of Visual Studio, you can use it to attach to each instance of the application that you have open.
First, compile the application with debug information so that it can actually be debugged.
Then launch your application. Open as many instances as you need.
In Visual Studio, click menu Debug → Attach to Process.... Select the process(es) you want to debug. You can select more than one from the list by Shift + clicking or Ctrl + clicking them.
I've just tested this to make sure. One instance of Visual Studio (at least Visual Studio 2008) can debug multiple instances of the same application.
If you don't have the Professional version I don't think this can be done. I'm absolutely sure the Express version can not attach to processes. I'm not sure about what "paid" editions can attach to processes though it is possible to do.