Working on an outlook addin and I was wondering if manually replacing the compiled DLL on a target machine is sufficient when I decide to update my addin ? is that practice even valid for stability ?
on some minor changes i did to my addin for tests, It seemed to work, even without changing the manifest, or re-deploying but I'm not sure it will still work if the project changes from end to end - Like, is it possible to take a whole different addin dll, and simply place it instead of a dll that is already installed - and walla ? does its manifest even acknowledge the content of the dll or simply point to it?
is sufficient when I decide to update my addin ? is that practice even valid for stability ?
Theoritically, you can replace the add-in assembly with a new one. But the host application should be closed at that time to let you delete/overwrite an existing file. Be aware, the Trust center settings in Outlook can be adjusted to load only signed with a digital signature assemblies. In that case your add-in will not be loaded by the host applications.
Consider using ClickOnce for updating add-ins on the fly. See Deploying an Office Solution by Using ClickOnce for more information.
Yes, as long as you do not change the addin's class name.
Related
I am putting together a VSTO addin for MS Outlook. The addin is designed to utilize a unmanaged C++ library. Access to the library is via a C++/CLI (CLR) project. I am receiving a
File Not Found
error when running the ADDIN directly. It appears that the addin has difficulty with the associated unmanaged C++ library. The library is completely packed within the C++/CLI project and nothing using it requires knowledge of the unmanaged C++ library. The strangest aspect of this situation is that If I launch the ADDIN from Visual Studio all is loaded properly. I've validated that all libraries being used are where they are suppose to. It is unclear to me why the addin would fail to launch (when not being launched from Visual Studio).
Note: I validated this by running a test where I created a C++ library with one class and a C++/CLI library with one class that instantiates the class from the first library. I attempt to connect to the C++/CLI library from a VSTO project. I get the file not found error. I felt this was the simplest test to validate / determine what was happening.
Peter
Peter
The issue dealt with my making assumptions based on where things were placed. I had an installer that deployed the addin to the target deploy location. All files went into this folder. MY thinking was that if all the libraries are located within the same location they should all be found. This was based on the my thinking that an app runs and looks locally first for files. My mistake was that the app being run was Office Outlook - and it runs in a specific folder location. When I got the file not found I was thinking this can't be because the files are all together. BUT Office products when loading ADD Ins do not look in the location that the Add In is identified to be in (at leat for un managed DLLs - managed -- maybe different).
The end result was that the unmanaged DLL was not locatable because it did not show up in any of the seath locations of Windows. So the correct was to update the path to have the location of that add in. Which solved the issue of not found. What is annoying is that Visual Studio debugger -- looks to be working on the aspect of identifying DLLs where the application is being launched from. Which in general is fine -- except with VSTO the app being run is somewhere else -- but VS still looked in the project folder location to find the files. Making it somewhat unclear. This should not be occurring. VS debug should try or at least be configurable to operate in the context of the real world scenario. If it does -- I certainly was not able to find that configuration.
Peter
At this moment, I have a VSTO add-in fulfilling my requirement. But it needs to run with Visual Studio or installed. Ideally, I want to have a Word file containing this VSTO add-in and put this file on my server so that user can use my add-in just by downloading this file, no need to any extra work. Is it possible?
Any help would be appreciated.
A VSTO project must be installed, whether it's an add-in or a document-level customization. Installation ensures that the correct version of the .NET Framework and other pre-requisites are installed. It also includes the user explicitly trusting the solution.
If you want something that distributes with a document then you need VBA, embedded in the document and saved as a *.docm file. Note that this file type will trigger macro security - some people will have settings that won't allow VBA to run. Some will have settings that can allow "trusted" and/or signed projects to run (you can research that).
First let me get this stuff out of the way:
This happens with my own addin, as well as another third party VSTO add-in, so I don't think I'm doing anything incorrect
.net 4.0. VSTO runtime 10.0.50701
Windows 8. Also tried Windows 7
I am using the |vstolocal suffix in the HKLM registry for the addin
I have also tried adjusting the 'program files' paths in the registry here: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion to point to my new 'F:' location, and that didn't change any behavior
Here are the steps I'm taking:
Create a new volume on a separate disk other than C:. I called mine 'F:'
Add the program files structures F:\program files and F:\program files (x86)
Install your VSTO addin (I'm using Outlook but it will happen with Word too) to "F:\program files (x86)" instead of the 'C:' drive
Launch Outlook.
Result is this dialog:
According to this, I shouldn't be getting this since its an all users install (see the Inclusion List section):
Is this a Microsoft issue? I realize I can add to the Inclusion myself however then I would be subscribing to more of a per-user approach, and that seems like a bad approach. Is this coming up because anything other than the 'real' program files folder cannot really be trusted by VSTO loader?
The dialog window belongs to the ClickOnce installer. But the link goes to the Windows Installer section in MSDN.
It is up to you where to install the add-in, there is no need to use the Program Files folder.
Make sure that you did all the steps described in the Deploying an Office Solution by Using Windows Installer article. It describes all the required steps for creating add-in installers.
I recently went through the same thing, i got this when i just published the vsto from vs2015. I tried using installshield, yielded the same issues, eventually i switched to wix installer, now i don't have any update checks running and its a clean install. These are some customization updates and our client actually had a firewall blocking it so the install failed. Try wix it worked great for me. Hopefully you don't end up with my current issue of not seeing the add-in if i am not running outlook as Administrator, driving me nuts, good luck.
I have Autodesk Inventor 2012 and its SDK, including add-in creation wizards, installed. I have created an add-in project (in VB.NET), and used the code from SimpleAddIn sample provided. .addin file points to the location of dll output of the compilation.
However, i have run into a following problem. When Inventor loads, not a single breakpoint in the add-in Activate function is triggered. Moreover, when i call the list of add-ins, mine is shown in the list as not loaded, and however i flag it to be, it does not.
What could be the reason for this behaviour? How can that be fixed?
Well, I assume that you're using RegistryFreeAddins being deployed via Manifests...
From the fact that your AddIn is listed in the AddIn Manager, I conclude that the registration works, but the loading at runtime fails. This can have those main reasons:
Missing Dependencies (in case you use third party assembiles)
BadImageFormatException (your AddIn compiled in x86 and you have X64
Inventor installed, which you always have in case you've got a 64-bit
OS)
Have a look at your debug output in VisualStudio. Do you see any Exception Messages, that would relate to your AddIn? If not, you could try to activate the "Managed Debugging Assistants" in VS (especially for BadImageFormat- and FileNotFoundException(s)). Just google the above phrase to see how it's done.
Hope I could help :)
Are you targeting .Net 4? Inventor 2012 supports only .net 3.5 it seems. I ran into the same problem and changing to 3.5 made my plugin load correctly.
http://forums.autodesk.com/t5/Autodesk-Inventor-Customization/Registry-free-addin-won-t-load/td-p/3488178
if for a reason or another, the library load crash in the Activate procedure, you will not be able to debug the solution.
So, clean the Activate sub and keep only necessary calls and try again.
If it's still not working, just PM me the Activate procedure and I'll help you.
I am having some difficulties with installing an Excel addin at my client. I have created an installer for the addin using the instructions at http://www.clear-lines.com/blog/post/create-excel-2007-vsto-add-in-msi-installation.aspx, and it has been successful for the majority of users. The installer was run as an admin and this seemed to work ok. However for a small proportion of users the installation was unsuccessful - the registry entries are created but the addin does not load when Excel starts and does not appear in the addins list. Trying to add it manually from the installation folder gives an error that the addin is not valid.
To complicate matters slightly, the client uses both Vista and XP (although all installations of Excel are 2007). None of the XP machines have installed the addin successfully, whereas most (but not all) of the Vista machines have been successful.
Has anybody had any experience of this, or might be able to point out where I am going wrong?
Many thanks in advance,
Rob
There were changes to various user profile paths between XP and VISTA. If you've hardwired any paths like \Users\username\Application Data, etc, you may not be installing things quite right under XP, where the path would typically be \Documents and settings\username\Application Data.
Finally, if an addin isn't loading, about the only causes are
1) the reg entries pointing to it (or to the MANIFEST in the case of VSTO) either aren't there or aren't right.
2) the addin has some prerequisite or dependency that you've missed, and since it's not there, the addin loader is just failing to load the addin.
For 1), just check the reg entries for all the right values, then add a msgbox or some logging in your addin to verify that it is, indeed, at least being initially loaded by Excel.
For 2) I'd read up on the Fusion Loaded Viewer and use that. Fusion is the .net "loader" service, and it can be setup to log all sorts of detailed info about where it's looking for preqs, which one are found where, and which can't be located.
Details here
http://www.hanselman.com/blog/BackToBasicsUsingFusionLogViewerToDebugObscureLoaderErrors.aspx