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.
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.)
I am designing a Windows Form app. I have an MDIParent form that loads in a maximized state, and loads its child forms in a maximized state as well. However, when I open an OpenFileDialog, or any datareader object, the MDIParent shrinks to a smaller size with all its forms and controls.
This solution Opening child form is causing mdiform to change size and shrink does not apply/work in my situation.
Also this solution https://support.microsoft.com/en-nz/help/967173/restoring-a-maximized-or-minimized-mdi-parent-form-causes-its-height-t did not work for me.
Some background: I have seen this behaviour in almost all my WinForm applications but I have never been keen to sort it out. I was able to narrow down to the causes as highlighted above when I started investigate it. Some posts are describing it as a windows bug, but it has existed for as long as the screen resolutions started going above 1024 (VS 2010) for my case. I hoped it is not just a windows bug...
I hoped it is not just a windows bug...
Feature, not a bug, but it is not one that Winforms programmers like very much. Notable is that there have been several questions about mystifying window shrinkage in the past few months. I think it is associated with the release of Win10 Fall Creators edition. It has deep changes to the legacy Win32 api layer and they've caused plenty of upheaval.
In your specific case, the "feature" is enabled by a shell extension. They get injected into your process when you use OpenFileDialog. The one that does this is very, very evil and does something that a shell extension must absolutely never do. It calls SetProcessDPIAware(). Notable is that it might have been written in WPF, it has a very sneaky backdoor to declare itself dpiAware. Just loading the PresentationCore assembly is enough. But not otherwise limited to WPF code, any code can do this and that might have been undetected for a long time.
One way to chase down this evil extension is by using SysInternals' AutoRuns utility. It lets you selectively disable extensions. But there is also a programmer's way, you can debug this in VS.
Use Project > Properties > Debug tab > tick the "Enable native code debugging" checkbox. Named slightly different in old VS versions btw. Then Debug > New Breakpoint > Function Breakpoint. Function name = user32!SetProcessDPIAware, Language = C. You can exercise this in a do-nothing WPF app to ensure that everything is set correctly. For completeness you can also add the breakpoint for SetProcessDPIAwareness, the new flavor.
Press F5 to start debugging and trigger the OpenFileDialog.ShowDialog() call. The breakpoint should now hit, use Debug > Windows > Call Stack to look at the stack trace. You typically will not see anything very recognizable in your case since the evil code lives in a DLL that you don't have a PDB for. But the DLL name and location (visible in Debug > Windows > Modules) ought to be helpful to identify the person you need to file a bug with. Uninstall it if you can live without it.
Last but not least, it is getting pretty important to start creating Winforms apps that are dpiAware so such a bug can never byte. You kick this off by declaring your app to be dpiAware so DPI virtualization is disabled. Plus whatever you need to do in your code to ensure the UI design scales properly.
Im using VS2012 to analyze a large project that I havent seen before. Im trying to figure out what happens when I click a button, but I dont know where the code for the event is. Is there any way I can get VS to tell me what code was recently run? Or perhaps a way to see what event handlers are associated with a UI element?
You can use the Runtime Flow extension (developed by me, 30-day trial) to list all methods executed after you click on a button.
It sounds like you're looking for a code profiling tool. Normally used to profile performance, it will definitely show you each and every routine hit in your codebase during a particular action.
Some of the more popular ones are dotTrace and RedGate's ants. I think the more expensive versions of Visual Studio.NET also have some profiling built in. Depending on if your code is all managed, and what the execution environment is like (Windows, web, etc.) your mileage may vary.
Edit: In my copy of VS.NET 2013 Pro, I just found the profiler under Analyze -> Profiler.
I understand that Windows Workflow foundation 4.5 supports side by side and dynamic update of Workflow definition. I found few samples on internet, but all describes Code based approach for updating the workflow. I wanted to make a utility which is used by developer to update the workflow without coding. (using only Xaml manipulation should be our ideal case)
My Utility does the following things,
I take Base Xaml (the workflow definition I wanted to update) File Name and Assembly (V1) from User.
I prepare it for update by calling prepareForUpdate API. and save it as a ForUpdate XAML.
I remove Base Xaml From visual Studio project.
I load that updated Xaml File in project (instead of base xaml) ,and modify the workflow.
After modification and rebuilding, I again open my update utility and take input from User the modified Xaml (v2) and Create update map.
After that I tried to update the running instance (using update map), At that time my utility show that they are updated successfully.
Although they are updated but at run time make undesirable effects (I got exception like {ICompiledExpressionRoot for compiled location 'a'}, where {'a'} is my variable) , related to Expression parsing, Root , etc.
Is anyone trying to achieve same thing or has some idea. my errors are consistent in both Visual Basic and Visual C# based XAML.
While we have not run into your specific scenario we have attempted to use Dynamic Update services to come to a solution much like you describe.
Despite having mostly declarative workflows designed entirely in the Visual Studio visual editor we abandoned this tool. In most cases this it was unable to generate an update map, sometimes even throwing parsing exceptions.
Using it really did not feel like it was a fully completed component and the lack of documentation around it, even after so much time has passed after its release, makes me very wary of considering it for anything.
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.