Helpful advice on developing a professional MS Word add-on - c#

A few months back I put together a simple proof-of-concept piece of software for a small firm with an idea for a document editing tool. The company wanted this tool to be integrated into Microsoft Word, understandably, to maximize its accessibility to the average user.
I essentially wrote the underlying library with all of the core functionality as a C# project, and then used VSTO to get it running inside of Word. It felt like a bit of a duct tape solution, really; but then, I have (practically) zero experience developing tools for integration with MS Office, and it was only a proof of concept anyway.
Well, the firm was quite pleased with my work overall, and they're looking to move from "proof of concept" to the real deal. Fortunately, as I said, the core functionality is all there and will only need to be somewhat tweaked and enhanced. My main concern is figuring out how to put together an application that will integrate with MS Word in a clean and polished way, and which can be deployed easily in accordance with a regular user's expectations (i.e., simply running an install program and voila, it's there in Word).
I seem to remember reading somewhere that nobody uses VSTO for real professional projects. Is this true? False? What are the alternatives? And what are the tips and gotchas that I should be aware of before getting started on this issue of MS Word integration?


One of the main issues with deployment of VSTO solutions has been the total deployment size. You have
your solution
the VSTO Runtime version of the project
the .NET Framework version of the
project
the Primary Interops
This could very easily turn your simple and efficient solution into 40-50MB for someone to have to download. Corporate enviroments are somewhat easier to deploy in, but commercial grade software is tougher.
This is partially solved now in VSTO 2010 with a sort of "only the components you're actually using" Primary Interop deployment. This and other things to make deployment easier, such as One-Click, are certainly a reason to consider VSTO 2010. There are some good intros to this on Channel 9.
Commercial products using VSTO are not unheard of though - StoryboarderPro was written in VSTO and is popular in the eLearning industry.


I also remember reading that VSTO was not ideal for commercial software. Internal software is another matter and it has finally made inroads (at least in my organization).
I believe the biggest argument has to do with legacy versions of Office. VSTO only supports as far back as Office 2003. In addition, VSTO required dependencies have been painful to distribute in the past, although this lessens over time with new Windows releases.
For example, my latest project requires the following (assuming, but verifying .Net framework 3.5 is installed):
VSTO Runtime 3.0
VSTO Runtime 3.0 SP1
Microsoft Office 2007 Primary Interop Assemblies
Hotfix for Office (KB976477) - All users get the application-level add-in

Related

How do I release an Office Add In to the Windows Store

I've created an office add in using Visual Studio 2015. The add in works perfectly with MSProject in debug mode.
I've published the add in following the instructions here. So far so good.
Now I'd like to release it to the Microsoft Windows Store. I've logged into the Seller Dashboard and I pretty much fall at the first hurdle.
It asks for the app package manifest file. TBH I'm not sure which file it wants exactly, so I tried
xxx.OfficeAddin.vsto file in the root of the "publish" directory
xxx.OfficeAddin.dll.manifest in the publish/Application Files/xxx.OfficeAddin_1_0_0_2 directory
xxx.OfficeAddin.vsto
also within the publish/Application Files/xxx.OfficeAddin_1_0_0_2
directory
I assume it wants No2 but it didn't work so I tried them all. None of them work and all result in the same error:
Your manifest does not reference any supported Office Add-in namespace. The most recent version is http://schemas.microsoft.com/office/appforoffice/1.1.Learn More
Googling this error in quotes returns nothing, without quote - a load of unrelated results.
I'm completely stumped now - has anyone managed to do this?

You cannot add VSTO desktop applications to the Windows store, but may be able to do so soon.
The Windows Store was designed for installing applications that would run in private sandboxes that would keep apps isolated (in case of issues) from your operating system and other applications. However, Desktop applications often have registry entries, dll dependencies, and other client-side requirements. Because the Windows Store cannot accommodate these OS-related and client-side requirements, desktop applications cannot currently be distributed via the Windows Store
Fortunately, Microsoft is finally addressing this issue. They are in the process of finalizing Project Centennial, which will allow one to convert desktop apps for distribution via the Windows Store. It does this by providing a separate registry for desktop apps and a way for dlls to function without hurting other applications.
As of this writing, Microsoft has withdrawn the preview version of their Project Centennial Desktop App Converter. I am hoping this is in preparation for releasing a stable version.
Will Project Centennial allow VSTO add-ins to be sold via the Windows Store? I am hopeful, but this is not certain. We should know more within the next couple of months, if not sooner.
Update: June 8, 2016
At Microsoft's dotnetConf 2016 John Sheehan stated that VSTO add-ins would not be supported in version 1 of Project Centennial. He added that plug-ins (his term) that leveraged other desktop technologies would be able to be converted by the Project Centennial Desktop App Converter some time after Project Centennial's initial release (now slated to be concurrent with Window 10's 1st anniversary release in July 2016). Mr. Sheehan did not elaborate on whether VSTO add-ins would specifically work with later versions of Project Centennial, but he did indicate that compatibility with software that leverages other desktop technologies is definitely on the Project Centennial road map.

How to creating an addin for multiple Office programs?

I want to develop addins for Office (Outlook,Word and Excel). The code will be almost the same. The difference is only for retrieve a document (mail for Outlook, document for Word,graphic/chart for Excel.
Should I develop 3 addins and therefore I will have 3 installations for my users. Or can I develop only 1 addin and add a condition somewhere?

Yes, that is possible. You possibly need 3 different AddIn classes, since every platform has it's own format and parameters and you might want to deviate some logic, though there is nothing to stop you integrating the three add-ins in one.
Another option is to make a class library that only uses the general Office assembly, and include that library into your other projects.
For the deployment: you can't use ClickOnce out of the box for that, since ClickOnce only supports a single Office program per installation. You can tweak the installation though, as explained on this article on MSDN: Deploying Multiple Office 2010 Projects in One Package.

VSTO doesn't supoport creating multi-host add-ins. The possible ways are:
Develop an add-in which implements IDTExtensibility2 interface without VSTO.
Use third-party tools such as Add-in Express that support creating multi-host add-ins.
Adding multiple AddIn classes to the extisting VSTO based add-ins is not a convinient way to go. At least, you will not be able to debug the code

PowerPoint Add-in working on Windows 7 Enterprise edition but not on Windows 7 Pro

I have created a PowerPoint add-in using C# VSTO and using msi installer for the deployment.
The Problem is that on every system at my end(all Windows 7 Enterprise edition), the plug-in is working fine, but on users' machines(Windows 7 Pro) either the ribbon is not visible or the events are not working.
My concern is, am I missing something which I need to take care of during the development?
Thanks

This is one of the reasons that VSTO deployment is a pain. You have to understand every dependency of your application and the dependencies of your dependencies and then make sure you cover all of them for every version, flavor and bitness of windows and office that you can think of. Then you come to find out that a user has a Click To Run version of Office installed that generally doesn't support AddIns anyways.
VSTO Lessons Learned
VSTO 4 ( 2010 ) Lessons Learned
Office 2010 Bitness Pain
There are so many possible failure points in the chain that no one could possibly tell you the cause of your problem. A lucky guess perhaps but that would be it. To date I've created VSTO installers for 6 companies and even with my background knowledge and prebuilt templates they are still labor intensive projects because of the test surface that is involved.

C# - Add reference for both MS Excel 12.0 object library and MS Excel 14.0 object library?

I have recently developed a small tool that uses Microsoft.Office.Excel.Interop, and according to my References folder I have added the reference to the Microsoft Excel 14.0 Object Library. I should also mention that I have MS Office 2010 on my machine, so the tool works just fine there.
However I have a client user that is trying to install the tool on his machine (apparently he has MS Office 2003 installed) and is getting an error message.
I was wondering, would there be any issues if I download the Microsoft Excel 12.0 Object Library and also add its Reference into my tool so that I have references to both, MS Excel 14 and MS Excel 12? ... would doing that even make sense?
Again, I'm fairly new to .NET and my programming experience is purely empirical, as in no school. Just a heads up in case this is a stupid question.
EDIT:
I found something that seems to solve this problem. I had my client download the file from this link: http://www.microsoft.com/en-us/download/details.aspx?id=3508
Then just follow the instructions at the bottom, and this apparently solved the problem. He was able to install the tool and run it without issues.

The best solution I have found is to use a virtual machine as a build machine that has the oldest version of the office Interop libraries installed that I care to support. I did run into a number of issues trying to develop with multiple interop versions on my development machine.
Microsoft does provide guidance on building clients for multiple office versions but I found that too cumbersome for my particular use case.
http://support.microsoft.com/default.aspx?kbid=244167
You also might consider skipping Interop entirely by using an alternative library, such as the open source EP Plus. I have not personally tried that one yet, but it looks promising.
http://epplus.codeplex.com/

There are some differences between the versions of the Interops. If you will use some members that were added in the newer version then the older versions won't work. For example here is a list of what all was added in Interop version 14:
http://msdn.microsoft.com/en-us/library/office/ff194938(v=office.14).aspx
If you use any of those your application won't work in older versions since these members were not available in older versions.

Differences in development between .NET and Mono

I'm looking into Mono and .NET C# and we'll be needing to run the code on Linux Servers in the future when the project is developed. At this point I've been looking at ASP.NET MVC and Mono.
I run an Ubuntu distro and want to do development for a web application, some of the other developers use Windows and run other .NET items with Visual Studio.
What does Mono not provide that Visual Studio does?
If running this on Linux later shouldn't we use MonoDevelop?
Are there some third party tools or add-ins that might be an issue with Mono later?

What does Mono not provide that Visual Studio does?
MonoDevelop is presumably what you mean here. MonoDevelop offers cross platform development on Linux, Mac OS X, Windows based on GTK. However it is not as polished as Visual Studio for obvious reasons - it's 3 people making it, not hundreds. It has some nice features, especially its source control plugin architecture. However as Visual Studio Express is free there aren't many advantages on Windows to using it.
It uses the same .csproj and .sln format as Visual Studio, however the XML docs format is different.
If running this on Linux later shouldn't we use MonoDevelop ?
As I mentioned above, the project formats are inter-operable.
Are there some third party tools or add-ins that might be an issue with Mono later?
Unlike Visual Studio, there aren't a huge wealth of add-ins for Monodevelop. The ones that you use in Monodevelop won't effect your .csproj files at all, as anything Visual Studio cannot read it generally ignores.
As people have said don't confuse Mono for MonoDevelop. MonoDevelop is an IDE for Mono that originally came from (forked) SharpDevelop.
Mono is the cross platform framework that 'apes' the Microsoft CLR and framework libraries.

I don't have much experience in this area but...
The Mono Project Roadmap has an overview of features that are new, upcoming, and not present in Mono compared to MS.NET. Even where Mono has the same classes as .NET, note that compatibility is not 100% (although that is generally their goal). I'm not sure if there exists a comprehensive list of things missing in Mono.
MonoDevelop is now available on both Windows and Linux so you're probably best off using it. However, MonoDevelop does appear to use the same project file format as Visual Studio and SharpDevelop, so you could make an attempt at mixing IDEs.
Of course, when using 3rd-party .NET libraries, note that many of them have not been tested with mono, and in particular anything that uses P/Invoke will not work on Mono for Linux. However, most incompatibilities with mono are minor, and if you stick with open-source libraries you can always fix any incompatibilities you run into.

You might also take a look at Mono Tools for Visual Studio. It lets your visual studio developers target and test with the mono platform.

You're aiming to always have support, and/or primarily use the software on Linux, correct? This is actually a question I asked the Mono developers at a conference a little while back, and it basically boiled down to what you want to do with it.
If you want it to always work on Linux, then use Mono. If you only care about Windows, then use Visual Studio.
If you're using Mono, then use MonoDevelop across all developers. It'll just make life a lot easier later on, and it'll make sure that whatever you write in the one will work for everyone.
Unfortunately, I do not know the answer to the exact limits/advantages of Mono vs. .NET, aside from .NET being further ahead, and Mono playing catch-up, nor about different addons.

If none of your developers need to develop on Mono for certain features, I suggest you all use Visual Studio on Windows. Then test the applications on Mono via
Mono Tools for Visual Studio
manually copy the binaries over
check out the code on Linux and build in MonoDevelop.
Personally I experienced a lot of small troubles when I tried out the third way, but luckily I am capable of finding workarounds.
It is only when you touch Mono, you know which part of your application needs to be tuned.
http://www.mono-project.com/Start

If you can help it, it'd recommend avoiding the Mono implementation of Remoting. There seem to be some unexpected hiccups and debugging it is not straight-forward.
We had a very Remoting heavy product that we tried to port to Mono so we could support Linux. Due to being unable to resolve the Remoting issues, we eventually had to abandon our attempts at supporting Linux altogether.
Caveat: my experiences may be outdated. See comments below

You don't need MonoDevelop in order to run ASP.NET program in Linux, make a shared folder on your development server (VMWare'd or real one), test often so you can easily work-around what's missing from Mono
That's the same approach I'm using in my .NET Remoting program I host on Ubuntu server. But I do the reverse, since I'm a solo programmer, I make a shared folder on my Windows development machine, then access that shared folder on my Ubuntu test server (vmware'd). On ASP.NET stuff, if the changes don't reflect on your Ubuntu test server, in Terminal just touch the Web.Config file in your Ubuntu test server. i.e. touch Web.Config, then refresh the page

Mono has a fully functional implementation of ASP.NET. This includes full support for ASP.NET Web Forms and Web Services. This essentially means that more or less any ASP.NET application that you have developed using with the .NET Framework will work with Mono. Obviously there might be changes needed, such as data access changes, removal of any
reliance on .NET Framework BCL types . Mono- Oracle users-.Net Programming C# : ubuntu 11.04

Categories