Posted on:
Categories: Azure
Description:

​When working with multiple developers on a project there’s always the potential of stepping on each other’s toes unintentionally. When a configuration setting is changed, or maybe a package for the project is updated it could cause havoc for the other developers without anyone knowing what caused the issues.

Think of Source Control

Internally we use Team Foundation Server (TFS) for our source control with our projects. When developing web applications using Visual Studio and ASP.Net you can use NuGet to grab packages for your projects. This is very useful as it enables easier management for adding in references and components required for your solutions. Such as adding in the SharePointOnline CSOM or jQuery.

The issue that can arise from using NuGet and TFS, is that by default TFS will add all the files to source control. This can become a headache especially if developers are updating the NuGet packages at different times which can cause issues checking in changes as well as compiling your solutions.

To get TFS to ignore NuGet packages:

  • Add a file named .tfignore to the solution folder with the following content (This will tell TFS to ignore all the NuGet package files)

    \packages
  • Now create a folder under the solution folder named .nuget
  • In the .nuget folder create a text file named NuGet.config and add the following content
    <?xml version="1.0" encoding="utf-8"?>
    <configuration>
      <solution>
        <add key="disableSourceControlIntegration" value="true" />
      </solution>
    </configuration>
  • Now once you add your solution to TFS you won't have the future headaches related to NuGet packages!

Multiple Web Configs and Build Configs

By default, a web application project already has a couple build configurations set up with their own web configuration transforms created (Web.Debug.config and Web.Release.config). As we were building a SharePoint provider hosted Add-in with Azure hosting the web application there was a number of configuration settings required that were unique for each developer.

To simplify this a new build configuration was created for each developer for use during the development of the web application. To go along with these build configurations a new web configuration transform was added to the solution for each developer (e.g. Web.Dev1.config).

This enabled us to have all our unique settings configured separately, as well, these web configuration transforms could be excluded from checking in to TFS to ensure security of all our own Azure applications.

For example, the following web configuration transform enabled me to target my own Azure Redis cache, as well, store the client secrets for my SharePoint Add-in separately from the other developers.

<?xml version="1.0" encoding="utf-8"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
  <!-- My App settings -->
  <appSettings>
    <add key="ClientId" value="{GUID}" xdt:Transform="SetAttributes" xdt:Locator="Match(key)"/>
    <add key="ClientSecret" value="{Shared Secret}" xdt:Transform="SetAttributes" xdt:Locator="Match(key)" />
    <add key="ClientValidationEnabled" value="true" />
    <add key="UnobtrusiveJavaScriptEnabled" value="true" />
  </appSettings>
  <system.web>
    <customErrors mode="Off" xdt:Transform="Insert" />
    <sessionState mode="Custom" customProvider="RedisSessionProvider" xdt:Transform="Replace">
      <providers>
        <add name="RedisSessionProvider" type="Microsoft.Web.Redis.RedisSessionStateProvider" host="{my host}.redis.cache.windows.net" port="6380" accessKey="{my key}" ssl="true" xdt:Transform="Replace" />  
   </providers>
    </sessionState>
  </system.web>
</configuration>
   

A good walkthrough on how to set up build configurations can be found here: https://msdn.microsoft.com/en-us/vs2010trainingcourse_webdevelopment_topic4.aspx

Publishing Profiles

Last but not least was managing the publishing of our web application to our personal Azure App Services. By accessing the Azure portal and navigating to the App Service that is hosting the developing web application you can download the publishing profile directly from the …More menu in the Overview tab.

In Visual Studio, when you go to publish an Azure web application, you get prompted with a Publish Web dialog that allows you to import a new publishing profile. If you:

  • Right click your solution and select Publish you will get the Publish Web dialog
  • Select Profile on the left of the dialog
  • Now you can select Import under the Select a publish target menu
  • Just browse and select your publishing profile file and click OK
  • You will now be able to select that profile for publishing your web application to the target app service 

To further ensure security, the publishing profiles for each developer can be excluded from TFS. These files are located under the ProjectFolder\Properties\PublishProfiles.

Final Thoughts

By setting up the Visual Studio Solution and Azure Web Application project as described, we eliminated a lot of the headaches that can happen collaborating with multiple developers. This enabled each developer to just select their own Build Profile and then publish their web application with their own Publishing Profile easily.