How does Excel VSTO Work? If I create an Excel Workbook solution in Visual Studio 2005 I can then happily code away with full access to the Excel object model and even treat the Excel sheet as a design surface. When I build the solution I get a .XLS file and a .DLL (containing my C# code).
I can now start up the Excel sheet just by double clicking on the .XLS and there is my sheet functioning with all my C# code and any controls I dropped on the sheet etc.
How is the sheet referencing the .DLL? What part of the excel workbook/sheet tells it that it needs to fire up the CLR and host my assembly?
According to this (thanks PintSizedCat) for Excel 2003 the following happens:
The Microsoft Office application
checks the custom document properties
to see whether there are managed code
extensions associated with the
document. For more information, see
Custom Document Properties Overview.
If there are managed code extensions,
the application loads AddinLoader.dll.
This is an unmanaged DLL that is the
loader component for the Visual Studio
2005 Tools for Office Second Edition
runtime. For more information, see
Visual Studio Tools for Office Runtime
Overview.
AddinLoader.dll loads the .NET
Framework and starts the managed
portion of the Visual Studio Tools for
Office runtime.
The Visual Studio Tools for Office
runtime creates an application domain,
sets policy for the application domain
not to trust the My Computer Zone, and
checks the code access security policy
store to find a policy for the
customization assembly.
The .NET Framework validates the
evidence presented by the assembly
against the policy. If it fails, an
error is raised. If it passes, the
process continues.
If the customization uses a deployment
manifest, the Visual Studio Tools for
Office runtime uses it to check for
assembly updates. If any updates are
necessary, they are performed now.
The Visual Studio Tools for Office
runtime loads the assembly into the
application domain.
The Visual Studio Tools for Office
runtime calls the Startup event
handler in your customization
assembly. For more information, see
Visual Studio Tools for Office Project
Events.
In my test project's Excel workbook I have two custom properties:
_AssemblyName, value = *
_AssemblyLocation, value = {533b2c13-a125-418a-bfff-9546b0762807}
I suppose these are the properties which direct the VSTO runtime to my assembly.
This is all done in the Registry, you should be able to find the key in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\Excel or your equivelant application. I've more experience with COM Addins which are registered somewhere else in the Registry as well. This key should have a LoadBehaviour item under it which is used to determine how the application is loaded (2 is load manually, 3 is load automatically on startup).
Do you have a Setup Project for your VSTO? Inside there you can see the Registry key that is set, but the Setup program will/should also Register the VSTO in GAC (though don't take my word for it as I'm a bit shakey with VSTO as I said).
Hope this helps, I shall try and find some more information for you.
Edit
You should try reading the following http://msdn.microsoft.com/en-us/library/bb386298.aspx which will give you an explanation of what the addin is. It's really just a wrapper around a COM host which is loaded from the Registry and the VSTO talks to that using some Interoparability code.
Also useful are http://msdn.microsoft.com/en-us/library/23cw517s.aspx (Getting Started with Visual Studio Tools for Office, don't knock it because it says Getting Started in, there's a lot of useful info in there) and http://msdn.microsoft.com/en-us/library/hy7c6z9k.aspx (Which is linked from the first and is an overview of VSTO Addins).
Related
I have an outlook plugin built with Visual Studio 2010 (.net 4.0 Client Profile), that works fine in Outlook 2007 and Outlook 2010. I just tested on 2013 and even installing the addin seems to crash. After googling, I see a few examples of issues people have faced but fundamentally can't get a straight answer to this question:
Is there any prerequisite that would not allow a VS 2010 Outlook addin to just work on 2013 or do I need to upgrade Visual Studio and Create an Outlook 2013 specific version of my addin?
The Running Solutions in Different Versions of Microsoft Office article describes all details. It states the following:
If you developed solutions for Office 2010, you can run the same solutions in Microsoft Office 2013. Solutions that were created by using Visual Studio 2013, Visual Studio 2012 or Visual Studio 2010 can run in Office 2013, Office 2010, or the 2007 Microsoft Office system.
What is the target .Net framework of your add-in? Did you try to debug the code? Do you get any exceptions?
Do you have Outlook 2013 on the machine you have the add-in project on? If you do, you can debug from VS 2010 by setting the "Start external program" in the Debug tab of the project properties window to the Outlook 2013 .exe. When I created my add-in I was able to debug it using whatever version of Outlook was on my development computer and I don't remember changing anything other than the external program path.
If you are using setup project for the installation it needs a different ComponenedId when you create its launch conditions. You'll need two different setup projects to install on Outlook 2010 and 2013. Here are the Office 2013 PIA keys and Office 2010 keys.
Did you try enabling the add-in again? It won't run after its in the disabled queue. After you re-enable it from the disabled add-in screen, you can then check the box in the COM-AddIn screen to have it load which then should prompt you more detail since you set the VSTO_SUPPRESSDISPLAYALERTS variable about what may have happened in the first place.
The problem can be that the add-in had been hard disabled by Outlook. Notice that the add-in did not show up under Inactive Application Add-Ins, but rather under Disabled Application Add-Ins. That makes a difference: In the latter case, just going to the COM-AddIn screen and ticking the check box is not enough to solve the problem.
Follow these steps for hard disabled add-in?
Goto the Manage box, change COM Add-ins to Disabled Add-ins, and then
click Go. Select the add-in and click Enable. Click Close. OK, now
the add-in can be loaded again:
In the Manage box, change Disabled Add-ins to COM Add-ins, and then
click Go. select the check box next to the disabled add-in. Click
OK.
Reference THIS site for further details.
I vaguely remember encountering an AddIn crashing on installation in the past... resolution is:
Install Visual Studio 2010 Tools for Office Runtime on the target machine.
Try the VSTO AddIn install again and you wont get the crash during installation.
Before trying to install it, you can try to run it trought the debugger to have more info on the real problem. As far as I remember, you just need to go to your project properties and change the launched version of outlook while debugging...
You can follow this link for more info : http://www.greycastle.se/vsto-project-office-target-version/
Assembly Loading issues are difficult to debug because there are at least two layers to this when dealing with Managed and Native code.
When an executable is started the native loader must find the file, load it into memory along with all the dependent DLLs to make it run.
The native loader looks into the assembly manifest to determine this information and then simply hunts down all the DLLs and load them into memory (in order).
You can easily see this process using WINDBG and pointing to an EXE and running it from Windbg. The list of modules being loaded is the native loader at work.
If a dependency is a .NET managed code assembly then the native loader transfers the loading request directly to the managed loader, known as "Fusion".
You can easily set up the FusionLOG viewer to see what is happening http://msdn.microsoft.com/en-us/library/vstudio/e74a18c4%28v=vs.100%29.aspx
Failures of loading at either the managed layer or within the managed layer are easily spotted either through WINDBG for Native or the Fusion Log View for Managed code.
A few hints on Managed DLL loading: If an assembly holds a reference to a dll that is not included in that assembly, there is a strict order of "probing" which is followed to find the dll. There will be a minimum of three attempts to find the DLLs in different places such as in the assembly, in the program root path and in the GAC. If the three attempts fail, loading is stopped at that point and the program will not run. When this happens it is often considered a system level environmental issue; however, in reality it's a programming issue because unless pre-requisites are fully know by the system administrator there is no way they can guess at this stuff. If you are a programmer who is including other dependent dlls you should always consider whether or not to place them into the assembly to stop this problem. Otherwise you, the system admins, and folks using your program will have to wait until the root cause is determined which takes a long time.
You may say, well I was told by another department to use this dll and I have no idea what the other dependencies are! This is no excuse, as there are excellent tools such as ILDASM and even managed code Dependency walkers that will tell you everything that's needed. The best way to package these "other" dlls is to simply include them in your assembly.
I have been trying to create a deployment for a C# Outlook 2003 add-in. It requires only NET 2.0 and relies on IDTExtensibility2 (of Extensibility.dll). Upon making sure Office 2003 PIA are installed the add-in still won't register because of Could not load file or assembly 'Extensibility, Version=7.0.3300.0, Culture=nuetral, PublicKeyToken=b03f57f11d50a3a' or one
of its dependencies. Strong name validation failed. (Exception from HRESULT:
0x8013141A)
I don't think deploying Extensiblity.dll is legal and I could not make it work even if it was. So how to make sure it is available on the target PC?
I could not find an adequate solution anywhere.
The solution is developed in VS 2010.
If your outlook add-in is signed using a strong name key then any external libs that you reference will also need to be strong name signed.
I've had a similar problem to yours in the past where 3rd party libraries were not signed with a strong name.
After doing a bit of searching around I came across this Microsoft Support article that provides a resolution.
In brief:
When you use Microsoft Visual Studio 2005 to create add-ins, smart
documents, or smart tags, you may experience the following symptoms:
The add-ins, the smart documents, or the smart tags cannot be loaded in any Microsoft Office application.
The add-ins, the smart documents, or the smart tags do not run in any version of Microsoft Office.
and their resolution:
To resolve this problem for Visual Studio 2005 developers, a
redistributable version of the update for Visual Studio 2005 is
available.
Found Extensibility.dll in
\Visual Studio Tools for Office\PIA\Common
folder. Copied it to the project folder.
I have VSTO 2010. Added the reference to my project, and the compile error went away. Same version on the error: 7.0.3300.0. VSTO is distributed freely by Microsoft for developers, to create solutions for Microsoft Office, but the license document enclosed with VSTO 2010 doesn't allow you to make copies of it except for your own use. That being said, I would pester Microsoft about the dll, as obviously you need it for your project. Obviously, they should have added a clause to the license to allow distribution of the dll by developers.
I want to create an add-in (a ribbon precisely) for MS Excel by using Visual Studio C# 2010 Express. I have searched and read about it here and here and somewhere else. However, when I want to create a new project I don't see any template as described, I don't see even the Office tab. Is it because I am using the Express edition? I think it shouldn't be. Because in this official comparison they say all editions are capable of office development.
What can I do to develop this add-in?
According to this post on the MSDN forum, Visual Studio Tools for Office are not available in the Express edition. I'm not sure where you're reading that on the comparison page (a quick glance said nothing about the Express edition).
A good alternative to VSTO for making an Excel add-in with .NET is Excel-DNA (which I develop). It is a free library that integrates your .NET assembly with Excel using the C API (as an .xll add-in). You can create user-defined worksheet functions (UDFs) for Excel (which are not supported by VSTO), and make ribbons, RTD servers. And you get easy deployment (a single .xll file) without needing any registration or admin rights, even for ribbons and RTD servers.
Another option, if you just want to integrate through the COM interface and not make UDFs or use the specialized Excel features, is NetOffice. The project give you a version-independent set of interop assemblies for Office and Visio, and allows you to easily make add-ins targeting different versions of Office. NetOffice can also be used as your COM interop library in an Excel-DNA add-in.
Both of these directions will work fine under the Express editions of Visual Studio, as well as in the free SharpDevelop IDE.
I have a project that adds functionality to Microsoft Word using an XML Expansion Pack. Currently, when the document we give the customer is opened, it loads our pack, which executes the SmartDocInitialize method which adds things to the main menu and toolbar using Microsoft.Office.Core.CommandBar.Controls.Add and the like. Without modifications, when opened in Word 2007 these buttons are added on the Add-Ins ribbon tab, but this isn't ideal since the buttons are all small, not grouped properly, and there is no way to bring the Add-Ins tab to the front when the document is loaded.
I would like to keep this functionality the same if the document is opened in Office 2003, but if the document is opened in Office 2007, I would like to read in an xml file which describes my new Ribbon tab and all of the buttons. Everything I've been able to find online has seemed to lead to the Ribbon file only being loaded if you have a very specific combination of magic (build in Visual Studio and it works, but no information on how you would deploy it to a users box) and will only work if you have an entire project created originally with the Visual Studio tools for Office properties, which I don't currently have.
Our development environment is XP, Visual Studio 2005, C#, .NET 2.0
The Ribbon UI is just not as programatic as the old CommandBars UI. I don't think you can do what you want. As far as I know the only way to programatically modify the Ribbon UI is to have a (COM) Add-in implement the IRibbonExtensibility interface and return a custom XML file (with the Ribbon definition) from the GetCustomUI method. There is no way to add or remove buttons one at a time like you could with the CommandBars UI. It's just totally different. I don't believe you can do what you want from some macros in a document.
I'm not familiar with XML expansion packs, but if you have to install them on the user's PC, perhaps you could install an add-in as well that could load the appropriate ribbon XML for you.
This isn't as hard as it seems.
If you already have your ribbon buttons hooked up to some VBA macros in the document, then you just need to add a reference in your VBA project to your com visible .net assembly.
The .net assembly in addition to being marked com visible (so it shows up as a type library in the references dialog box), has to have some methods that are setup to be callable from VBA.
google "vba .net callable"
its not difficult, mark class as com visible, declare it with a ProgID attribute, make methods public, make sure your methods return simple types, and use regasm to register the assembly on the target machine (not needed on dev box).
I want to use C# class methods in Excel. Can anybody guid me how to do it ?
The C# component will be excel add-in. How to create setup for this addin, so that I just need to give setup to user which will install add-in at client's machine. User should not need to do any other steps like registering the C# dll.
(Disclaimer: I develop the Excel-Dna library.)
You should have a look at Excel-Dna - http://excel-dna.net. The library allows managed assemblies written in C#, VB.NET or F# to expose high-performance user-defined functions (UDFs) and macros to Excel through the native .xll interface. The project is open-source and freely allows commercial use.
With Excel-Dna you can create a single .xll add-in file that the user can open as an add-in without any further installation or registration. Excel-Dna add-ins can expose RTD servers and customized Ribbons for Excel 2007 and Excel 2010 without additional registration, so you need no extra setup program.
You will need to create a new Visual Studio project of type Excel 2007 Add-In (or Excel 2003 Add-In). The option for this can be found (in Visual Studio 2008) at:
New Project dialog -> Project types -> Visual C# -> Office
This Add-In will need to be installed on the target machine(s).
The Add-In will be able to hook into the Excel object model and therefore access any loaded spreadsheets etc.
The Add-In will also be able to add buttons to the Excel toolbar/ribbon.
Try looking at VSTO, there's a section explicitly for Excel
You can create Excel projects within Visual Studio (previously known as Excel VSTO projects) or you can use a third party library such as ExcelDna.