I'm using wix3 to build a setup file, I would like to know whether the outlook is running during the installation. If the outlook is still running, the setup should notify the users to close it or have to reboot after the installation.
I noticed that there is a feature can send a message to close the outlook directly, but that's not very friendly. I would like to knwo whether the FileInUse dialog can be called in such situation.
Thanks.
Related
I am currently having problems with the on-send feature on some desktop clients. I have implemented an addin but for some desktop clients emails are blocked from being sent. The email hangs and does not get sent. Is there a way to use on-send by disable for desktop clients. Can i do this in the manifest file or in powershell? Is it even possible to disable on-send for specific platforms. I want to configure my addin to never block emails. I suspect emails are blocked because event.completed() close as expected on some Desktop clients.
This is a new thing since the on-send never worked on desktop clients before. Now that it does...i have to deal with this bug somehow
There is no way to disable an add-in for just desktop clients. It is either enabled for all Win32, Mac and OWA, or off for all. This is true of all add-ins not just OnSend. Though previously this feature was not enabled for Desktop clients, it now is.
Note to unblock e-mails you should be calling event.completed({allowEvent:true}); (or false) to block e-mails. See: https://learn.microsoft.com/en-us/javascript/api/office/office.addincommands.event?view=word-js-preview
What is your scenario that you need to disable this for Desktop but NOT OWA?
You could also detect what platform you are on an change behavior of your add-in as necessary.
But the event.completed({allowEvent:true}); also have problem.
For example:
If I install a com app on Outlook then install an on-send add-in.
The problem is, if they both have simultaneous response on-send event. It will stack in an infinite loop.
As an add-in developer, the root cause looks like, event.completed({allowEvent:true}) not only end add-in but also send an 'send' event out. This will trigger a non self sending event response.
At a client of mine, in-house applications are all located on a network share. Users create shortcuts to the required applications from the network share so we can easily make sure everyone uses the latest version.
This works fairly well, although we often have an issue when users are still using applications when we'd like to release a new version. For most applications, we'd forcibly remove all the file locks on the server and release the new version. Not a very elegant solution, especially since we need assistance from another department for this.
For newer applications, I've developed a cleaner solution, where the application intermittently checks if it's still the most recent release. If it isn't, it shows a message to the user, asking him to quit the application at first convenience, or within 3 minutes. After 3 minutes, the application quits itself and all is well. However, some users will immediately try to re-start the application. The application will then show a simple MessageBox telling the user this version is currently not supported. My problem is this: while this MessageBox is visible, my executable is still locked.
I'm looking for any of the following solutions:
Releasing all locks on the current assembly files from within code
Showing a message box that lingers after the current assembly has exited
This is exactly precisely the problem that .NET ClickOnce deployment is meant to solve. Users have a shortcut they can click, the latest version is downloaded on application start, and there are no server-side executables to be locked if a user leaves their process open.
ClickOnce Deployment Overview
HowTo:Publish a ClickOnce Application
We have an application that can run as a Windows service (or as a user mode app). As part of it's processing, it launches a second executable that interacts with MAPI to read the contents of an MSG file. The executable is 32 bit. Office is 32 bit. So far, we've only tested using Outlook 2013.
This has worked fine for quite some time, but we've recently discovered a corner case where things do not work.
When we run as a Windows Service, and Outlook is not running in the user's session, then the application runs properly. However, if we launch Outlook, then MAPIInitialize fails with a return code of -7 (0xfffffffd).
I've tried calling with and without the MAPI_NT_SERVICE flag added (honestly, I can't figure out what that flag actually does), but it makes no difference.
So far in our testing, the Windows service account has been the same as the user logged into the Windows session that has Outlook installed - not sure if that might be important or not.
I can't for the life of me figure out how a process running under one session could interfere with a process running in another session.
I found this post a few minutes ago: https://social.msdn.microsoft.com/Forums/office/en-US/7a9cc40a-ffd6-4f83-9973-5410615b4df4/mapi-working-when-accessed-from-normal-application-but-not-from-the-service?forum=outlookdev
I'll give that a shot, but it seems super unlikely that this could be the issue (it's not like we do anything different with COM initialization, and certainly that wouldn't have anything to do with whether Outlook was running or not).
Can anyone point me in direction(s) to pursue this?
=============
More interesting information:
This appears to only happen with Outlook 2013. It definitely does not happen with Outlook 2010.
I have an outlook addin which is located on the network drive for all users to use.
When network fails may it be because of a cable that plugged out, or a system issue, if at that moment, the user launches Outlook (when no network is available), outlook automatically ticks off the addin out of usage.
For as long as the user doesn't enable it back, the add-in will not load. ever. you can close outlook , reopen it, it won't load the addin if it failed to find the .VSTO file once when outlook started.
Setting the registry value to never disable the addin, isn't effective here, because the addin is not realy disabled, its only been shut off and waiting to be reactivated manually.
I would like it to stop being shut off, or at least auto-enable it self when network is accessible. can this be accomplished without an 3rd party exe running in the background ?
Put the addin locally to each computer and equip those computers with simple script which runs on user logon and copies the addin from its network location to local directory. This will keep your addin both updated and always available.
In case if the network is inaccessible, it is the script (invisible to user), which will fail, not the Outlook. This makes a difference :)
Of course, besides the initial launch of the script, there are also possibilities to re-run it on regular basis (once a day?) when a user is logged on. This will be be effective only when Outlook is not running at the moment, otherwise the addin DLL cannot be overwritten.
It is not a good idea run from a network drive. Why not copy the dll locally when you install your addin?
Why not install locally and then write code to check the network location? If the network is available, compare the remote dll to the local one. If they are different, copy the new dll to the local machine, then adjust the registry entries for that addin. Then display a message to the user to restart the application.
I've been working on upgrading an application, and I've come upon two brick walls, although this question will only pertain to the first.
We allow users to add attachments from a web-based document service, so when the user clicks a button on one of the forms in our application, it opens up an instance of Forms.WebBrowser, which is essentially an IE wrapper. I've added a Value to the registry to make it run in IE8 compatibility mode, as this document service doesn't support IE7 compatibility mode (of which Forms.WebBrowser defaults to). This is the only change that I've made to the Forms.WebBrowser instance that I create.
When I open the WebBrowser, it instantly gives me a popup saying to install a plugin for the document service, of which I know for sure is already installed on my computer. I can click install or do not install, and it still appears to works fine. The problem is, this happens every single time I open the WebBrowser from the application, and I really don't want my users to come across this and become confused by what they have to press every time that they want to add an attachment from this document service.
Is there any way to make the WebBrowser reference the already installed plugins for my normal install of IE, or if this isn't possible, is there a way to automatically accept or decline the plugin installation (app is running in full-trust), or even a worst case scenario, can we make the Forms.WebBrowser block all popups, and just continue without the plugin?
Try using the ScriptErrorsSuppressed Property. It should disable all dialog boxes, not just script errors.