I read the related post from Nathan here but is still unable to improve the performance of the Add-in. The load function is pretty empty and running a step by steps using breakpoints gives me 178 ms and the addin report 1780 ms to load which is above the perf threshold. I am using VS2017 and .Net 4.5. Any idea on where I should look for thoss 1602ms?
I need to load the addin during the start of Outlook.
Ok I did not find the answer but resolved the problem by placing all startup instructions in a thread:
new Thread(() =>
{
// My startup code
}).Start();
The downside is that you need to manage user actions while the add-in is not fully loaded.
Related
I've recently picked back up a year old MVC5/WebAPI2 (and SignalR) application which ran just fine under VS2013.
In VS2015 I however keep struggling with what appears to be hanging debug sessions: When starting a debug session VS2015 hangs on "Build succeeded" with no output in the console. The solution is to terminate the IIS Worker Process (which appear locked at 20-30% CPU Usage) via the Task Manager. Upon doing that VS throws a general error message and stops. When retrying once again it works normally until next stop-then-start.
It makes no difference if I stop (Shift+F5) the debug session or restart (Ctrl+Shift+F5) it, either appears to lock up the IIS process. What however does work is going to Debug -> Terminate All, then the debug session starts without hick-up.
I have tried disabling pretty much all debug tools (including Edit-and-Contiune), but nothing has worked so far. I should also mention that running the application on IIS Express does not work at all: It hangs during startup no matter what.
Update: Attaching the error message that pops up if I let the debug startup process time out. I have of course tried all the suggested solutions which the "help" button takes me to.
Update II: It looks like the problem might be related to SignalR. I've been working without problem for the last hour or so, but now stepped into the part of the application which uses SignalR. After stopping and changing some code, the debug session would not start again.
Ensure that you turn on ‘Internet Information Services Hostable Web
Core’ along with all the other .NET / IIS feautes
Try to Change the IIS Settings Shown in this Article
I have the exact same problem, and the solution was to install signalR performance counters.
SignalR performance counters
Similar question with solution: SignalR makes IIS hang after rebuild
I am having serious trouble getting the JIT debugger event trigger when using the Stop statement on my scripts.
Me an 2 other coworkers have been doing research on the issue and none of us can figure out what is the problem. We have uninstalled and reinstalled Microsoft script editor, and we have updated the registry values, we have added ourselves to the debugger users group. We have admin rights etc.
Not using this debugger is not an option, is a project requirement but we cant get it to work on 2 of our machines. However, the team leads machine does work. but we have 2 machines that the debug event does not trigger. When comparing settings everything seems to be in order.
We have followed the instructions on MSDN and various other found around the web.
Is MDM.exe running in Task Manager? (it's a service, Machine Debug Manager).
cscript //x nameofscript.vbs work?
stumbled on this post one year after... hope in the meantime you found a solution.
I have too the problem when I need to JIT-Debug my VBS Scripts; I 've realized that the debugger won't fire up upon Stop statement but only in case an Exception is thrown; After you are in debug mode, then, Stop statements should work again, but you need to generate an exception in order to invoke the debugger.
When I need to break a VBScript, I usually put a call to a non-existing function in order to intentionally cause an ecxeption: this will trigger the debugger and I'm able to work with it.
Sample code:
(do something)
DEBUG_INVOKE ' Function DEBUG_INVOKE does not exist => Exception.
' you can actually type whatever you want, eg. 'stp', 'stopp', 'xxx', etc.
' provided, of course, it's NOT the name of a Sub or Function present in
' your script.
(do other stuff)
After you enter debug mode, then, you may not be able to move from break position: it depends on the debugger: I know, i.e. that MS Script Debugger and Visual Studio 2015 Community Ed. do like this, while MS Script Editor and Visual Studio 2010 Professional allow you to move the pointer and do step-by-step debugging. Still investigating on this!
HTH,
Max - Italy
I am having an outlook addin which is fairly stable and has been used for years. On a citrix machine environment, the addin is causing outlook to hang if it is left open. Logs are not helping much. How can I approach the problem if I can do the native debugging?
Outlook can hang for many reasons. Since Outlook is COM-based, it uses STA which will cause the main UI thread to hang while it waits for a long-running operation to complete (network call, disk read/write, etc.).
You will need to review the source code to review what behaviors the component is performing when it hangs. Inserting trace statements (Trace.TraceInformation) may also help if you can repeat the hangup. Start with the event ThisAddIn.ThisAddIn_Startup to see the entry point to the AddIn. DebugView is a great utility to view the Trace output of your plugin while it's running.
If COM resources are not being cleanup up properly (Marshal.ReleaseComObject) - over time the memory consumption will grow which will start making the application sluggish - although it shouldn't cause it to freeze/hang.
Your best bet is understanding the behavior of the plugin to see what triggers the hang.
I noticed that at installation time of a VS package product (like http://www.continuoustests.com/ ) devenv.exe is started
and I notice that sometime my VS addin is loaded (its OnConnection() method is called), and this could provoke a crash.
The problem is about sometime, since I cannot repro the conditions where my VS addin gets loaded.
From my crash log, I know it happens rarely, only with VS2010 devenv.exe, and I know as well it is independent from the machine architecture x86 / x64.
I tried installing/deinstalling extra addins having no VS instance running, or having VS instances running, VS2008 or VS2010.
Does anyone have a clue about how to reproduce the problem when my VS addin gets loaded?
Btw, I am pretty sure to have a fix for the problem, since in OnConnection() I already have code like that...
switch (connectMode) {
case ext_ConnectMode.ext_cm_External: // This setting is no longer used by Visual Studio. (http://msdn.microsoft.com/en-us/library/extensibility.ext_connectmode%28v=vs.80%29.aspx)
case ext_ConnectMode.ext_cm_CommandLine:// The add-in was loaded from the command line, don't support it so far
case ext_ConnectMode.ext_cm_UISetup: // addin loaded for the first time, we don't need it (http://msmvps.com/blogs/carlosq/archive/2008/10/13/the-onconnection-method-and-ext-connectmode-ext-cm-uisetup-of-visual-studio-add-ins.aspx)
return;
case ext_ConnectMode.ext_cm_AfterStartup:
case ext_ConnectMode.ext_cm_Startup:
case ext_ConnectMode.ext_cm_Solution:
break;
}
... but once OnStartupComplete() is called back, I forgot to check the connectMode value I got in OnConnection(), hence the crash.
Anyway being able to reproduce the bug would comfort me in the fix.
Update: 10 October 2011
After more testing and feedback from users that repro the problem, it appears that my theory was wrong: connectMode is actually in the range [ext_cm_AfterStartup, ext_cm_Startup, ext_cm_Solution].
The problem only occurs with VS2010 and comes from the fact the addin has no UI element, provoking something like dte.MainWindow, or HwndSource.FromHwnd(new IntPtr(mainWindow.HWnd)).RootVisual to be null.
I talked with Carlos Quintero http://msmvps.com/blogs/carlosq/, the world expert in VS addin, that has never observed this case. VS2010 shouldn't load any addin in the VS extension install/uninstall scenario, and it seems to occur randomly, or more likely, under unknown and rare conditions.
I'll put yet another try/catch to circumvent yet another VS2010 addin bug :(
I am trying to fix a bug on an ActiveX control. Is it possible to debug it from within Visual Studio 2008?
If attaching to the process is a problem, just throw a DebugBreak() into the code you wish to debug. If VS is your JIT debugger, once the debug break command is reached you'll be asked whether you'd like to debug the process. Just say yes, and you're in.
You should attach the debugger to the process which loaded the ActiveX component. If the latter has debug information you will be able to debug it as if it was a usual application.
If the host application refuses to load it and you suspect that some code responsible for the ActiveX initialization is broken you can attach to the process in advance and them do the action that will make the host application load the ActiveX.
ActiveX is not a stand alone application.
Usually, it is used within a container application.
I suggest using the Message Boxes and alerts.
Hope this will help.