• Skip to main content

Davton

Outlook development specialists

  • Home
  • About Davton
  • Blog

Technical

Changing the icon for an Outlook message

August 21, 2017 by davton

We were recently asked to change the icon showing in Outlook for messages when they had been filed to a CRM system.

The image below shows an example of the icons in Outlook. The top message has been forwarded and shows the icon for a forwarded message. The second message is a copy of the first, but the icon has been changed to one of the standard icons.

Updated Icon

It is possible to set the icon to one of the many pre-defined icons within Outlook. The full list of icons is shown below.

Outlook Icon Listing

In order to change the icon, the field PR_ICON_INDEX  must be programatically set to the value of the required icon.

This way, when a user has carried out a particular action on a message, the message icon can be changed so that the user knows it has been completed.

How to upload large email attachments to a CRM system

July 31, 2017 by davton

We recently came across a situation where an Outlook plugin we had built for a SAAS customer started reporting ‘System.OutOfMemoryException’ errors during the synchronisation routine.  The plugin was uploading emails and attachments to the SAAS CRM system via an API, which isn’t an unusual scenario for the systems we build, so we were slightly surprised. On closer examination, the errors were only occurring for large files (which in our case meant over 100Mb).

Typically when we need to upload files, we use ‘base 64 encoding’ and then upload them using http requests. There are other methods, but many servers expect base64 encoded data when uploading files. Below is a simple code for encoding the file to a base64 string.

 

 

Figure 1: Encode file to base64 string

However, with large files, the code above was giving us the  ‘System.OutOfMemoryException’ error, so we needed another solution.

Chunking the Data with a MemoryStream

Initially we tried the method shown below (Figure 2) that reads data chunk by chunk from the large file and writes that data to a MemoryStream.

Figure2: Encode file to base64 string and save it to MemoryStream

Up to a certain file size this method worked well, but when the file was more than 200Mb, we again got the same error. It turns out MemoryStream uses an internal byte[] buffer to store data. It initializes the buffer with a pre-set initial value, but if it reaches its limit, it needs to be re-sized. Instead of just grabbing a bit more memory, it creates a new buffer twice the size of the previous buffer, and then copies data from the old buffer to the new buffer. For example if the length of a buffer is 200Mb and new data needs to be written, .Net has to find another 400Mb block of data. So the total memory required is at least be 600Mb.

Back to the drawing board!

Using a FileStream instead of MemoryStream

We then looked at the FileStream class in the System.IO namespace. It helps reading from, writing to and closing files. While MemoryStream writes data to the internal memory, FileStream writes data to a file. (I guess the clue is in the name.)  As FileStream writes all the data to a file, there is no inherent memory limit, so using FileStream avoids the Out-of-Memory exceptions.

Figure 3: Encode file to base64 string and save it to file using FileStream

Uploading base64 encoded data to http Server

Now the base64 encoded data from the original file is saved in to another external file. It can then be read from the saved file and uploaded to the server using an http POST request (figure 4).

In this code, we can read the data in small chunks and can write these chunks to the request stream.

Figure4: Read base64 encoded data from a file and upload to http server

Summary

In this article, a large file is encoded to base64string and saved in a file using FileStream, then the source file is read chunk by chunk and written into the target stream. This is a good method for uploading very large files as base64 encoded data to a server.

Using Auth0 Integration with an Outlook Plugin

May 7, 2017 by davton

Davton have implemented a number of different authentication mechanisms as part of our work integrating SAAS applications with Outlook and Office 365, including oAuth, oAuth2, single sign on using federated Active Directory, and simple username and password. Recently we were asked by a customer to use a third party service called Auth0  which provides ‘authentication services’ as a service.

This article describes how we used Auth0 authentication with an Outlook plugin. (Note: Davton is not affiliated with Auth0 in any way)

Why do we need Auth0?

Davton integrates SAAS applications with Outlook. In this case, the Outlook plugin would upload to the SAAS application, the email address of the sender of specific emails. This information is communicated via an API – and the API requires a protocol to allow the Outlook plugin to be authenticated. One option would be to build in a username/password mechanism into the SAAS application. An easier solution is to allow the user to be authenticated by a third party application. That application is Auth0.

What is Auth0?

Auth0 is a third party (freemium) service which abstracts how users authenticate to applications or to systems. Developers can use the Auth0 authentication service for any programming language and on any stack to authenticate users to connect with the application. There are several methods that developers can use to connect users to the application using Auth0. They include.

  • Social network logins: Google, Facebook, Twitter, and any OAuth2, OAuth1 or OpenID Connect provider.
  • Custom credentials: username + passwords
  • Passwordless systems: Touch ID, one time codes on SMS, or email
  • Enterprise directories: LDAP, Google Apps, Office 365, ADFS, AD, SAML-P, WS-Federation, etc.

Figure 1 shows the mechanism of how Auth0 connects users with the applications.

Auth0 Mechanism

Auth0 provides Software Developers Kits (SDKs) for all major platforms such as .Net, PHP, Python, Java, NodeJS, android, IOS etc. It’s very simple and easy to create the integration to authenticate users to connect with applications using Auth0.

Auth0 Account

Before we begin development, it is necessary to create an account on the Auth0 service to use Auth0 authentication.We will need the details of this account later.

Creating a sample Outlook plugin which integrated with Auth0

This article describes how to integrate Auth0 in an Outlook plugin by creating a sample Add-in for Outlook. The details of how to create the add-in are beyond the scope of this article, so we will start from the point of creating a windows form which is displayed when we want the user to logon to the service.

Below we can see the Windows form which has been created to allow the user to login.

Windows Form

Adding Auth0 assembly for windows forms to the plugin project

After creating the windows form design we need to add the Auth0 assembly to the plugin project to create the Login button functionality.

Go to “Tools > NuGet Package Manager” and click “Manage NuGet Packages for Solution”. Then click on Browse and type “Auth0” in the search text box and select “Auth0.WinformsOrWPF” from the list of assemblies in search results (figure 8).

Install the assembly to the sample project.

Install the Assembly

After that double click on the Login button to add the functions to the Login button. – The picture below shows the code snippet for the Login button functionality which was given by Auth0.

 Code snippet

You can find further details on the auth0 web site here: https://auth0.com/docs/quickstart/native/wpf-winforms

Strongly-named key

At this stage you will need to refer to the account information for your Auth0 account. The  auth0Domain and auth0ClientId will be required in our code.

Important: Auth0.WinformsOrWPF requires a strongly-named key. Without a strong key for this assembly Outlook will fire an exception when we click on the ribbon button we created.

Please refer to “https://blog.devoworx.net/2014/03/13/signing-a-strong-key-to-an-existing-dll-that-you-dont-have-the-source-to-it/” for more information on how to sign a strongly-named key for Auth0.WinformsOrWPF assembly.

Add the Auth0.WinformsOrWPF assembly reference to the sample project after signing a strongly-named key for Auth0.WinformsOrWPF assembly.

Running the sample Outlook Plugin

When we compile and run our sample plugin, at the appropriate point, the plugin will display our windows form with the login request.

Click login to Authenticate using Auth0

Now we can click on the Login button to authenticate using Auth0 login form as follows.

We can either login using our username and password or we can sign up and then can login to the application using Auth0 authentication. Also we can login using our LinkedIn profile login too. All the validations are done in this authentication form of Auth0. We don’t need to do validations by ourselves. So if we logged in successfully we can see the following message in our windows form as follows.

Authentication Succeeded

Summary

So using these steps we can use Auth0 authentication for our Outlook plugin. One of the most important things is to sign a strongly-named key for Auth0.WinformsOrWPF assembly, otherwise we can’t implement Auth0 authentication in Outlook.

Finally I hope this article will be helpful for the developers who implement Outlook plugins using Auth0 authentication.

Written by Kasun Amarasinghe May 2017

How to pass Custom Actions to a WIX Installer using command line arguments

May 1, 2017 by davton

It is often desirable for an installer to be provided with specific data at the time of the installation. For example to supply a user name, password, license string etc. Passing command line arguments while initiating the installation process allows us to do this. This article gives you a detailed description about how to pass data to custom actions in a WIX Installer using command line arguments.

The installation process can be controlled using custom actions. Custom actions can be dynamic linked libraries, Visual Basic scripts or JavaScript files. A custom action written in C# will generate a dynamic linked library file (DLL).

Why use Custom Actions?

The installer provides many standard actions that execute during an installation. However, there may be times where your installation needs expanded functionality. In these cases, custom actions let you extend the capabilities of standard actions. We can use custom actions for the following scenarios.

  • Launch an executable during installation that is installed on the user’s machine or that is being installed with the application.
  • Call special functions during an installation that are defined in a – (DLL).
  • Use functions written in the development languages Microsoft Visual Basic Scripting Edition or Microsoft JScript literal script text during an installation.
  • Defer the execution of some actions until the time when the installation script is being executed.
  • Add time and progress information to a ProgressBar control and a TimeRemaining Text control.

Creating a sample project.

In this sample project, we tell the Wix Installer to use custom actions to execute an .msi with command line arguments. The example will create a sample installer for a Windows Form Application.

Start Visual Studio and go to “File->New Project” under the installed section select Windows Forms Application [Figure1].

Create a new project

Figure 1

Create an Installer for the application

Right click on the solution and “Add->New Project“.  Under Wix Toolset select Setup Project and add a new one. To install Wix Toolset, go to http://wixtoolset.org/releases/ download, setup and install [Figure2].

Add New Project

Figure 2

In the CustomActionSetup project, right-click on the References node and choose Add Reference.

Navigate to the Projects tab, click on the SampleApp project, and click the Add button, and then press OK [Figure3].

Set Reference

Figure 3

Create a Custom Action for the application.

Once we’ve created our setup project, we’ll need to add a C# Custom Action Project to our solution (you can see this project template option in the below screenshot as well).

To create a custom action, right click on the solution and “Add->New Project“. Under Wix Toolset select a “C# Custom Action Project” and add a new one [Figure 4].

 Create Custom Action

Figure 4

Here is the final Solution [Figure 5].

Figure 5

Edit Product.wxs in Wix Setup Project

After creating the setup project you’ll have a Product.wxs file that defines your setup. In the Product.wxs file, we can define custom actions and properties which are sent through the command line.

  • Define two properties “LIC” and “NAME”. See more on the Property Element in Wix here:

http://wixtoolset.org/documentation/manual/v3/xsd/wix/property.html

  • Binary tag a link to the DLL. Here you will need to give a source location for the dll with any unique ID value. When we build the installer, a custom action project (.CA.dll) is created in the bin folder.
  • In the CustomAction tag, you need to define which custom action you are using. In here refer to the “GetArguementValues” custom action and add the Binary Id to the BinaryKey property.
  • After that define the InstallExecuteSequence for a given custom action. Here specify in which step of the installation the custom action should be executed. See more on the InstallExecuteSequence here:

http://wixtoolset.org/documentation/manual/v3/xsd/wix/installexecutesequence.html

The screenshot below shows the location of these elements in the Product.wix file [Figure 6]

Figure 6

Custom Actions

Within the custom action project, you’ll have a new CustomActions class. In the CustomActions class define a method “GetArguementValues” which we have previously added to the “DllEntry” property in the product.wxs file. Here we get a “LIC” and “NAME” property through a Session object. A custom action can interact with an installing package through “Session objects”. The Session object controls the installation process by opening the installer, which contains the installation data. Finally show in a message box with two parameters [Figure 7].

Custom Action Class                                                             Figure 7

Pass Command Line Arguments to Wix Installer

You’ve most likely run .msi files simply by double-clicking them from Windows Explorer. However,you can also run an .msi file by typing the file name at the command line. The advantage of running from the command line is that you can pass parameters to the command.

Open a command prompt and ‘Run as administrator’. Figure [8]. To do this click the start button on Windows and search cmd, right click on command prompt and ‘Run as Administrator.

Run as Administrator

Figure 8

Using command line, we can run the .msi installer and pass parameter values which we define d in the Product.wxs. First go to the location where the  .msi file is saved. For this example it’s located in “C:\pro”. Then, using the command msiexec /i CustomActionSetUp.msi LIC=”xxxxxxxxxx” NAME=”davton”, as shown below, you can run the installer and pass the parameter values [Figure 9].

Command Line

Figure 9

When executing the command, it will open the install wizard and show the message box with the two property values being passed in the command line [Figure 10].

Command Line popup

Figure 10

Summary

This article provides information for creating a custom action in Wix, passing parameters to custom action functions and extracting parameters passed from an installer inside a custom action function.

Written by Tharaka Pathirana  May 2017

Web browser control in .net

November 14, 2014 by chathum

I recently needed to use a webbrowser control with an Outlook plugin – in order to display information hosted in a web application. The big problem is that by default, the .Net browser control emulates Internet Explorer 7. This is a big issue for web developers who want to create nice looking information for the browser control – and use the latest techniques. Regardless of which.net framework I used, the browser control was emulating IE 7 (seriously ?) So the poor web developers working with me had a hard time trying to support IE7.

I discovered you can force (emulate) a preferred Internet Explorer version using a simple registry mod. You can check this MSDN article for more information on how to do this. The best thing to notice is you don’t need admin rights for this.

HKEY_LOCAL_MACHINE (or HKEY_CURRENT_USER)
   SOFTWARE
      Microsoft
         Internet Explorer
            Main
               FeatureControl
                  FEATURE_BROWSER_EMULATION
                     yourapp.exe = (DWORD) 00009000

Since my code is required to run as an outlook plugin, the application runs inside outlook.  So I can’t use yourapp.exe, I always have to use outlook.exe if I want this done inside an outlook plugin. I started writing some code to do the this registry mod.
Microsoft.Win32.Registry.SetValue(@"HKEY_CURRENT_USERSoftwareMicrosoftInternet ExplorerMainFeatureControlFEATURE_BROWSER_EMULATION", appName, ieVer)
You can find the IE version by using this table  

Value Description
11001 (0x2AF9 Internet Explorer 11. Webpages are displayed in IE11 edge mode, regardless of the !DOCTYPE directive.
11000 (0x2AF8) IE11. Webpages containing standards-based !DOCTYPE directives are displayed in IE11 edge mode. Default value for IE11.
10001 (0x2711) Internet Explorer 10. Webpages are displayed in IE10 Standards mode, regardless of the !DOCTYPE directive.
10000 (0x02710) Internet Explorer 10. Webpages containing standards-based !DOCTYPE directives are displayed in IE10 Standards mode. Default value for Internet Explorer 10.
9999 (0x270F) Windows Internet Explorer 9. Webpages are displayed in IE9 Standards mode, regardless of the !DOCTYPE directive.
9000 (0x2328) Internet Explorer 9. Webpages containing standards-based !DOCTYPE directives are displayed in IE9 mode. Default value for Internet Explorer 9.Important  In Internet Explorer 10, Webpages containing standards-based !DOCTYPE directives are displayed in IE10 Standards mode.
8888 (0x22B8) Webpages are displayed in IE8 Standards mode, regardless of the !DOCTYPE directive.
8000 (0x1F40) Webpages containing standards-based !DOCTYPE directives are displayed in IE8 mode. Default value for Internet Explorer 8Important  In Internet Explorer 10, Webpages containing standards-based !DOCTYPE directives are displayed in IE10 Standards mode.
7000 (0x1B58) Webpages containing standards-based !DOCTYPE directives are displayed in IE7 Standards mode. Default value for applications hosting the WebBrowser Control.

I initially ran this code inside my outlook plugin but it didn’t give me what I actually want. When Outlook loads for the first time it checks the registry for this value and decides whether to use IE7 or not. So, doing the modification inside the application will only affect the version used once the application has restarted. I solved the problem by writing a custom action in the installer.
When researching this solution I came across this awesome website which tells you the current browser version. Of course you can write your own script to find this out.

Copyright © 2025 · Davton Limited

  • Home
  • About Davton
  • Blog
  • Privacy Policy