There are many different reasons why you would want to deploy your builds from Visual Studio Online build system directly to your Azure VM. You might have test or staging environment running on Azure and you want to setup contentious integration build to run every time someone of you teammates checks something in. After each build run is finished it would be nice to for latest changes to be deployed automatically so that your test team can get latest version as soon as possible without you doing the deployment manually.
In essence we want to make WebDeploy profile for our application and instruct MSBuild running on Visual Studio Online to execute that profile once build run is finished. At the moment of writing this there are some improvements to this process on VS Online portal so you might check that out but my approach might be better for simpler use-cases.
Preparing your VM
It doesn't necessarily have to be Azure Cloud virtual machine, it could be machine running anywhere even your local on premise server as long as it is publicly accessible and running IIS Web Deploy agent. For sake of this example I will use Azure VM.
First we need to create Web Deploy Publishing profile for our application. In solution explorer right click on project you want to deploy and click on Publish.
When dialog pops up expand it by clicking on More Options to reveal Microsoft Azure Virtual Machines. From there you can pick up existing VM running on Azure or create new one.
From this dialog you can create new VM and make sure to check "Enable IIS and Web Deploy" because it will make configuration a lot easier. If already have your existing machine running here are detailed instructions how to enable IIS and Web Deploy. If you are creating new VM pay attention to Visual Studio Output window because this process can take some time.
Configure Build Process
Now that we have our machine ready for hosting and accepting our deployments it's time to configure our Build. Once again I will use Visual Studio Online Builds but same method applies if you are running Team Foundation Server on premise or even if you are just building your solution from command line manually or using scripts. Point is, whatever method for compiling your application you are using it will directly or indirectly run MSBuild in background and MSBuild can run our Publish profile as part of the process.
At the moment of writing creating build process directly in VS Online portal in browser is still in beta so I will do it from local Visual Studio. First make sure that you commit at least one version of your solution to source control because you will need it to define build process. It doesn't matter if you are using Team Foundation or Git VCS, VS Online Build will work with both.
Switch to Team Explorer and click on Builds. From top of the window choose "New Build Definition".
First step is quite self-explanatory. Leave it at enabled and give it some meaningful name. Give it some name that will clearly describe what application suite it is building, what configuration, how often (like nightly, CI etc.) because that list can grow over time.
On Trigger tab choose how you want your build to run. Manually, on each check in etc. I want to have continuous integration, meaning on every source code change application will get built and deployed to my designated environment.
Source Settings tab setts where your solution is to be found on VCS. Settings for Team Foundation Server and Git use different notation but Visual Studio should detect this step automatically if your code has already been committed (checked in) to VCS.
On Build Defaults tab you can leave everything by default.
Now we come to most important step of all. Build processing.
Items to build setting needs to point to your solution or project file. This will probably be detected automatically. If not just click trough. Under advanced settings you need to enter additional MSBuild Arguments. This is where we set our deployment profile. Remember that we could technically configure multiple publish profiles for one single application. We could make one profile for test and another for staging environment. We could also build in Debug configuration for test and Release for staging environment. Since I am deploying for test I use following command:
Settings are split with semicolon. Configuration is "Debug" in this case. PublishProfile is the name of publishing profile we set up in first step. You can find it inside application Properties/Publish Profiles.
It is the file with .pubxml extension. I found that "AllowUntrustedCertificate=True" and "VisualStudioVersion=12.0" are necessary for this process to work. Password had to be the one used by Web Deploy on your target server.
Hit Save and you should be able to see your new Build definition inside Visual Studio Builds in Team Explorer as well as in Visual Studio Online. Right click on it and then on "Queue New Build".
Your Build should kick of at this point and you should be able to see progress both in Visual Studio and VS Online Portal.
If everything went ok with the build your application should be successfully deployed to target environment. Double-clicking on Build in both VS and VS Online Profile allows you to see logs and eventually diagnose if something went wrong.
Deploying specific project in solution
There is a special case when you have two or more Web type projects in solution(Web Application, Web Site, Web API). Even though you define publishing profile in specific project in solution and it works if you publish using wizards and UI from Visual Studio it will not work from the command line and build systems for that matter. It will not know which project it needs to be deployed with that specific profile. To work around that you need to add custom Property Group inside .proj file of application you want to deploy.
Simple unload and edit your csproj file by adding something like following:
Then you add this custom property you defined in project to MSBuild configuration arguments list and set it to true.
Team Foundation server notifications are very useful for situations when you want to be notified about various changes to your project such as check-ins , work item changes, build completes or brakes.
Configuring notifications in previous versions of Team Foundation server required manual editing of Web config files of your TFS web service application. In 2010 version most common configuration tasks can be done through TFS administration console UI.
1. Configuring Email alerts on server side
Start up TFS admin console. test
Click on Application Tier tab and scroll down to Email Alert settings.
Click on Alert setting and enter details.
Even though your SMTP server doesn’t have to be on same domain as TFS box you can ran into trouble if your SMTP requires authentication.
Setup SMTP authentication details
If you try to use SMTP server which requires authentication you may run into following error found in Windows Server Event Viewer.
Detailed Message: TF271001: An error occurred while attempting to send an e-mail notification to the following address: firstname.lastname@example.org. Further e-mail notification errors that occur within the next five minutes might not be logged. Verify that the e-mail notification settings are correct in the Team Foundation Administration Console.
Exception Message: Transaction failed. The server response was: This server requires PTR for unauthenticated connections. (type SmtpException)
In previous versions of Team Foundation Server it was possible to configure TFS to work with SMTP user name and password, unfortunately IT IS NOT POSSIBLE TO DO DIRECTLY IN TEAM FOUNDATION SERVER 2010.
TEAM FOUNDATION SERVER 2010 DOESN’T SUPPORT SMTP SERVERS WHICH REQUIRE AUTHENTIFICATION.
Googling around I found that:
TFS does not directly support using a username and password to connect to an SMTP server but it is possible to work around this limitation by using an SMTP virtual server on the TFS AT. That virtual SMTP server can be configured to provide the authentication credentials that the “real” SMTP server needs when relaying messages. Please consult the following links for more details:
Apparently “TFS 2010 Background Job Agent” service, responsible for sending emails, has hardcoded line such as this:
smtpClient.UseDefaultCredential = true;
However, there is workaround for this issue you can found it on this blog post: http://blogs.msdn.com/b/buckh/archive/2006/07/21/smtp-username-password.aspx?wa=wsignin1.0
Basically you need to setup SMTP server which does not require username and password which will “relay” messages to your main SMTP server. You only need to setup SMTP relaying correctly.
2. Configuring Email alerts on client side
Fire up Visual Studio and connect to your team project.
Right click on your team project and then on “Project Alerts”.
Use this dialog to setup for which notification’s you want subscribe to.
To monitor your TFS notifications open Event Viewer, expand Custom Views and click on Application Events and look for Source=TFS Services events.
Additionally you can switch on logging and tracing of your TFS Job Agent by editing config file usually located on this path C:\Program Files\Microsoft Team Foundation Server 2010\Application Tier\TFSJobAgent\TfsJobAgent.exe.config.
Edit following lines under system.diagnostics:
<trace autoflush="false" indentsize="4">
<!--To enable tracing to file, simply uncomment listeners section and set trace switch(es) below.
Directory specified for TextWriterTraceListener output must exist, and job agent service account must have write permissions. -->
<remove name="Default" />
<!-- Trace Switches
Each of the trace switches should be set to a value between 0 and 4, inclusive.
0: No trace output
1-4: Increasing levels of trace output; see Systems.Diagnostics.TraceLevel-->
<add name="API" value="2" />
<add name="Authentication" value="2" />
<add name="Authorization" value="2" />
<add name="Database" value="2" />
<add name="General" value="2" />
<add name="traceLevel" value="2" />
Enter location for your log file and increase level from 0 to desired level of data in your log files.
Hope this helps
When using Microsoft Team Foundation Server from windows domain other than your current logon domain user will be prompted for logon details whenever new connection to TFS is needed.
This can be quite irritating, because every time you start Visual Studio same info has to be provided all over again.
I will give in next few lines short tutorial how to utilize Windows Credential Manager to store user name and password in order to enable Team Foundation Server automatic log on.
1. In control panel go to Credential Manager
2. Click on Add Windows credential
3. Fill in details with address of team foundation server (without protocol prefix), full qualified domain user name and password.
4. Click ok and you are good to go.
On next start Visual Studio should not prompt for user name and password. If there is ever need for any other user to login beside one added to credential manager , just removed previously added user to CM.
Hope this helps.