Edit

Share via

Configure Office 365 API projects for distribution

  • Article

This page explains some steps developers should consider taking on their projects that leverage the Office 365 APIs prior to distributing them to other developers, their customers, or to source control systems such as Team Foundation Server, Git, or Visual Studio Team Services.

Specifically this page looks at two steps:

  • Fix the Azure AD Graph Client NuGet Package reference
  • Clean the web.config file for app-specific details

Fix the Azure AD Graph Client NuGet Package reference

All projects that leverage the Office 365 API SDKs by way of adding a connected service include a NuGet package that adds Office 365 and Azure Active Directory (Azure AD) references to the project created in Visual Studio.

The NuGet package added to the project by the Office 365 API Tools in Visual Studio is not present in the NuGet package registry, and therefore, attempts to perform a NuGet package restore fail because it cannot find a matching package.

Understanding the problem

The Office 365 API Tools for Visual Studio, version 1.3.41104.1, adds multiple NuGet packages to projects as part of completing the Add Connected Service Wizard. One package in particular presents a challenge: the Microsoft Azure Active Directory Graph Client Library.

The way Visual Studio works is that it, or add-ins, typically contain a local copy of the NuGet package so that developers do not always have to be connected to the Internet to download the NuGet packages. The package that the tools include has an ID of Microsoft.Azure.ActiveDirectory.GraphClient and a version of 1.0.22.

When projects are committed to source control, typically the packages are not included as part of the commit because they can add a lot of extra storage space demands and unnecessarily increase the size of a package when sharing it with other developers. Therefore, one of the first tasks developers do after getting a copy of the project from source control is to run NuGet package restore.

The challenge is that a package with the same ID and version does not exist in the NuGet package registry; there is no package with an ID of Microsoft.Azure.ActiveDirectory.GraphClient and a version of 1.0.22. The package does exist in the NuGet package registry, Microsoft.Azure.ActiveDirectory.GraphClient, but under different versions.

Fixing the Azure AD Graph Client NuGet Package reference

Until the Office 365 API Tools for Visual Studio are updated to fix this issue, we recommend that you alter the project prior to committing to your source control system, regardless if you are using Team Foundation Server, Visual Studio Team Services, Git, or any other solution.

After creating the project, look in the project's packages.config file and search for a package with an ID of Microsoft.Azure.ActiveDirectory.GraphClient and a version of 1.0.22. The safest way to update the project is to uninstall and then reinstall the package.

Open the Package Manager Console in Visual Studio and enter the following to uninstall the package:

  PM> Uninstall-Package -Id Microsoft.Azure.ActiveDirectory.GraphClient

Note

If the uninstall throws an error about not finding the package, simply remove the package reference from the packages.config file manually and save your changes.

Now, install the public version of the same NuGet package from the public registry:

  PM> Install-Package -Id Microsoft.Azure.ActiveDirectory.GraphClient -Version 2.0.2

Note

The previous example references a specific version of the Azure AD Graph client that is known to work with the Office 365 APIs. Future versions may work, so omitting the -Version argument is optional.

Clean the web.config file for app-specific details

The Office 365 API Tools for Visual Studio add the ability to create a new Azure AD application with the necessary permissions for the Office 365 APIs by using the Connected Service Wizard in Visual Studio. When completing the wizard, multiple entries and customizations are made to the project's web.config file.

These modifications include the following add-in settings:

  • ida:ClientID: The unique ID of the application created in your Azure AD tenant.
  • ida:Password: The Azure AD application's key that was generated by the Connected Service Wizard.
  • ida:AuthorizationUri: The endpoint used to authenticate with Azure AD.

The ida:ClientID and ida:Password are unique to the Azure AD app. Some development teams may elect for each developer to code against their own app, similar to how developers work against their own local development database. Therefore, you can think of the ida:ClientID and ida:Password as similar to database connection strings.

The next time a developer uses the Connected Service Wizard to create a new Azure AD application of the project, the wizard detects the ida:CliendID and tries to connect to an application in the current user's Azure AD tenant. If a match is not found, the Connected Service Wizard throws an error.

Therefore, prior to committing the project to source control or before sharing with other developers, we recommend that you remove the values from the ida:ClientID and ida:Password add-in settings in the web.config file.

See also