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.)
Related
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.
As the questions says, I want to write code or debug an appication in real-time without setting breakpoints or pausing/restarting the application.
For example, when I write a game, I want to see what is happening when I change the code for the calculation of the light effects or the AI of the enemies immediately, while running the game on my second monitor.
Update:
Ok, it seems that you guys don't understand exactly what I want.
I want Visual Studio to be more like a WYSIWYG editor...make changes or add new code and see instantly what has changed in my application, without the application to pause it's work.
Update:
I saw this feature in this Video with Java in Eclipse (go to 14:30, where he changes the light effects of the game without stopping it.)
Sometimes. Check out the Edit and Continue feature: http://msdn.microsoft.com/en-us/library/bcew296c%28v=vs.80%29.aspx
Based on the comments, it sounds like you either want a dynamic language (a lot of games are scripted with LUA, or check our IronPython or IronRuby) or you want to dynamically load and reload assemblies, which would require something like MAF perhaps. With that, you could build the bits that you are changing as addins, and then unload and reload the addin assemblies when they change. That seems hacky though, and will likely perform poorly compared to a DLR language.
here is all you want to know abt the Edit and continue feature in Visual Studio:
http://msdn.microsoft.com/en-us/library/bcew296c(v=vs.80).aspx
You can edit the code while debugging, but no instruction will be executed during this time.
If you hit F10, the next instruction will be executed. If you hit F5 the normal execution will continue.
Why not create a resource file with the values to apply. Then have a command you can execute in the app that will reread the file. World of Warcraft has a feature like this. /reload ui
Yes, but unless Edit and Continue is enough for your need you need to design and implement the functionality yourself.
if the change is data driven - just reload the data when some file changes.
if change is in code - consider making that portion of the code to be in separate assembly and dynamically load and rewire the assemebly (may require strongly signed assembly to proper version code). Or dynamically compile code into new assembly (to avoid assembly conflicts in the same app domain).
In all cases you need to figure out how to deal with loosing part of previous state that could be in older objects.
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.
Edit-And-Continue is one of my favorite debugging tools which I have previously used on C# based Winforms and ASP.NET projects. However, I'm running a Silverlight 3.0 application on VS 2008 and whenever I try to make a change (after breaking) it says "Changes are not allowed when debugging Silverlight applications". Also there isn't an "Enable Edit and Continue" option in the project settings.
Does anyone (possibly an insider) know when this feature will be supported by Microsoft???
(I NEED IT!)
I doubt it will ever be a feature, to be honest. EAC has always required you to attach directly to your .exe in order to work. In the case of Silverlight, that .exe is the browser, which is not the .exe you are developing.
If you are looking to edit XAML while running, you might consider a dynamic loading situation where you can refresh the control at runtime. In that case, you can edit XAML while debugging, but I'm afraid you're stuck with the managed code.
EDIT:
One possibility that you might consider (but I haven't tried it) is to write your code against unit tests. Then, there is a tool called TestDriven.net that allows you to debug your tests with EAC (as an advanced feature). From there, you might be able to do some EAC, but you will be doing it via unit tests, not actually in the Silverlight environment.