I am running into problems with an Outlook Add In I created. Somehow Outlook doesn't shut down properly. I've seen all the postings about using ReleaseComObject and such.
==== UPDATE ====
I tried the whole thing again, creating a new empty project in a new solution and now, after some time after shutting down Outlook the following Error message is presented to me in Visual Studio. Somehow I think I must have disabled getting that exception in the previous solutions. I don't know what it means (yet) but I will go for a hunt. Maybe this will shine some light on the issue? The effect is still the same: Outlook doesn't shut down.
ContextSwitchDeadlock was detected
Message: The CLR has been unable to transition from COM context 0x55cdd8 to COM context 0x55cf48 for 60 seconds. The thread that owns the destination context/apartment is most likely either doing a non pumping wait or processing a very long running operation without pumping Windows messages. This situation generally has a negative performance impact and may even lead to the application becoming non responsive or memory usage accumulating continually over time. To avoid this problem, all single threaded apartment (STA) threads should use pumping wait primitives (such as CoWaitForMultipleHandles) and routinely pump messages during long running operations.
Also when I try to remove the add in when not in safe mode (e.g. it has been loaded) Oulook locks up when hitting the remove button in the safe center). Guess that's the same cause though.
===== END OF UPDATE ====
To debug what's going on I did the simplest thing imaginable:
1) Using Visual Studio 2008 I created a new Outlook 2007 Add In Project
2) I started the debugger with the new add in.
3) After some time I close down Outlook, expecting it to properly close down.
It doesn't. The code does reach the generated ThisAddIn_Shutdown method. But, Outlook doesn't shut down.
To make sure I'm not completely insane, I downloaded, compiled and tried the extensive example found at http://code.msdn.microsoft.com/ContosoAutoOBA. Using this add in has the same effect: Outlook doesn't close down.
I tried this with no other add ins available: that doesn't make a difference.
Just for the record, below you find the generated code.
I'm using Windows 7, Visual Studio 2008, Office 2007, all updates are installed.
Is there someone that can shine a light on this. You help is greatly appreciated.
Thanks,
Bart
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Xml.Linq;
using Outlook = Microsoft.Office.Interop.Outlook;
using Office = Microsoft.Office.Core;
namespace OutlookAddIn3
{
public partial class ThisAddIn
{
private void ThisAddIn_Startup(object sender, System.EventArgs e)
{
}
private void ThisAddIn_Shutdown(object sender, System.EventArgs e)
{
}
#region VSTO generated code
/// <summary>
/// Required method for Designer support - do not modify
/// the contents of this method with the code editor.
/// </summary>
private void InternalStartup()
{
this.Startup += new System.EventHandler(ThisAddIn_Startup);
this.Shutdown += new System.EventHandler(ThisAddIn_Shutdown);
}
#endregion
}
}
It appears that the Microsoft CRM Add In is the problem. I disabled it earlier (in fact disabled all Outlook plug ins), but apparently that isn't enough. Actually removing it from my computer solved the problem.
There seems to be a update 7 roll up for the Microsoft CRM plugin, but it refuses to install on my machine. Alas, at least I can continue with my own Outlook plug in. I will keep a post it on my screen from now own as my new CRM system.
Ah the days of VSTO development!
From memory - to fix this:
Close all instances of Outlook running (Task Manager, End Process)
Start the application by using the debug button in VS.NET
From memory; it plays up a bit when there was already an instance running.
First up.
What version of the office service pack are you running. There are loads of fixes in SP2 to help shutdown.
Are you saying that if you dont have the addin installed outlook shuts down ok ?
As I wonder if you have any other installed inder trust center. ?
Related
I'm facing the Developer Tools problem since yesterday. I use
Unity (several different versions, e.g. 2018.4.23),
Jetbrains Rider (updated today to 2020.1.3, yesterday 2020.1.2)
macOS Catalina 10.15.5
I was refactoring some stuff and Developer Tools asked me for the access: Developer Tools Access needs to take control of another process for debugging to continue. Enter your password to allow this...
Since then, two things are happening.
If Developer Tools Access is enabled (also tried doing this through sudo /usr/sbin/DevToolsSecurity --enable command) nearly every time when I'm changing something in code, Unity stops working (loading wheel present) and I can't turn its application off. I tried using Activity Monitor, it doesn't show any activities. I can only see the loading wheel.
I even tried killing the Unity process through kill unitypid, it "kills" the process since it's not present on the processes list, but I still can see it on my desktop, being just as down as before.
Checking Unity logs, I can see it stops on:
Begin MonoManager ReloadAssembly
custom-attrs.c:1250: (null)
assembly:/Applications/Unity/Hub/Editor/2018.4.17f1/Unity.app/Contents/Managed/UnityEngine/UnityEngine.CoreModule.dll type:UnityException member:(null) signature:<none>
Stacktrace:
Native stacktrace:
0 libmonobdwgc-2.0.dylib 0x00000001460b4976 mono_handle_native_crash + 242
If Developer Tools Access is disabled, the application asks me a few times to enable it. After pressing Cancel a few times, Unity crashes and turns off and gives me the ability to send log error to Apple with the exception:
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Application Specific Information:
abort() called
Don't really know what to do. I tried updating Rider, Catalina, installing a new Unity version.
Update: I formatted the disk and installed Catalina again, it still doesn't work.
Your help would be much appreciated!
After further investigation, I've discovered the following repro:
Create a custom attribute that derives from the PropertyAttribute that calls AssetDatabase.FindAssets("somethingsomething") in it's constructor.
Create a class (in my case it derives from the MonoBehaviour class in order to be able to call the constructor because of the gameObject placed on the scene) that contains a field that has a custom attribute mentioned above.
Add FormerlySerializedAs attribute to this field (e.g. during refactoring).
Create a gameObject with your class attached.
This will result in a pop-up window with a message that I've mentioned in my question:
Developer Tools Access needs to take control of another process for debugging to continue. Enter your password to allow this...
Example:
using System.Diagnostics;
using UnityEditor;
using UnityEngine;
public class CustomObjectPathAttribute : PropertyAttribute
{
/// <summary>
/// Default constructor.
/// </summary>
public CustomObjectPathAttribute()
{
var guids = AssetDatabase.FindAssets("Resources");
}
}
using UnityEngine.Serialization;
[System.Serializable]
public class TestClass
{
/// <summary>
/// Path to the file.
/// </summary>
[FormerlySerializedAs("pathToFile")]
[CustomObjectPath]
public string pathToFile2 = string.Empty;
}
using System.Collections.Generic;
using UnityEngine;
public class MyBehaviour : MonoBehaviour
{
private List<TestClass> testClasses;
void Start()
{
testClasses = new List<TestClass>();
}
}
Attach the MyBehaviour script to the gameObject placed on the scene. The issue will occur after project recompilation.
Using AssetDatabase.FindAssets("Resources") in the custom attribute's constructor works fine if there's no FormerlySerializedAs attribute attached to the field in the TestClass.
I've reported the bug to the Unity QA Team and they successfully reproduced the issue. Here's the link to the Unity Issue Tracker: https://issuetracker.unity3d.com/issues/crash-when-using-assetdatabase-dot-findassets-in-a-custom-propertyattribute-and-when-formerlyserializedas-attribute-is-also-used
There's nothing more I can do at this point except of
not refactoring my fields when they have custom property attributes
attached,
not using AssetDatabase.FindAssets in my property
constructor.
This is happening to me in 2019.3.x
It generally happens when I'm testing animations and making changes while in play mode.
Nothing short of a reboot will fix the issue.
I've dropped the VB6 MSCOMM32.OCX (Microsoft Comm Control 6.0 (SP6)) on to a VBA form. I had to apply a Microsoft Security Update KB926857 to VB6 to get the control to drop on the form because a Windows Update set a kill bit on the older version.
When I look at the object's events in VBA I do not have "OnComm" available. I can get it in VB6 by double clicking its icon (a phone) but not in VBA. Importing it in Delphi shows OnComm as the only event handler.
I know the control is registered properly and licensed.
I've done it a couple of years ago with the older control, but has anybody done this lately?
Available Events: OnEnter, OnExit, OnGetFocus, OnLostFocus & OnUpdated
I discovered independently that HK1's suggestion was correct. I created an event handler that looked like this
Private Sub MSComm1_OnComm()
Nothing needed to be done to the object properties to link it to the routine.
In the form load event I placed an MSCOMM1.PortOpen = True. I scanned a bar code and presto it worked.
Why this is treaded differently than other events I do not know and how/where it is documented is a mystery.
This Microsoft site has helpful information on handling the data properly and is what I used for the test.
http://support.microsoft.com/kb/194922
This is driving us crazy... In VS2010, MVC2 projects, not all projects.... both on a project that was upgraded from 2008/mvc1 and on a brand new project created within 2010/MVC2, we have the following behavior:
1) develop as normal..
2) hit F5 or CTRL-F5 to open up a browser
3) works great!
4) add a CSS file (or JS file or any file, or remove any file) in the project
5) immediately the dialog pops up "WebDev.WebServer20.exe has stopped working"
You have to close the program, and "F5" again - and all is right with the world...
Say we then modify an existing css file. No problem. But adding or removing one, immediate crash.
It seems like the development webserver is "locked on" to the project file and when it detects a change, it dies.
The Event Viewer is pretty unhelpful. The following is logged:
Faulting application WebDev.WebServer20.exe, version 10.0.30319.1, time stamp 0x4ba204ca, faulting module KERNEL32.dll, version 6.0.6001.18215, time stamp 0x49953395, exception code 0xe053534f, fault offset 0x000442eb, process id 0x%9, application start time 0x%10.
This is happening on all of our developer workstations, which include some with Windows Sever 2008, some with Windows XP, and some with Windows 7. All are running VS2010 Premium with ReSharper.
Also, the same thing happens on projects which target the 4.0 framework, only the error message referrs to WebDev.WebServer40.exe instead.
Google has revealed nothing. We've already tried "setting a static port" instead of a dynamic port - no help.
Please help if you can.
So, as it turns out, the problem was due to a certain use of MVCTurbine and StructureMap, but it seems likely that the problem would also occur with other IOC Containers, not just StructureMap.
The author of MVCTurbine has expressed that the fix will be in version 2.2 of that product.
In the meantime, one extra line of code in your Global.asax will solve this problem:
//VNEXT: after Turbine 2.2 we wont need this line anymore...
protected override void ShutdownContext() { CurrentContext = null; ServiceLocator = null; }
This article shows the particular use case we were addressing. The "normal plain vanilla" use of MVCTurbine and StructureMap would not have this problem.
Obviously, great thanks to Javier for being so responsive to help requests!
since moving to Windows 7 (IIS 7.5), the debug assertions do not prompt a pop up dialog anymore.
I have tested this in a separate project, and noticed that they do work when using the integrated Visual Studio Developer server (Cassini) but they do not work when using IIS Web Server.
This is a big issue for us since we are counting on debug assertions to identify potential programming errors, so any help would be appreciated.
Thanks. Eyal.
That's because failed debug assertions are displayed in the Output window now instead, under the Debug section.
To view the Output window in Visual Studio 2008 go to the 'View' menu and click 'Output'.
I also find it inconvenient. Some more info...
You can work around by using
System.Diagnostics.Debugger.Launch();
You can make for example this function
[Conditional("DEBUG")]
public static void AssertEx(bool condition, string message)
{
if (condition) return;
System.Diagnostics.Debugger.Launch();
// Still write the message on output
Debug.Fail(message);
}
and get similar results.
That is the default behavior now and it cannot be changed.
What you can is generate a file with the assertions that failed in your app. That will still help you track your issues without halting the app when running inside the IIS.
Take a look at this good article about it.
Simple question - I found two ways to add a tool window to Visual Studio (2008): create an addin or create a package.
(Addin: http://www.codeproject.com/KB/dotnet/vstoolwindow.aspx)
(Package: http://msdn.microsoft.com/en-us/library/bb165051.aspx)
What's the "right" way?
You can do either, and I've done both. In some ways, addins are a bit easier, but they suffer from some annoying drawbacks.
Add-in:
+No requirement to install the Visual Studio SDK
+No requirement to use a Package Load Key (PLK) or sign your distributed binaries
+Easier development process when you use the Extensibility API (simplified code in many ways)
+Easier installation process (no wacky registry stuff)
-Doesn't seem to behave as well as VSPackage-based tool panes
-I've run into performance issues which prompted me to use the VS SDK COM interfaces instead of the Extensibility ones, leading to a significant performance bump. In other words, my "add-in" is now based on the VS SDK and is only really an add-in because it loads via an XML file instead of the registry. (Also, from everything I can tell, the Extensibility interfaces are just a large utility wrapper around the SDK.)
VSPackages:
+You can harness the full power of the VS SDK, both its feature set and (potentially, when carefully used) performance advantage
+Seems to behave more reliably than add-ins
-Requires signed binaries, a PLK, and a complicated installation procedure
-Steep learning curve, and many seemingly simple actions are nasty/convoluted. I now have an assembly providing extension methods to perform "obvious (to me)" actions on the COM interfaces. Between that and experience things have improved over time. There are similar options available to the community, which you should seriously consider if you go this route.
I think 280Z28 was perfectly correct prior VS2010. But now VS2010 and VS012:
Do not require officially signed packages (may only those that go to the Gallery have to);
Thanks to VSIX it can very easily install VSPackages that can also be deployed to the Gallery.
Moreover VS2010 supports another kind of extensibility: those are MEF extensions, that are lightweight plugins that trigger only at specific events of the IDE, like text editor events. An example is FixMixedTabs extension.
Just a create a VSPackage empty package (no menus, commands, ...) and copy this in the main class to create a VSPackage that basically loads when there's an active solution and just get a reference to the DTE2. In this way you can just use it as an Add-in.
// This attribute tells the PkgDef creation utility (CreatePkgDef.exe) that this class is
// a package.
[PackageRegistration(UseManagedResourcesOnly = true)]
// This attribute is used to register the informations needed to show the this package
// in the Help/About dialog of Visual Studio.
[InstalledProductRegistration("#110", "#112", "1.0", IconResourceID = 400)]
[Guid(GuidList.guidVSPackage1PkgString)]
// Load this package when a solution is loaded (VSConstants.UICONTEXT_SolutionExists)
[ProvideAutoLoad("{f1536ef8-92ec-443c-9ed7-fdadf150da82}")]
public sealed class VSPackage1Package : Package
{
/// <summary>
/// Default constructor of the package.
/// Inside this method you can place any initialization code that does not require
/// any Visual Studio service because at this point the package object is created but
/// not sited yet inside Visual Studio environment. The place to do all the other
/// initialization is the Initialize method.
/// </summary>
public VSPackage1Package()
{
Trace.WriteLine(string.Format(CultureInfo.CurrentCulture, "Entering constructor for: {0}", this.ToString()));
}
/// <summary>
/// Initialization of the package; this method is called right after the package is sited, so this is the place
/// where you can put all the initilaization code that rely on services provided by VisualStudio.
/// </summary>
protected override void Initialize()
{
Trace.WriteLine (string.Format(CultureInfo.CurrentCulture, "Entering Initialize() of: {0}", this.ToString()));
base.Initialize();
IVsExtensibility extensibility =
GetService(typeof(EnvDTE.IVsExtensibility)) as
IVsExtensibility;
DTE2 dte = extensibility.GetGlobalsObject(null).DTE as DTE2;
}
}
If you are just creating a simple tool window then I suggest going the Add-in route.
Both Packages and Add-Ins are ways of extending Visual Studio. Generally speaking they have the same functionality. Packages are a bit more powerful and allow deeper integration into Visual Studio. But that deeper integration comes with a cost including bigger ramp up times and installation procedures.
Add-ins are designed to be a more light weight extension mechanism. Smaller ramp up time and easier installation.
If all you are doing is tool window with basic interaction of the editor our code model then add-in is the best route.