I found some ways below.
1. Add-in Express
2. VSTO
3. unmanaged c++
I'm not sure is this right?
And which way can compile only a dll without any dependency.
Using outlook add in, could I get the drag attachment event?
You will be surprised but there is only one way for developing Office COM add-ins - implement the IDTExtensibility2 interaface. All the paths you mentioned follow this pattern and have their own pros and cons.
You can use managed programming languages for developing an add-in as well (C# or VB.NET). C++ is not required. Erlier VS versions had a template for that called "shared COM add-in". VSTO and Add-in Express provides shims (loaders) that create a new Application domain to run your add-in code in isolation from other add-ins. It is up to you which framework to use, or just not to use any.
Related
I am new in Office add-in development and little bit confused about creation JS plug-ins for Outlook. Actually we can create one add-in which will be available on all platforms: Outlook on Mac/PC, Outlook.com and Outlook 365.
But what about tools for it? According Outlook development documentation, we can use Yeoman generator for creating Office add-ins. However in my VisualStudio Community 2015 is type of project like "Web add-in", where I can chose Outlook add-in. So is there some difference between Yeoman generator and VisualStudio Web add-in projects?
Visual Studio is the main tool for creating Outlook plugins. You can also use Visual Studio Code for developing web-based solutions.
Office add-in is nothing else as "manifest.xml" file + your web application (HTML + JS). Web application is what your VS Code is help you to create. The manifest part is something which you able to write yourself, coy it from an example or use YO Generator to produce it for you. More on how to build office add-ins: Office Add-ins with VS Code and how to use generator: Yo Code - Extension Generator
To answer your question "is there some difference between Yeoman generator and VisualStudio Web add-in projects?": There is no fundamental difference. First choose whether to develop your Outlook Web Add-in with VS or with some non-VS tool. If you use VS, then use the project templates in VS. If you use any other development tool, use the yeoman-generated templates.
Occasionally, templates can get out-of-date. For example, recommended practices may change, or the manifest XML schema may be expanded. As a general rule, the yeoman-generated templates are updated more frequently than the ones generated in VS. For this reason, there may be small differences in the templates (besides the differences that are inherent to the differences in the tools).
Visual studio 2012, being run under desktop mode under windows 8. Doesn't share the look of other windows 8 desktop applications.
How was this GUI achieved?
Did Microsoft scrap MFC/Winapi altogether (since its so different) and use Direct2d to create the custom gui? Or, have they just made calls to Winapi to customize it they way it looks?
Is there any shortcut for us developers to implement the vs2012 theme in our applications? Using the MFC Application template wizard we can chose from many themes but no vs2012 alike is available.
Indeed, Visual Studio 2010/2012 leverages WPF.
LEVERAGING WPF
WPF utilizes DirectX. WPF attempts to provide a consistent programming model for building applications and provides a separation between the user interface and the business logic. WPF leverages XAML, which is a declarative markup language. XAML stands for eXtensible Application Markup Language, which is based on XML. XAML is designed as a more efficient method of developing application user interfaces
ITS ABOUT MULTIPLE DOCUMENT WINDOWS AND FLOATING TOOL WINDOWS
Visual Studio was written to support multiple document windows and floating tool windows.
GREAT LIBRARIES ARE AVAILABLE
Codeplex provides a library to model the multiple document windows.
http://wpfmdi.codeplex.com/
There is also a docking library you can leverage:
http://avalondock.codeplex.com/
MEF IS USED HEAVILY
The internals have been redesigned using Managed Extensibility Framework (MEF).
MEF allows application developers to discover and use extensions without messing around with configuration files.
MEF allows you to easily encapsulate code and avoid fragile hard dependencies.
This allows developers to create add-ins to modify the behavior of the IDE.
DESIGN GOALS
In Visual Studio 2012, a one change is that the interface uses of all-caps menu bar.
Some design goals include reduced clutter and visual complexity by removing excessive lines and gradients in the UX.
The UI has been modernized by removing outdated 3D bevels.
You can take Spy++ which comes with Visual Studio and inspect the windows/class names of the application. If you do it with VS 2008, it's obvious that it's MFC. If you do it with VS 2010 and later, you will see that it's all WPF stuff--no MFC involved.
I'm using Outlook 2010. Via the Developer ribbon, I see that I'm able to script Outlook using VBA. I'm also aware that you can create Outlook addins through COM that can pretty much have anything as their source language (C# / .NET included).
However, is there any way to actually code extensions to Outlook using built-in Outlook functionality using C#, rather than VBA? If not, are there any plans for Microsoft to allow this in future versions of Outlook?
I'm not sure what you mean by "built in" functionality. Addin can access anything VBA can access AFAIK.
Are you talking about converting the VBA editor to c sharp?
Few question about VSTO project I don't understand:
Registration - unlike native Office Plugin, where I've an installation project, how does the deployment work in managed add-in? After building the project, I do have the necessary entries in the registry that define the plugin (HKCU\Software\Microsoft\Office\Outlook\Addins...). Where is the code that perform this registration?
Also, why in the HKCU? I'd like the plugin to be defined for all users (in HKLM). How do I change that?
How does Visual Studio know to start Outlook, when I press F5? In the property page for the project, under the debugging tab, the 'Start Option' is set to 'Start project'. Who tells Visual Studio that starting the project means starting Outlook?
Looking for more materials about VSTO. Can you recommend a resource?
A few answers
1. Basically the same for a managed project except that the Reg entries point to the .MANIFEST file, which in turn identifies the dll of the addin assembly.
Ohhh. this is a LONG story, there's lots of info on the web about it. Google "registering an addin for all users".
Short version is that it's possible, but requires some really weird and difficult to explain registry shinanigans.
If you've created an Outlook addin property, then by virtue of that project type, VS knows what to do on start.
I've never found a good definitive source for vsto material. Google's been my best friend for that kind of info. Andrew Coates has a pretty decent list here though
http://blogs.msdn.com/b/acoat/archive/2007/08/02/vsto-resources.aspx
I have no explicit information but currently I'm working through http://msdn.microsoft.com/en-us/library/ff937654.aspx which so far has been a great source of information. Please let me know if this worked out for your Outlook project.
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.