When developing an office add-in, some times my local development environment causes issue when attempting to work with Windows Desktop versions of Office (Outlook, Word, Excel, PowerPoint). What could be working one day will tomorrow have Office saying “We can’t open this add-in from localhost”.
We can’t open this add-in from localhost. Click “See Details” for more information.
There are two things you may need to do:
Enable local loop-backs Install and allow the self-signed certificate Enable local loopbacks Edge Web Viewer will need to allow loop-backs.
This post contains articles to help study MS-600: Building Applications and Solutions with Microsoft 365 Core Services which is the only exam needed to become achieve the Microsoft 365 Certified: Developer Associate certification. Additionally it can be used to help your organization qualify for the Application Development Microsoft Partner competency.
Here is what is currently being tested along with articles that can help:
Implement Microsoft Identity (20-25%) Register an Application
Previously, I have discussed things that weren’t so clear to me when implementing Application Insights distributed tracing. There was another thing that I came across but thought it was worthy of a post on its’s own.
Simply put, it is that Azure Storage Queues cannot effectively pass on telemetry information. Look at Service Bus instead.
With Azure Functions, we use queue-based triggers to run non-immediate tasks within or in-between services. These queues are all Azure Storage Queues, and they were chosen as that because they did everything we needed, and we can move to a different queuing or messaging tech when the need arose.
Previously I was tasked to ensure all of our micro-services were set up correctly with distributed tracing, although there were a lot of docs that mentioned the topic and gave some insight, none gave straight information on how it worked. Below details some things that would have made my job a lot easier if I knew them first up.
First thing: How it works Let’s say you have a website selling carbon paper.
Photo by jonathan Ford on Unsplash
One of the common issues among developers in our organisation is the notifications from Azure DevOps. We get so many that they often go unnoticed or ignored, which leaves others waiting for responses to a Pull Request. I have compiled up a few hints to help reduce the torrent that is Azure DevOps Notifications.
The problem with notifications By default, Azure DevOps sets up a series of global notification subscriptions that are the defaults for every user.
TL;DR: Azure Front Door’s Health Probes can cost you quite a bit.
Recently I built a nice little Azure Functions App that helped us do user acceptance tests at the time of a Pull Request. Then I went on a holiday to relax by multiple pools for a few weeks.
When I got back however, I see my Azure spend had significantly increased, and investigations showed it was around this Function App.
