I just upgraded (if you can call it an upgrade) from VS 2010 to VS 2012. They are now forcing you to use installshield Essentials, which is rubbish and you need to sacrifice a chicken, whilst performing satanic rituals to get it to work.
So my question, can I install the ADDIN manually? I know what registry entries are needed. I ask because I want to know if I can build the addin and then get a third party installer and use that.
Also the MS addins seem to use VSTO, can I not use a simple DLL? I ask because I see my NOD32 antivirus addin is a simple DLL.
Yes, it is enough to include in the installer the DLL, VSTO manifest file and create the registry entries as documented. This way you can create the installer with any tool that integrates in VS, like Wix or Advanced Installer(disclaimer: I work on its development). They are both free for what you need.
Sure, you don't have to use VSTO at all. On the low level, your COM addin is just an in-proc COM server (dll). The COM object exposed by the add-0in must implement the IDTExtensibility2 interface. That's it, there are no other requirements.
See: VSTO 4 ( 2010 ) Lessons Learned
FWIW, I've authored about 10 VSTO AddIn installers and half of them using InstallShield Limited Edition. It actually works really well once you fully understand the deployment requirements and how to use the tools. The primary problem with ISLE is that it does hide a lot of the functionality that's in Windows Installer and more fully explosed by InstallShield Professional Edition.
ISLE allows you to consume setup prerequisites (.PRQ files) but doesn't provide an editor to tweak them if needed. Using an eval version of InstallShield and then back porting the changes to ISLE works nicely there. Also the use of Windows Installer XML (WiX) to create merge modules that get consumed by ISLE solves most of the other problems.
I've got this type of installer template down to the point of taking < 8 hours per project including
project management, testing and close out. Someone brand new to installers should expect to take several months to get something that "seems" to work.
Related
I had to import an older project (in .Net 2) into Visual Studio 2013, it makes use of the Microsoft Primary Interop Assemblies.
Visual Studio said that I need to add references to the project. Now I went and did some reading and apparently Microsoft has only released the PIA for office 2010? (I have Office 2013)
Now what I would like to know is.
Can I get it to work with office 2013 and be backward compatible?
And if so is this a good route to go for the future? Is it going to be compatible? Because I see you need .Net 2 (at the latest) and Windows 8 comes with 4.5 and not 3 (by default) and most new computers are going to have Office 2012 or 2013.
PIAs are a historical artifact, required only by old .NET versions (before v4). They have been thoroughly and elegantly replaced by the "Embed Interop Types" feature, also known as the "No PIA" feature. Supported since Visual Studio 2010, you'll find it back in the Properties window when you select a reference assembly. It defaults to True. A good video that covers the underlying technology is available here.
Which is the reason that Microsoft doesn't publish the PIAs for Office 2013, they expect you to embed the interop types instead.
The feature is very desirable, it avoids your customer having to install the PIAs on his machine and for you to include them with your installer. Solving the issue when neither takes care of it, an entirely too common mishap. In addition, the PIAs for Office are very large, the great advantage of embedding the interop types is that your assembly only contain the types that you actually use. Many megabytes reduced to a few kilobytes.
The workflow is a little different. Instead of adding a reference to the Microsoft.Office.Interop assemblies as available in the Add Reference dialog, .NET Framework tab, you now use the COM tab. And pick, say, "Microsoft Excel 15.0 Object Library" to generate the interop types for a program that uses Excel. If you load an old project that previously used PIAs then just remove those reference assemblies and add them back from the COM tab.
Do note that a feature is lost, intentionally targeting an old version of Office that you don't actually have installed on your dev machine is more difficult. If that's a requirement then you still need the PIAs for that version, force the Embed Interop Types to True in the Properties window. Actually doing this is questionable, Microsoft has a hard time keeping new Office versions completely compatible with old versions. They've kept it up for 15 years now but it has been running out of steam. A worst-case scenario is targeting a newer version than you have installed on your machine, that's liable to make your program crash with very hard to diagnose exceptions like AccessViolationException.
Do note that you have to make small modifications to your code to allow it to work. The synthetic "XxxxClass" classes are not embedded, just the "Xxxx" interfaces. Simply remove the word "Class" from the new statement.
VS 2015 Community with Office 365 - for whatever reason the Add from the COM object does not work. The solution is go into the GAC and find the interop assemblies, copy them to a temp directory, then add to your project like any DLL.
Also, if you don't know by now, Windows 8 does have older versions of .NET Framework but they aren't installed by default. Go to Program Features ---> Add features to Windows ----> and the first check box should be .NET 3.0 and maybe 2.0. Note, if you are on a WSUS server you will need to tell Windows to grab the files from the Windows Update servers. Hope it helps!
Officially there is no backward compatibility of the PIA for Office. In fact it works.
For backward compatibility reasons I'm using the PIA for Office XP since several years and it works fine with Office XP, 2003, 2007 and 2010 (not yet tested with 2013) and on Windows XP, Vista, 7 and 8.
For compatibility with the different versions of Windows I'm using the .NET framework 3.5.
For the future... it depends of what you are doing with the PIA. If possible it is far better to directly deal with the Open XML files or to create an add-in for word/excel.
I just found out that the Visual Studio 2013 express does not have office-support anymore. So you need at least the pro-version to make it work.
Is it possible to manually install my word add-in?
Visual Studio is preparing an installation file for word add-in and it worked great but i want to build more complex installation file. if i knew how to do it manually it would be very easy to build my own installer.
Sure its possible.
If you use Visual Studio 2013, you have two common options to deploy your addin.
One is to use publishing, also known as, Click-Once, this basically does all the dirty work for you, and leaves you with an executable that helps you deploy it on your target machines by simply double clicking it.
The other method is to use the InstallShield.
Go to File > Add > New Project > Other Project Types > Setup and Deployment > Installshield ...
You most likely do not have install shield installed, so once you try to choose that project a webpage will pop up, asking you to register (quickly and freely) to download and install Install-Shield limited edition - do it, its quite fast.
When its done, you may add a setup project to your solution.
now this part is very user-friendly, and allows you to build a custom install to your liking.
Notice that the free "limited edition" as they call it, gives you quite a lot of features, so it should be enough for light weight word addin.
Now, placing the focus on the Word Addin, the whole idea of the install is to place about 4 registry values into the deployed machine to point to the dll you compiled, and describe it.
You can find all the information you need by following microsoft's step-by-step guide on deploying an addin. its very fun and simple. really!
https://msdn.microsoft.com/en-us/library/ff937654.aspx
Good Luck !
I'm developing addin compatible with 2003,2007,2010 and 2013 MS Word versions and XP(not crittical), Vista, Windows 7.
Important note - I'm working with free SharpDevelop IDE, target framework is 4.0.
First of all, I should find installer for relevant version of intertop assemblies and provide it to client. In order to download only one version I have to download the oldest version of PIA. Here I read that PIA for XP works for any MS word version and for any of XP,Vista and Windows 7. Is it true?
This answer talks about implemeting Extensibility interface. I found extensibility GAC reference in SharpDevelop and it's ok. But should I give extensibility.dll to client or it exist on any PC with .NET framework?
What version of Microsoft Object Library is compatible with every OS/Word combination? 2003's 11.0? Is it necessary? Now I'm using office.dll GAC reference without adding object library and it works. But I can't even build project using both office.dll and object library. Doest it mean I can provide to client office.dll and forgot about object library and problems related to compability?
Question about RegAsm.exe. If I compiled project under 4.0 .NET Framework and set target Framework 3.5 what version of RegAsm I should use? Development version or target version?
Oh, i forgot the main question)) After solving compability problems how create setup.exe which automatically installs .NET Framework, Intertop Assemblies and automatically registers addin? Right now I'm doing registration manually - create LoadBehavior,Description,FriendlyName variables in regisrty, call RegAsm - how do it inside installer?
I owe you respect for the work you have undertaken to do all this manually and without the help of Visual Studio. I'm developing also add-ins targeting multiple office versions, but I always use Visual Studio Professional together with the Add-in Express rapid development tool, which covers all of the questions / steps you're asking for. You may get plenty of free information on their website.
Please be aware that creating an installer program working in all the situations you have named can be a very difficult job. Don't forget that in the case of a professional software you must test your deployment on nearly each configuration you're expecting.
ad 1) As for an installer, look for WIX tools which are free. Otherwise you can buy any installer program you like and learn how to deploy. - As for the PIAs, installation can only be done be administrators, so be aware of this.
ad 2) You must deploy the extensibility.dll to your clients.
ad 3) You must use the oldest PIA for all versions, because it is the only one the oldest office version (e.g. Office 2003) can understand. All Office PIAs are compatible upwards. Attention of course you cannot use methods or properties which have been introduced in newer versions.
ad 4) I don't think that there's a difference between the two versions of regasm.exe.
ad Main Question)
I cannot explain here HOW TO DEPLOY AN OFFICE ADD-IN. You need some basic knowledge about the Windows Installer technology first. But you're on the right way.
However, "Installation of the .net framework" I would leave as a prerequisite to the administrator, because it may require reboots.
Additionally, a lot of people have got grey hair pulling the right version of the .net framework in their setup program (say, it is running on a Windows 7 English US with Multilanguage Pack in Dutch running a Dutch Microsoft Office 2010: which framework your setup should install?)
The same for the PIAs: You can just check through custom actions in the installer for the existence of the Office PIAs and cancel the install, if they are not available.
As for the registry keys, normally this is done exactly as you're said: writing to the registry during the setup; and this is done normally by custom actions.
I've created a simple Outlook add-in and I can't seem to get an install package together correctly.
Specs: Visual Studio 2010 (C#), .Net 4.0, Office 2007
The add-in works perfectly in my development environment and appears to install successfully with the setup file I created (using http://blogs.msdn.com/b/mcsuksoldev/archive/2010/10/01/building-and-deploying-an-outlook-2010-add-in-part-2-of-2.aspx).
The problem is once Outlook is reopened after the install, the Add-in is nowhere to be found. It shows up as an "Active Application Add-in", yet it's not available on the ribbon like it is when I run the add-in through Visual Studio. Do I need to hard-code it in the ribbon somehow? Also, I noticed if I manually open the VSTO file and install it, all seems perfect again. Thanks for your help!
There's a lot that can go wrong with a VSTO installation. Here's what I think may be going wrong in your situation:
If you're installing the add-in on your development machine then try a different machine instead. Debugging the add-in on your development machine sort of registers the add-in with Office via some registry keys but that registration info doesn't get cleaned up. (You can certainly clean those keys up yourself and then try your add-in's installer but I recommend a clean machine just in case.)
Try the installation without |vstolocal in the manifest path. I know Microsoft recommends including it but in my own experience it prevented my add-in from loading, and using a normal path fixed the problem.
If you're installing to Office 32-bit on a 64-bit machine then you'll need to write your registry keys to HKEY_LOCAL_MACHINE\Software\ Wow6432Node\Microsoft\Office...
Consider installing your add-in using VSTOInstaller.exe instead of manually writing the registry keys. (I tried to write the registry keys myself but Microsoft's own documentation -- rather, random blog posts -- for doing this is not thorough enough and sometimes just plain incorrect and misleading.)
I have to make a rather complex installer for a C# add-in for Word. I've been researching this for almost two days now and I still haven't found something that can do everything needed.
The main issue here is due to the constraints regarding prerequisites. They mustn't be included in the main installer to keep it small so they'll have to be downloaded.
Additionally, they have to be installed silently without bothering the user. It is ok to show a progress bar or something similar but nothing that requires user input.
After reading about the Windows Installer, Inno, bootstrapper packages and dotNetInstaller I have finally reached the conclusion that the later would be best suited for this scope. However, there's a nasty downside which I have yet to resolve: prerequisites checking.
Is there a standard way to check whether a Microsoft redistributable is installed? The add-in needs the following components:
Windows Installer 3.1
.Net Framework 3.5
PIA
VSTO
Furthermore, I haven't been able to find the direct URLs for these components. I'm wondering how Windows Setups in VS get them.
As a last resort I could host them somewhere to have them at a known location but I'd like to avoid that.
Furthermore, I haven't been able to find the direct URLs for these
components. I'm wondering how Windows Setups in VS get them.
If your using the Visual Studio Setup Project, you can embed them into the setup, and make them required for your application to be installed.
At least for the case of Windows Installer 3.1 and .NET Framework 3.5 SP1
Is there a standard way to check whether a Microsoft redistributable
is installed?
Checking the registry is a quick way.
I would first prompt the user about the downloads first because there would be an uproar if it secretly downloaded files without the users consent. It could also be used for malicious reasons if it were unsecure.
use this tool http://www.advancedinstaller.com/ for creating installer project it has the simple ui interface using which u can handel many comple scenarios in an easy way. U can purchase the tool or can use freeware edition