Call us today to see how we can help you be at your best.
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.
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:
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.
A good walkthrough on how to set up build configurations can be found here: https://msdn.microsoft.com/en-us/vs2010trainingcourse_webdevelopment_topic4.aspx
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:
To further ensure security, the publishing profiles for each developer can be excluded from TFS. These files are located under the ProjectFolder\Properties\PublishProfiles.
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.
Sign up today to receive our monthly newsletter with tips, Microsoft funding availabilites, upcoming events and industry news.
Take advantage of this hands-on event that will guide you through Microsoft’s security tools and how to protect your business interests.
Sign-up to our monthly newsletter for valuable insights, workshops/events and funding available for your next project!