We are developing an Outlook Mail Addin for our product.
When i debug the solution in Visual Studio my Office365 Outlook account opens and i can see the plugin i developed in the list of outlook plugins and i can use it.
The problem is that even after stopping the solution in Visual Studio i can still use the plugin. And when i re-run the solution it displays the cached version of the addin not the current version that i have in visual studio.
Looks like the addin is cached somewhere. Can't seem to stop it.
How can i solve this problem?
The add-in doesn't get cached, it always loads from the source location set in your manifest. During testing, when you build the solution the app gets deployed to the Mailbox you specify. However, the app can only run while your local web server is running. The add-in's tab will continue to be displayed, but if your web server has stopped it will fail when it loads - it should never load a cached version. You'll have to manually uninstall the add-in from the add-in page if you don't want it to run while you're not debugging.
Your browser is caching the files used by your add-in. If you deploy an updated version your browser will rely on the old files it still got cached. Deleting your browser's cache should solve the problem.
Related
After upgrading to Visual Studio Community 2019 [16.10.3] from [16.9.x] Chrome gets updated every time I save any javascript file. In my workflow it is annoying and does not bring my work any benefits. How to disable this feature?
I spent couple hours on searching the internet for the answer, but failed. It may be related to Hot Reload feature, but I still did not find an answer
I also want to disable this and what I found is that a javascript file named aspnetcore-browser-refresh.js is injected into the rendered page. The code in that file sets up a web socket to your web server which then allows the web server to issue a remote refresh of the browser. The browser refresh is triggered by something called dotnet watch, which is a process watching all the files in your project to see if any have changed.
You can read about it here: https://learn.microsoft.com/en-us/aspnet/core/tutorials/dotnet-watch?view=aspnetcore-5.0#run-net-core-cli-commands-using-dotnet-watch
Apparently this is a new feature in VS2019 for ASP .NET Core apps and is enabled by default.
HOW TO DISABLE
Go to Tools > ⚙ Options > Projects and Solutions > ASP .NET Core
Select Auto build and refresh browser after saving changes in Auto build and refresh option
I am currently working on an existing office 365 outlook add-in.
I'm not using visual studio but eclipse on a mac.
I simply need to do some debugging to check the response of an api call, so I added my debug code and deployed the add-in on the hosted server.
Then, from the Office Admin Center I re-upload the add-in making it available to all users.
The original problem was that the updated version of the add-in did not update straight away in outlook.
I left it for a day and today outlook was serving the updated add-in but then I had to add some more debugging code and once redeployed the new add-in version again was not served in outlook.
Thinking it was a caching issue I deleted all the browser cache (Local Storage, Session Storage, Cache Storage).
Unfortunately since then the Add-in is not loading at all returning an Add-in error:
Uncaught Function ContextActivationManager_getAppContextAsync call failed. ErrorCode is -2, exception: Failed origin check
from outlook-web-16.01.js
I tried to re-deploy it updating the version in the manifest but still no success.
I cannot really afford to waste another day to wait for the new version to kick-in so I was wondering if there is a faster way? Am I doing something wrong in deploying the add-in? Is there a reason why uploading a new version of the add-in it doesn't get served straight away in outlook?
RESOLVED. Apparently there is nothing wrong with the add-in deployment. I have spoken directly to the outlook support team and they said that if you are using the outlook web app the plugin takes time to become available because it goes through a release process.
So either use the desktop version of outlook or wait at least half hour before the plugin finally becomes available.
The error I mentioned earlier looks like it is not related to the add-in deployment.
We've created an Outlook add-in which integrates our custom CRM with Outlook. A command button is added to messages in read and compose mode. A function file is called on the button click.
The add-in manifest passes validation and installs properly on all machines. However on Outlook 2016 desktop (only) we are seeing an error on some machines. The exact error message says: “We’re sorry, we couldn’t access [NCS Outlook Add-in]. Make sure you have a network connection. If the problem continues, please try again later.” ([NCS Outlook Add-In] is the name of our add-in.)
Note that this message appears IMMEDIATELY after clicking the add-in command button. It does not first say “[NCS Outlook Add-in] is working on your request” like it add-ins do when an error has occurred.
We have tried Outlook logging and haven't found anything useful in the logs. We've checked settings and disabled other add-ins. We have also tested across machines with user accounts. The same user will have the error on one machine and not the other. In short, it seems that the error is machine specific and not profile related.
Version of Office 365 installed: 1705 (Build 8201.2209).
We experienced this exact behavior in Outlook 2016, the solution was to enable protected mode for the restricted and internet zones.
The easiest way to change this is in IE.
In Internet Explorer, click the Tools button, and then click Internet Options.
Click the Security tab, and then select the Restricted Sites Zone.
Select the Enable Protected Mode check box, and then click OK.
Restart Internet Explorer.
Here is a little more information:
https://support.microsoft.com/en-us/help/2761180/apps-for-office-don-t-start-if-you-disable-protected-mode-for-the-rest
Try this:
1) Close Outlook
2) Rename the folder C:\Users\%USERNAME%\AppData\Local\Microsoft\Outlook
to C:\Users\%USERNAME%\AppData\Local\Microsoft\Outlook.OLD
(Where %USERNAME% is current User Name.)
3) Start Outlook, Setup User Profile
4) Add/Test Add-In.
If that works, then something broken on old Outlook profile. But if same problem: Exit Outlook, delete the Outlook folder and rename Outlook.OLD back to Outlook.
I ran into this exact same problem after uninstalling Visual Studio 2015 on my development machine. (I had been using Visual Studio 2017 for Outlook add-in development.)
The problem went away as soon as I reinstalled Visual Studio 2017. The Outlook 2016 installation had nothing to do with the problem, I never changed Outlook or its profile at all.
This would indicate that the problem is somehow related to the SDK tooling on the machine...perhaps something to do with the .Net framework?
If I ran into this problem on a customer machine I would try reinstalling or repairing the .Net framework, or perhaps reinstalling Outlook (assuming it contains some add-in tooling that is broken.)
Just passing this on in case it helps anyone else.
I cannot get Visual Studio 2015 to attach remotely to my Azure site. Or, rather, it attaches okay, but no breakpoints are ever hit.
I've confirmed I'm publishing a debug build. I tweaked web.config to require that.
I've confirmed remote debugging support for 2015 is activated within the Azure portal.
The site launches fine after the attachment...just no breakpoints.
This is an MVC6 site using rc1.
For the sake of other people struggling with this, it turns out VS2015, even with all the latest updates, isn't "aware" of dnx running under Azure. So it attaches to the wrong process on the Azure site.
After doing "Attach Debugger" within Cloud Explorer or Server Explorer, you must go into Debug -> Attach to Process, and do two things:
change the qualifier so it points at the remote Azure site
manually attach to the dnx.exe process
The first step seems to get "remembered" by VS 2015. The second step most definitely does not; you have to do it every time you do a remote debug attachment.
Also, you need to refresh the site in your browser after doing all of this for the debug cycle to start.
Here's a link that explains this a bit more: https://blogs.msdn.microsoft.com/webdev/2016/03/21/remote-debug-aspnet-core-on-azure/
Try downloading cloud explorer here
attach debugger as below
Enable debugging setting in azure portal with visual studio version as below
Attach remote debugger to w3wp as below
5 Make sure Debug must be = true
Make sure you deploy application to azure in debug mode
This is a very strange situation that I am in; scratching my head for answers.
I have developed an outlook addin that works perfectly on my dev machine and on about 90 % of the clients machines.
The load behavior of the addin is 3.
On 10% of the users, outlook starts up without loading the addin despite the load behaviour being 3. The user can manually make the addin active by going to the addin manager on outlook but after a restart this addin reverts back to being inactive bbut load behavior never changes from 3.
I used Install Shield LE to package this addin. I don't even know where to debug anymore, I tried changing different load behaviour values but still the same outcome. The addin just won't load on startup with this set of users.
The company uses ZenWorks to automatically install the addin on all the PCs from the MSI i generate using install shield.
One weird thing is, If i go to the installation directory of the addin and install the addin using the .vsto deployment file, it works and gets loaded on outlook (but thats makes it two addins installed).
I also checked the Resiliency section on the registry and the addin isn't there.
I have faced this issue. To solve this, you need to manually delete the registry entries from the following path.
Open registry editor and go to HKEY_CURRENT_USER\Software\Microsoft\Office\Outlook\Addins\<Your add-in> and change the LoadBehavior to 3.
If the above registry entry is not found, then look for HKEY_CURRENT_USER\Software\Wow6432Node\Microsoft\Office\Outlook\Addins\<Your add-in> and change the LoadBehavior to 3.
Go to HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Outlook\Resiliency – remove the REG_BINARY keys found in DisabledItems and CrashingAddinList
where 15.0 is for outlook 2013.
If you are using 2010 outlook, replace 15.0 by 14.0 and for Outlook 2016 replace 15.0 by 16.0
Hope this helps.