nugget.exe load Microsoft.Office.js
As of this writing this created a folder in the C:\Apps folder called Microsoft.Office.js.184.108.40.206. That was it. Simple. I then pulled over those files as a zip to the customer project a installed them.
NOTE: The NuGet version of the Office.js libraries are not necessarily the newest. The latest are always available on the CDN, however there is not a way to pull those copies down for a local version. The NuGet version is updated with each point release, but it will lag at some interval behind what is available on CDN.
It is sometimes tough to determine what is happening in a production environment and you need to get logging information from the add-in to see what is happening. How can you do that?
One way is to build a console.log() option into your add-in that looks for a Debug flag in the manifest. So, you will create two manifest, one that enabled Debugging and another than disables it. More on that in a bit. To start, here is the basic class I created in order to handle this:
To enable logging you will add the following code to your initialize:
Once initialized this will add a TEXTAREA to the bottom on the page where the log entries will be loaded. Additionally, it will place a “Copy To Clipboard” button at the bottom that when clicked will copy the contents of the TEXTAREA to the clipboard so that they can be forwarded to you as needed.
Once implemented and initialized, you can add a console.log() anywhere you want in your code to add an entry to the log. Now, how do you turn this on. What this is doing in initialize is to see if the debug flag is set in the Query String of the SourceLocation setting in the Manifest. To turn on debugging, you change the following line as such:
That is it. From this you will be able to share two manifests with your users/administrators. The first one will be your default production manifest and the second one can be loaded if you need debugging information from the add-in.
Recently while preparing an internal Chalk Talk on Office Web Add-in Development, a co-worker presented me with two links I had not seen before and I wanted to share them with everyone:
These Code Explorers are pretty cool in that they contain some common use code patterns that you might find useful in your projects.
Unfortunately, there does not appear to be one for PowerPoint and or Outlook yet. But the fact they are there for Excel and Word is pretty cool.
The EWSEditor tool has been around a while and is managed/developed by some of my co-workers that sit on the Outlook Developer Support Team. As I have been developing more and more Office Web Add-ins for Outlook, I have found knowing and using EWS to be a very important skill.
EWSEditor helps in this regard. It is a very powerful, full featured EWS test bed. To get started you download this and extract the contents of the ZIP to a folder. From there you launch it and from the File menu, click Next Exchange Service enter in your email address and then select password and click Ok. Then viola, you are connected:
Once connected, you can start browsing your mailbox using EWS. To get to your Inbox, for example, you select TopOfInformationStore and then select Inbox:
From there you can go to different folders and look at the items, properties, and values stored in your mailbox. It is quite handy to understand how these things are structured and stored.
Next, you can click Tools, EWS Post and test your EWS skills. What I did was entered in my information to connect to my server and filled it in as such:
I then entered the following XML:
<?xml version="1.0" encoding="utf-8"?>
<t:RequestServerVersion Version="Exchange2010_SP2" />
And when I hit run, I got a response you see above. It is that simple. And there are also lots of examples as well. If you click Load Example you will see a lot of XML SOAP requests you can test with:
Download it and give it a try.
First, let’s discuss the architecture and from an Outlook/Exchange perspective:
- First, you load your manifest on the Exchange server. The manifest is simply an XML file that contains pointers to your web site (on the IIS server).
- When you load Outlook Web Access and click the add-ins button, the Add-ins pane will appear and each application manifest you have loaded will appear in the list.
- When you click on one of the add-is, the task pane will load (in Orange) and your site (located on the IIS Server) will populate in the pane.
The problem arises when you have but ONE Exchange server or ONE developer account for development and test. Developers want to be able to debug the code they are working with which typically loads from the local instance of IIS Express (localhost). But testers need to be able to work with the latest release build to test.
So, how do you do this?
The key is in the Manifest file. If you open the Manifest file, you will see the <Id> field. This is the most important piece, but there are other areas you should/need to update as well. What you will essentially have is two copies of your manifest file:
The first file will use the default ID provided in the project, it should have a name like Developer Release and it will point to your localhost (this is default with the setup of a new Web Add-in).
<?xml version="1.0" encoding="UTF-8"?>
<ProviderName>David E. Craig</ProviderName>
<DisplayName DefaultValue="Demo Developer Release" />
The second file will have a different unique ID, a different name (like Tester Release) and it will point to your IIS website.
<?xml version="1.0" encoding="UTF-8"?>
<ProviderName>David E. Craig</ProviderName>
<DisplayName DefaultValue="Demo Tester Release" />
The real key is having different ID’s and publishing them separately. In Visual Studio the developers will have everything set as shown above (essentially leave everything as default). When they are ready to drop a build to the testers:
- Right-click on the Website project and click Publish. Follow the steps to publish the site to the Testers server.
- Right-click on the Manifest project and click Publish. Click the “Package the add-in” button.
- In the resulting dialog, enter the URL to the Testers site, This will ONLY update the URL, but not change the ID.
- Open the <manifest>.xml file in Notepad and then change the fields as shown above:
- Modify the ID
- Change the name so that you can identify which one is which
- Verify the URL is correct.
At this point you are ready to go. And you can create MULTIPLE versions of your manifest. If for example you need one for Testers, one for Developer and then another for Pilot and yet another for experimental testing (each pointing to different IIS instances, sites or even to the Cloud (Azure). You can create as many manifests as you need this way, have them all show up in the Add-ins task pane allowing the testers/users to select the one they wish to work with.
Ever since Office 2010, Excel has become more and more burdened with memory issues. The most common problems I have seen are hangs, crashes, errors about resources, and problems with cut/copy/paste. This has occurred more and more often with each subsequent build of Excel. The symptoms have become more apparent as Excel Spreadsheets have become more and more complex. Users have become more savvy with formulas, pivot tables, slicers, etc. And Excel has started using more and more memory to enable these features. The problem is 32-bit architecture on a system. Although application are supposed to have 4GB of memory, Excel is actually limited to 2GB where the system uses the other 2GB for shared process memory.
Now, there is a fix which makes Excel 2013 and 2016 “Large Address Aware.” This is a feature of Windows that limits memory for the system to 1GB, freeing up 3GB for Excel. This should help tremendously. Most of the problems reported with Excel usage should decrease as a result of this. For more information on this fix, see:
A requirement in an Outlook Web Add-in I am working on required the ability to send an email to an alias with another email as an attachment. I found this a bit challenging as the makeEwsRequestAsync() function limits us to only a handful of EWS functions (EWS operations that add-ins support). This means I was unable to use a lot of the samples I found on the web. However, with the UpdateItem method, I found a way.
First, let me say, I have been asked – why is easyEWS.js not on GitHub. Well, now it is:
Additionally, you can now reference the latest and greatest in your project at https://raw.githubusercontent.com/davecra/easyEWS/master/easyEws.js.
Next, so I updated the functionality in easeEws via two function:
- easyEws.getMailItemMimeContent – we use this function to get the MIME content of a specified mail item by the ID.
- easyEws.sendPlainTextEmailWithAttachment – this function, although a tad more complicated, will create a very simple plain text email and add an attachment send it and save it to the drafts folder.
Here are the two new updates:
Additionally, you no longer need to call initialize on easyEws. And you can simply add a reference to it in your HTML to always get the latest:
Once added, you can use EasyEWS.js on your projects. In my particular project, I used the following code, which does the following:
- Gets the current mail item (entirely) as a base64 encoded string. This is the full MIME representation of the message.
- It then creates a new mail item and sends it with a comment from the user to the email address specified with an attachment (which is the base64 string we got in the first step).
This is all done with EWS and because of easyEWS.js, it is done in very few lines of code: