Is there the possibility to run some code when the Code is stopped when running it from Visual Studio?
I am using the CefGlue library to build a WinForms application and realized that there are issues when pressing the stop button ranging from Exception to two windows with no content opening. A separate process continues to run in the background. In order to stop Cef nicely I need to exectue CefRuntime.Shutdown(); Maybe this is because it does not run the application in a Visual Studio hosting process, because CefGlue has problem with this (see this). This does not affect production but is nasty while developing and testing, but nevertheless I would like to execute some code to fix the problem.
I would guess this is not possible but if it was it would be interesting to know.
So I am looking for a way to execute some code when Visual Studio is stopping the application when pressing the stop button while in development.
Note: I am using Visual Studio 2013 and 2015.
Edit
The issue is not reproducibly with very few lines of code. Nevertheless I have tried to create a simplified example here
What you're basicly looking for is a solution using the Visual Studio SDK.
You can build your own add-ins by implementing the IDTExtensibility interface.
In the OnConnection function you can subscribe to different events. Using (DTE2)application you can access a lot of things from VS.
You'll have to subscribe to some of the events that can be obtained from the Events property.
You'll have to find out yourself what events work best for your solution. But the DebuggerEvents would seem like a good place to start.
This does require some research before you can use it. There are likely to be easier solutions.
As a simple example for the OnConnection:
public void OnConnection(object application, ext_ConnectMode connectMode, object addInInst, ref Array custom)
{
var applicationObject = (DTE2)application;
var events = _applicationObject.Events;
var buildEvents = (BuildEvents)events.BuildEvents;
buildEvents.OnBuildBegin += new _dispBuildEvents_OnBuildBeginEventHandler(OnBuildBegin);
}
This triggers when a build is started. The available documentation isn't great, so it will need some trial-and-error before you find what you need.
Related
I am working on a small engine which can be run as standalone or within a winform application.
So far I got both working, the only issue I have is that during debugging in visual studio, the winform application's gamescreen updates slowly, which results in the player lagging.
But if I open the created .exe without the debugger, it runs smoothly.
So that I can easily edit the winform, see my changes and play the game without lag I am asking you guys if you could help me.
You can see my code here:
https://github.com/insanepure/SweetEngine/
Sweet.Editor is the C# Winform, which depends on the Sweet.Wrapper, which is the managed C++ application. This depends on Sweet.Game (for game specific components, also that can be run as standalone) and Sweet.Engine (which depends on Sweet Core etc but I abstracted that so that you only need to include Sweet.Engine within Sweet.Game)
So the tool works is that it get's the HWND of a specific Panel and then creates the engine with that HWND, instead of creating a new one. That is the only difference between standalone and tool.
The problem may be because I am running my own loop within SweetEngine. I tried to change this so that the winform calls Update and Render, but this somehow was slower than doing it in a seperate loop.
Also I am not sure why this is faster than making the application call Update and Render.
Another problem I encountered is that I can't debug my native c++ code, so I can not step inside of it. Can this be fixed somehow?
Switched to WPF and using a class that inherits from usercontrol, that way I can draw when OnPaint() is called, also I am using a timer to call OnPaint 60 times a second. Now it's working better.
I'm having a really strange problem that I just can't figure out. Things I compile in Visual Studio 2015 (C# projects in WinForms and WPF) will not launch outside of Visual Studio. This includes a project that is completely new and untouched. As in, create a new WPF Application, build in debug and release. Go to containing folders click on EXEs and...nothing.
When I run them I get 3 processes appearing in Task Manager (named the same as my application) than cannot be killed (through task manager or command prompt) and nothing else occurs. Nothing in event viewer that seems to correspond to the app. I've attached an instance of VS 2015 to the process and I get the following message: WpfApplication.exe has triggered a break point. Pressing Break takes me to a screen that tells me no debug information is available and pressing continue has no visible effects (I can occasionally see slight movement in the cpu % but not a lot else). Any attempt to stop debugging will cause visual studio to hang and when I end its process VS closes but its memory is not freed up according to Task Manager. All of these same things occur when building in VS2013 and attempting to run outside of VS. Everything runs just fine when run in debug mode inside Visual Studio but outside of it...not a chance.
I literally have no idea where to proceed from here. I can find no error messages or clues to point me in a direction to look. Is there something I'm missing/doing wrong? What steps can I take from here to find the source of the problem?
I've considered it may be something wrong with my computer but I want to explore the possibilities before I do something drastic like a clean install. If the prevailing opinion lies that way then I'll seek help elsewhere!
tl;dr: launching the exe of a compiled application results in no running application and no obvious error messages, how can I proceed from here?
I'm going to post an answer to this because I found out what was wrong but it probably isn't useful to have it hanging around so I'll just delete the question at some point soon.
The main lesson to remember is that the main purpose of anti virus software is to frustrate you as much as possible and if something weird is happening try turning it off briefly and see what happens. You'll probably find that things are now working correctly.
EDIT: I should restate this in a more serious fashion.
Anti virus can sometimes affect things in unexpected ways and turning it off temporarily can save you a lot of time. Keep it up to date too, mine was a version or so old and was not functioning correctly. I updated it and the deep scan now functions as expected rather than silently failing.
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.
Is there a possibility to start/stop the visual studio (Professional 2012+) profiler from code? I know you can start it paused, but to start the profiling, you have to click on a button in the visual studio.
In my case, I would like to start it when clicking on a button in my application, which switches to a new view, and automatically stop it when the UI was loaded. I would like to see why there is such a large delay until the UI shows up.
I've not used it before, but it seems you're looking for Profiling API.
DataCollection.StartProfile and DataCollection.StopProfile looks like the methods you're interested in.
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.