Hi I inherited a word ribbon project. I need to create an installer but first I would like to manually install it(i.e. copy files and run commands in command prompt).
The problem is that I don't know how to deploy the ribbon onto another PC. All I know is that I created a word ribbon in VS and when I run it, word opens and the ribbon appears.
I need to be able to deploy it on word 2007 onwards, 32 and 64 bit where available.
Thank you
I would recommend to create an MSI for deploying your add-in, this is the most used distribution system from Windows, that has built-in support for silent installation, repair, rollback and uninstall. So you can easily have your clients deploy it through Active Directory/GPO or SCCM if they need to.
When using a MSI to deploy the addin you basically copy your add-in resources/files in the desired installation folder and create the registry entries as mentioned by Patrick.
I recommend installing the addin per user, that is to install the files under APPDATA folder and the registry entries under HKCU. Installing per-machine will require admin privileges from your users (maybe not all will have that privileges) and you will also have to work much more to see where to write the registry entries under HKLM, because here you have the key "Wow6432Node" dedicated to 32 bit applications, so based on the edition of WIndows and that of Office you need to see if you will need to write under "HKLM\Software\Office..." or under "HKLM\Sofware\Wow6432Node\Office...". When you install per user under HKCU this problem is gone as under HKCU\Software there is not registry redirection, so the extension will work for all 32 and 64 bit machines/flavors of Office. Also, installing the extension per-user will automatically give your users the possibility to install different versions of the add-in on different accounts from the same machine, if this will ever be needed.
A very important thing, you should have a launch condition in your MSI for Word 2007, so that the users which don't have installed cannot install your add-in also. All tool authoring tools should be able to set this launch condition quite easily.
Also, you should digitally sign your MSI and addin with a code signing certificate (acquired from a certified vendor, like VeriSign, Thawtee, etc...).
To create the MSI package you have multiple options, but basically you can use any tool that is capable to create MSIs, as long as you create the registry entries correctly. For example Advanced Installer (the tool on which I work on) has a nice wizard that just asks what version of Office you target, asks you the files you want to install and it automatically handles the rest for you. You can have it integrate with VS so you build the MSI directly from your VS solution if desired. As for the launch condition, it is just one click away in the Advanced Installer GUI, no need to do any scripting.
You can create a ClickOnce installer by clicking Publish on your Visual Studio project in the Solution Explorer or by editing the registry.
Related
I have created an installer project using Install Shield on Visual Studio which is required to install a custom VSTO add in to Outlook. The setup file is created as required and it runs without any issues, all of the files that are required are installed to the correct directory and all the registry files are added to the users registry as required.
However, Outlook does not seem to be finding the add in at all. Can anyone point me in the right direction with this?
For anyone in the UK - The registry entry "LoadBehavior" must be spelled exactly as it appears here. I used the UK spelling "LoadBehaviour" and it was the sole reason my install was not successful. I was held back for several days due to this.
First of all, make sure that you did all the steps described in the Deploying an Office Solution by Using Windows Installer article.
Do you see the add-in listed in the COM add-ins list in Outlook?
Make sure the right windows registry hive is used. Note, it depends on the Outlook/Windows bitness.
What I Have Done:
I created a Visual Studio Setup Project that creates the installer for my WPF application. This installer creates the MSI I use to install the application.
I created a Primary Output with my primary project and created a shortcuts to this.
The application installs successfully.
Problem:
When I click the shortcut that was created on the desktop I get the following screen before the application loads and starts:
Header: [Application Name]
Message: Please wait while Windows configures [Application Name]
Loading Bar Header:
Gathering required information...
(Followed by a progress bar and a cancel button)
This takes up unnecessary time.
The application starts after this finishes and continues as intended.
How can I prevent this from happening, what reasons could there be for this to happen?
PS: when I open the application from the exe in the program files this does not happen.
This nearly always happens because people are unaware of the fact that if they install a file (or registry entry) and then delete it later a repair will be triggered by using an advertised shortcut. There are other entry points into repair, but shortcuts are the obvious one. Attempts to defeat repair are often pointless because there are other things that can prompt a repair of a changed product. such as upgrades, patches, and the user right-clicking the MSI to repair, or doing repair from Programs and Features.
Another cause is that the setup installs an item (such as a file or registry entry) into a user profile location (such as User's data) in an Everyone install. The is installed for the installing user, but not for another user so repair will install it. However you'd see this just once per new user.
There have also been VS setup project bugs that can cause this issue.
The documented way to prevent repair for files you want to remove after install is to null the Component Id for the file, something VS setups don't support so you need to do it with something like Orca or post-build MSI script. See ComponentId here:
https://msdn.microsoft.com/en-us/library/aa368007(v=vs.85).aspx
Note that the Windows Installer team recommends the MSI source be available anyway for a number of reasons, rule 31:
http://blogs.msdn.com/b/windows_installer_team/archive/2006/05/24/605835.aspx
Visual Studio Setup Project authors advertised shortcuts which is one of the mechanisms that MSI uses to determine if a repair is needed. It is detecting it is needed and attempting to do so but failing resulting in an infinite repair loop. Please read:
Windows Installer launches unexpectedly, for no obvious reason
This will help you identify which component is causing a problem. Unfortunately, VS Setup Projects are quiet limited and it's going to be difficult to fix this problem. I really would recommend a better toolset such as WiX, Advanced Installer or InstallShield.
The problem occurs when a windows user profile is created after installing our tool with the MSI installer.
When starting the tool with the new user, Windows wants to start the .msi file again.
(When the installation was run from a network path, Windows is then unable to find the installer)
The installation only installes 5 files (exe, dlls, txt) and creates a link on all users desktop.
Questions:
What is the reason why windows wants to run the installer again?
Is this the default behavior?
How can I prevent windows from starting the installer again with new users?
If this occurs when you click the shortcut, perhaps the advertised shortcuts have been created by the installation program and it tries to install the feature on demand. The differences between the types of shortcurts are described here. If it is your installation program you can try using non-advertised shortcuts in project. If you are talking about third-party software you can try creating your own shortcut for the installed executable.
Note that this repair to add the missing something should occur just once per new user to restore the data. If it happens more than that it's something more serious.
Even if you modify the shortcut, there is still the issue that if this new user (or any user) does anything that triggers a repair the same thing will happen. Repair is available from right-clicking the MSI file, and maybe from Programs&Features too. You really should keep the MSI file available.
If it's an accident that you didn't intend then why not just fix it? Look at the event log MsiInstaller event log entry, that might help. Also, Visual Studio may have added something that it thinks you need, like an extra HKCU registry entry - I believe that's been reported as an issue. You may find something in Orca or even in the setup project's UI in the HKCU registry.
I wrote an outlook addin with some basic functionality to access a webservice and execute methods on it. Everything works like a charm, except that I can't seem to get rid of the fact that users need admin rights to install this add-in. Google doesn't really seem to have the solution or answer for me,.
Is it possible to write an outlook addin (VSTO) which users can install without the need of admin rights?
Thanks a lot in advance!
It depends if you want a Per-User install or a Per-Machine install.
The main difference is where the registry keys are saved, under HKLU or under HKLM:
The other main difference is Per-User is set by default to install in the Users folder and Per-Machine is set by default to Program Files.
As #Aron mentioned certain prerequisites may require admin rights to install. If you know the client has the correct .Net version installed its possible. Otherwise you might need to resort to running the VSTO Add-In without .Net. Note: Microsoft Info path is written entirely in .Net so if users have the full office install, .Net 2.0 (maybe more recent depending on the version) should already be installed.
The easiest way to avoid the UAC prompt is to run the MSI not the setup.exe. Because the setup.exe is responsible for the downloadeding/installing components (such as dotnet). Running the MSI wont ask for admin.
Also note the MSI command line usage to see all the switch's (eg /quiet):
Start > Run > CMD > Enter
c:\Apps\App1\Release\app.MSI /?
I know this is really old, but there still isn't much help available this process.
One possible solution if your only goal is to share your project with someone and not specifically "install". I'm sure there are some issues with this method, but it is really simple, and so far it is working for my teams simple project. Additionally my team is not allowed internet access on their development machines and that complicates the standard publishing process.
Publish the project. (this is for VS2017 yours may be different)
Build the project. I built in release mode, but debug may work.
Publish the project.
Right click on your project in the solution explorer and choose
properties.
Select the publish tab.
make sure publishing folder location is "publish/" (or more generally a relative file path)
click publish now
Next we need to add it directly to someone's office program. You can add it directly by
opening options under the file menu
Go to the Add-Ins tab
Make sure "Com Add-ins" is selected in the drop down and click the "Go..." button
Once the dialog box opens click the "Add..." button
Navigate to "/bin/release/app.publish/" and choose the setup.exe file.
Restart the Office program.
Your vsto add-in should now be added in.
The answer is yes and no. In of itself, it is possible to install a VSTO plug in without admin rights via ClickOnce.
However, certain prerequisites may require admin rights to install (such as dotnet).
So in the general case no. But it maybe possible.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
What are the specific differences between .msi and setup.exe file?
I am working on an installer for a new version of my project (C#).
Previously, I've used Inno Setup to create .exe files for installing my projects on other computers in the workplace. While reading through some tutorials, though, I came across Windows Installer XML, which uses XML files to build a .msi installer.
My project will be available on a network share that all the employees have access to so they can install the software (I'm currently working on an update checker as well)
What are the major differences between .exe and .msi installers? Why would I want to chose one over the other? Would either make more sense given my specific environment?
I found some of the information at this question, but there was not a lot of information.
I wouldn't use WiX for a new project. I'd use an 'Installer Project' in Visual Studio to build an MSI. An installer project is much, much easier to put together.
Many exe installers are actually stubs or containers that hold an MSI, btw.
I guess you've checked out http://en.wikipedia.org/wiki/Windows_Installer?
MSI's give administrators the ability to restrict installs, rebase installs, change or add custom actions, automate installs/reinstalls/uninstalls, standard logging and switches. It just really integrates into a corporate IT environment ( http://technet.microsoft.com/en-us/library/bb742606.aspx ).
A custom installer may have many of those features, but that would depend on the installer package.
Most EXE installers available today are simply stubs to verify that the target machine has just enough support to launch an MSI stored within the EXE. They do basic windows version checking and Windows Installer version checking, then essentially invoke msiexec and let Windows Installer handle the rest.
For a very basic installation, the Installer Project in Visual Studio can get you by, but for just about any kind of real customization or tweaking you'll need a real MSI editor. We use WiX and love it - but it's a bear to learn. If you've got the cash you can invest in InstallShield - but that has it's own set of quirks.
MSI is configurable while EXE is not. I know this doesn't answer your question directly, but I thought I should point towards the ClickOnce technology.
MSDN: See example here.
Simply stated, a ClickOnce application
is any Windows Presentation
Foundation, Windows Forms, or console
application published using ClickOnce
technology. You can publish a
ClickOnce application in three
different ways: from a Web page, from
a network file share, or from media
such as a CD-ROM. A ClickOnce
application can be installed on an end
user's computer and run locally even
when the computer is offline, or it
can be run in an online-only mode
without permanently installing
anything on the end user's computer.
For more information, see Choosing a
ClickOnce Deployment Strategy.
IndigoRose's MSI factory is extremely powerful and much, much cheaper than InstallShield.
It uses WiX internally and allows you to modify the XML files in any way you like. The bootstrapper (.exe, if you add one) has a powerful scripting engine based on Lua to do... well anything.