A bit of a strange one.
I'm learning how to create VSTO add ins for Outlook and I've barely done much and what I seem to have already done, causes Outlook to disable it as it takes too long to load. (Says it takes 1.57 seconds)
All I've literally done is:
Created a new Project for Outlook 2013 and 2016 VSTO
Added the ribbon add in by going to Project -> Add New Item
Set the Ribbon type to Microsoft.Outlook.Explorer
Added a button
Press F5 to test
I'm more concerned that if I was to develop, will this VSTO take longer to generate?
When you hit the F5 button on the keyboard the add-in is run under the debugger with non-optimized code. I'd suggest testing the RELEASE configuration of your add-in instead. In that case you will get an optimized assembly without debug symbols defined, so it should be run a lot faster.
The New in Outlook for developers page states the following:
Extending the add-in resiliency pillar of Outlook 2010, Outlook 2013 monitors add-in performance metrics such as add-in startup, shutdown, folder switch, item open, and invoke frequency. Outlook records the elapsed time in milliseconds for each performance monitoring metric.
For example, the startup metric measures the time required by each connected add-in during Outlook startup. Outlook then computes the median startup time over 5 successive iterations. If the median startup time exceeds 1000 milliseconds (1 second), then Outlook disables the add-in and displays a notification to the user that an add-in has been disabled. The user has the option of always enabling the add-in, in which case Outlook will not disable the add-in even if the add-in exceeds the 1000 millisecond performance threshold
Related
I have created a Outlook 2010/2016 addin (VSTO?) with VS2015. I deploy this addin using click-once.
The update settings in the addin are set to every time the customization (addin) runs.
I can install the addin with one click (so far so good) and it remains working if a stop and start Outlook. No issues.....
But when I make a change to my AddIn, publish it and restart Outlook again. The addin is not loaded anymore. It is just not enabled in Outlook. Even enabling it again will not work. I need to uninstall and reinstall the addin to get the newest version available.
I cannot figure out why it is not working as there are no error messages.
Any clue anyone?
Microsoft Office applications can disable VSTO Add-ins that behave unexpectedly. If an application does not load your VSTO Add-in, the application might have hard disabled or soft disabled your VSTO Add-in.
Hard disabling can occur when a VSTO Add-in causes the application to close unexpectedly. It might also occur on your development computer if you stop the debugger while the Startup event handler in your VSTO Add-in is executing.
Soft disabling can occur when a VSTO Add-in produces an error that does not cause the application to unexpectedly close. For example, an application might soft disable a VSTO Add-in if it throws an unhandled exception while the Startup event handler is executing.
When you re-enable a soft-disabled VSTO Add-in, the application immediately attempts to load the VSTO Add-in. If the problem that initially caused the application to soft disable the VSTO Add-in has not been fixed, the application will soft disable the VSTO Add-in again. Read more about that in the How to: Re-enable a VSTO Add-in that has been disabled article.
we configured outlook 2016 with Dynamics 365 with help of Dynamics 365 for Outlook add ins. The contacts are Syncing fine but every time when I open the outlook 2016 in my machine, its asking us to add the Dynamics 365 for Outlook add ins to Enable. Please suggest us how the Add ins should stay connected or Enabled longer instead of adding the add Ins every time.
Thank you. Suggestions are appreciated.
Looks like the add-in was installed/registered twice. You need to remove the second instance from Outlook.
Microsoft Office applications can disable Add-ins that behave unexpectedly. If an application does not load your Add-in, the application might have hard disabled or soft disabled your VSTO Add-in.
Hard disabling can occur when an Add-in causes the application to close unexpectedly. It might also occur on your development computer if you stop the debugger while the Startup event handler in your VSTO Add-in is executing.
Soft disabling can occur when a Add-in produces an error that does not cause the application to unexpectedly close. For example, an application might soft disable a Add-in if it throws an unhandled exception while the Startup event handler is executing.
When you re-enable a soft-disabled Add-in, the application immediately attempts to load the Add-in. If the problem that initially caused the application to soft disable the Add-in has not been fixed, the application will soft disable the Add-in again. Read more about that in the How to: Re-enable a VSTO Add-in That Has Been Disabled article.
We have developed a custom outlook addin which has a log file for logging. For installation, we are using .msi installer created using installshield. Installation is successful and functionalities are good except logging. There is only one entry in the log file after installation, rest of the actions are not logging as expected. But the same is fine, if we install the addin using .exe installer created using 'publish' option in VisualStudio 2010. As .msi is the expected installer, any help in fixing this issue is appreciated.
Saravanan,
Make sure that you did all the steps described in the Deploying an Office Solution by Using Windows Installer article.
Is your add-in loaded by Outlook? Did you have a chance to check out the Disabled Items list?
The fact is that Outlook can disable add-ins that behave unexpectedly. If an application does not load your add-in, the application might have hard disabled or soft disabled your add-in.
Hard disabling can occur when an add-in causes the application to close unexpectedly. It might also occur on your development computer if you stop the debugger while the Startup event handler in your add-in is executing.
Soft disabling can occur when an add-in produces an error that does not cause the application to unexpectedly close. For example, an application might soft disable an add-in if it throws an unhandled exception while the Startup event handler is executing.
When you re-enable a soft-disabled add-in, the application immediately attempts to load the add-in. If the problem that initially caused the application to soft disable the add-in has not been fixed, the application will soft disable the add-in again.
Also Outlook 2013 monitors add-in performance metrics such as add-in startup, shutdown, folder switch, item open, and invoke frequency. Outlook records the elapsed time in milliseconds for each performance monitoring metric.
For example, the startup metric measures the time required by each connected add-in during Outlook startup. Outlook then computes the median startup time over 5 successive iterations. If the median startup time exceeds 1000 milliseconds (1 second), then Outlook disables the add-in and displays a notification to the user that an add-in has been disabled. The user has the option of always enabling the add-in, in which case Outlook will not disable the add-in even if the add-in exceeds the 1000 millisecond performance threshold.
I've read that Outlook disables add-ins that take too long to load. That's not usually the case with mine, but I think it's happened on occasion for a couple customers.
I recently discovered the warmup VSTO setting:
A value that indicates that the .NET
Framework and Visual Studio Tools for Office [VSTO] runtime load before an
add-in loads and reduce the perceived time to load an add-in. Set the
Warmup entry to 1, and use it in conjunction with the LoadBehavior
entry to reduce the load time for Outlook 2010 and Outlook 2013
add-ins that are deployed by using Windows Installer (.msi). This
registry key cannot be set by using ClickOnce.
I'm not sure if that "perceived time" applies to Outlook, or only the user. Does anyone know if this reduces how long Outlook thinks the add-in took to load? Or is it still timing the whole process, .NET and VSTO runtimes included?
Warmup key forces Outlook to preload the .Net run-time. This way it will be loaded by the time Outlook starts the timer to calculate your addin's startup time and you will not (supposedly) be punished for having to load a couple hundred megabytes worth of dlls simply for the pleasure of writing your code in .Net.
Can someone give me a quick explanation of when I would use Visual Studio 2008 Outlook 2007 Ad-In project type? and how would that compare to developing a bunch of outlook macros directly in outlook?
Basically, I want to have some sort of application read email (with attachments) from a pop3 email box, do some filtering/editing/validation of the subject/sender/content and then if certain conditions are met, save the attachments to a local file, and then add an entry into an SQL server database table (i.e. date/sender/subject/message).
Seems there are at least 10 different ways to do this....so between an outlook macro and a VS Office Project, how do I pick?
I am not clear, if I create this solution as a Visual Studio outlook add-in, where does it run? Is it loaded into outlook, does it run as a separate process and communicates back and forth with outlook? if outlook is not running, does it start it?
An Outlook Add-on is a compiled component that uses the Outlook API to perform the tasks you need. A macro/VB script is an interpreted script that actually uses the same API. The add-on approach is better if you want to deploy your functionality.
When you work on an Outlook add-on in Visual Studio, you'll be creating a .NET component, which integrates into the Outlook application, which is written in C++ so uses COM. You'll have to be careful about managed/unmanaged types and releasing objects you retrieve from Outlook.
I have recently completed just such a tool, but I chose to use Add-in Express (http://www.add-in-express.com/). These guys provide a layer of abstraction over the [challenging] Outlook API and also provide some excellent support if you're stuck.
In my case, with Add-in Express, I "run" by setting Outlook as the application command to run, in the Project properties. Add-in Express sorts out the installation of the add-on within Outlook. So when I press "Run", Outlook starts and my add-in is displayed, which may be debugged in the normal fashion. I'm not sure how VSTO (Visual Studio Tools for Office) works in this respect - or at least, I can't remember.
This is an example of an outlook add-in..
Personally, I don't see macros distributable.