When we need to deploy an application to Azure from VSTS (Visual Studio Team Services), we use the Azure tasks prepared by Microsoft. These tasks require a contributor account in Azure AD to make changes to your subscription. As this account is not a regular user account but an application account we call it a Service Principal. A very basic build pipeline might look as follows:
The “Azure App Service Deploy” task is an example of a task that will use a Service Principal account to update your App Service in Azure. VSTS makes it easy to create the Service Principal account; it also automatically assigns a contributor role in your subscription to this newly created account. When you want to have full control over your Azure AD you may manually create an App Registration (another name for the Service Principal) in the portal and give it the required rights. You will also need a key to authenticate the service in Azure:
In the next step, you create a new Azure Resource Manager Service Endpoint, providing all the collected information:
Each build and release definition in TFS has a set of custom variables assigned to it. Those variables are later used as parameters to PowerShell/batch scripts, configuration file transformations, or other tasks being part of the build/release pipeline. Accessing them from a task resembles accessing process environment variables. Because of TFS detailed logging, it is quite common that values saved in variables end up in the build log in a plain text form. That is one of the reasons why Microsoft implemented secret variables.
The screenshot below presents a TFS build configuration panel, with a sample secret variable amiprotected set (notice the highlighted padlock icon on the right side of the text box):
Once the secret variable is saved, it is no longer possible to read its value from the web panel (when you click on the padlock, the text box will be cleared).
And this is how the output log looks like if we pass the secret variable to a PowerShell script and print it:
Let’s now have a look where and how the secret variables are stored.
In this post I’m going to show you how to diagnose SQL exceptions using memory dumps. Imagine you have a web application deployed on a production server. Your application is using Elmah configured to log all exceptions to a dedicated table. One day you receive information that users are unable to make orders and in the Elmah log there are lots of
SqlDateTime overflow. Must be between 1/1/1753 12:00:00 AM and 12/31/9999 11:59:59 PM.
at System.Data.SqlClient.TdsParser.TdsExecuteRPC(_SqlRPC rpcArray, Int32 timeout, Boolean inSchema, SqlNotificationRequest notificationRequest, TdsParserStateObject stateObj, Boolean isCommandProc, Boolean sync, TaskCompletionSource`1 completion, Int32 startRpc, Int32 startParam)
at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async, Int32 timeout, Task&amp; task, Boolean asyncWrite)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, TaskCompletionSource`1 completion, Int32 timeout, Task&amp; task, Boolean asyncWrite)
No more information available. If you are using NHibernate you may turn on SQL logging but, if you have thousands of users, this will have a negative impact on the application responsiveness. Another idea might be to use ADO.NET ETW logs – even though this way we will minimize the performance drop, it’s still not a perfect solution. ETW logs weigh hundreds of MB and contain a tremendous amount of information, which you need to filter and analyze. I plan to write about this type of logging in the future. For now, let’s take a third approach: create a production memory dump when the application breaks and analyze it locally in the debugger.
Few days ago I had a presentation in the Warsaw .NET Group about PDB files. To make the slideshow more attractive (or rather original:)) I decided to replace the PowerPoint with something more connected with the subject, such as… the Visual Studio debugger. The only question was how to actually achieve this. The idea grew in my head after reading a brilliant Mike Stall’s post about debugging dynamically generated code. Mike shows in it how to emit sequence points for a text file of your choice and so bind this file with the generated MSIL. If done correctly, the debugger will load the text file, allowing you to step through its content and at the same time execute the emitted MSIL. So what if we could use the presentation table of contents as our source file and for each title (line of the table of contents) emit MSIL which will present a corresponding slide in the console window? This will actually make the debugger play the role of the PowerPoint:)
Invalid session management is one of the common problems when using NHibernate and can lead to severe issues such as memory leaks or data inconsistency. In this post I am going to show you how to eliminate those pitfalls using the Visual Studio debugger. We will step through the process of opening and closing the session. We will also have a look at its properties in order to check if entities are correctly persisted. Let’s start then from breaking into the session open event.
Are you using NHibernate or other open-source library in your project? I’m pretty sure that you are. Have you ever wondered what’s happening “under the cover” when you call Session.Get or perform a query? You probably did. The problem is that usually all the external assemblies are stored in one directory (libs, packages, reflibs etc.) with no symbol files or sources. In this post I would like to show you how you can benefit from project’s ReferencePath property and debug the source code of your libraries at any time you want.
I’ve recently needed to remotely debug a .net desktop application with Visual Studio 2010. After having read the MSDN documentation on this subject I still missed some information. I hope that this post will fill some of these gaps and will help you configure and run the remote debugging tools.
Have you ever wondered where Visual Studio 2008/2010 stores the source files that it downloads from the source server? By default they are put in your home directory under Local Settings\Applications Data\SourceServer. If you are using two different debuggers or you have more than one user using your machine you probably would like to change this location. Unfortunately there is no way to do that through the options dialog. You are left with two options described below:
- through registry – by changing a value of the SourceServerExtractToDirectory key in the HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0\Debugger\ branch
- through options file – locate your Visual Studio settings file (its path should be displayed under Tools->Options->Import and Export Settings), then a tag: <PropertyValue name=”SourceServerExtractToDirectory”> and change it’s value to your desired cache directory
If you know any other way of changing this Visual Studio setting, please describe it in the comment.