I have deployed a VSTO application by using ClickOnce and I got this:
This installer works real fine.
However, what I really want is one single installer, like a single .exe file or a single .msi file, so that it would be much convinenet to distribute.
I guess I have to pack all the dll, xml, vsto and exe into one single installer. Does anyone know how to do this?
Thanks in advance to anyone who has taken time to look at my problem!
Check this https://github.com/bovender/VstoAddinInstaller
A few years ago I wrote a few installers for VSTO projects via Inno Setup. There are also other players like (all paid) Advanced Installer, InstallShield and probably many others.
There is also VS installer but I've never used it (but still should be possible)
Related
I have an excel plugin that I want to distribute as a single installation package, preferably MSI. Is there an easy way of doing this?
I've created many office addin installers for customers and basically have it down to a template starting point. For pointers see my blog article:
VSTO 4 ( 2010 ) Lessons Learned
ClickOnce is still technically used but the |vstolocal tag is used to run from source and not deploy to the click once cache. Basically you get a per-machine MSI experience and a setup.exe that makes sure all of your prereqs are present.
The best way is to create an MSI installer from scratch, not try to wrap your ClickOnce package. Any MSI package, no matter the tool you use to build it, can install the addin, as long as it install the files and registry entries required, as documented in the following MSDN article.
If you are looking for a free tool and have some time on your hands to learn using it than WiX is the best.
I was wondering if anyone knows how easy it would be to convert an install project created with the standard visual studio 2010 install project to a WIX project.
This install project has a custom actions dll as well. I read about Heat but I'm not sure what it does.
I'd describe the process more as refactoring then converting. For example, the custom actions you are using very well may not be needed. Often times CA's are used to do things that MSI supports natively such as installing a windows service. (Reinventing the wheel.)
I approach situations like this with:
1) Examine the VDPROJ and custom actions for intent.
2) Possibly use Dark to decompile the MSI to wxs files.
3) Reauthor the WiX as cleanly as possible.
I've done this many times so it's 'easy' for me. If you don't have the underlying Windows Installer experience and/or WiX experience, it'll be far more difficult yet also rewarding in terms of building your skillset.
Why should one go for Windows Installer XML (WiX) when we have in built .net MSI installer?
It would take me hours to rant about everything I hate about VDPROJ. I won't because in my (expert) opinion it's already settled law that VDPROJ sucks. If your install is so simple that you haven't noticed any problems, then be my guess and stick with it. But if you already find yourself fighting the tool trying to get it to do things it doesn't do, then take my advice and dump it fast for WiX.
10 things I hate about VDPROJ
No MSBuild Support. Sure, you can call devenv from the command
line but it's not as good.
No exposing of the critical concept of
a component. Every file/reg key is a keyfile of it's own component.
No effective way to fully exclude automatic dependency scanning.
Shortcuts are always Advertised
No way to describe a service.
No way to describe many things which leads to overuse of custom
actions.
No way to fine control the scheduling / execution of
custom actions. Too abstracted.
Abstraction is wrong. Deferred
CA's are scheduled with Impersonation which breaks on Vista.
Various limitations lead you down a path of massaging the built MSI
during postbuild to get around all the limiations. Results in a
very poor build automation hacks.
Merge Module directory tables
are authored incorrectly.
100 other things suck that I'm not
remembering right now.
The introduction of WiX tutorial gives the basic idea about WiX advantages comparing to other setup development tools (including VS setup projects):
declarative approach
unrestricted access to Windows
Installer functionality
source code instead of GUI-based
assembly of information
complete integration into application
build processes
possible integration with application
development
support for team development, both
in-house and third-party
free, open source
Hope this helps.
Visual Studio deployment packages can only be built by visual studio. They cannot be built using plain MSBuild command lines, which makes them less than ideal for e.g. build servers.
All the above answers have included most of the annoying features of Visual studio setup projects (.VDPROJ), one thing that most people have missed.
.VDPROJ file format is such that, and if we make a small
change to one single entry it completely rewrites all the entries
within which makes it impossible to merge changes from 2 different
branches.
Some of us don't want to use / can't use the .NET installer.
Some of us don't want to have to install Visual Studio to distribute a program, written in, say, Borland Delphi. WiX and .NET have nothing to do with one another.
WiX provdes a much more complete feature set than the .NET installer.
the company I work for is looking at different options for installers. The product consists of a ASP.NET web site, some web services, and windows services. We'd like to be able to install everything in one go, but be able to uninstall or update services individually. We'd also like to be able to configure/edit xml files (like app.config or custom xml files) from an installer dialog, without too much of a hassle.
Of Installshield, Wix, and NSIS, is any particularly well suited for doing this?
WiX and InstallShield can both do it but both will take a huge learning curve either way. NSIS can do it also, if you consider running vbscripts during an installer elegant. Someone with experience could help you ramp up faster.
I just finished an installer that needed to support IIS7 and I have to say some things are easier with WiX compared to InstallShield once you worked in MSI development for a while.
Last year I heard that Installer Projects were going away and we should be switching to Windows Installer XML. Whatever happened with that?
So you know where I'm coming from, support for TFS-based buil machines is very important to me. I know Installer Projects kinda-sorta work with TFS, but they have issues.
IronRuby uses Wix, but that requires upkeep and scripts. I haven't looked into parrafin or anything like that yet, but the mix of a Parrafin (like) script and WIX would probably work well.