Using global application host file in Visual Studio 2015+

In moving one of the projects from VS2013 to VS2015 I realized that IISExpress settings specified in the users applicationhost.config file got overridden. After a quick search, it came to me that another applicationhost.config file was created by the VS2015 and placed in the .vs/config folder under the root of my project.
This is, however, an undesired behaviour as I do not want to check in the source code the .vs folder, being that a bad practice also described by Microsoft itself. Files under the .vs folder are all files that you would never check in, since they are generated from a build or contain machine-specific information.

Then how to proceed with what concerns my applicationhost.config file?

There is a solution for this and it lies in a setting that is part of our project file. If you edit your web project .csproj file with a text editor, you should find a MSBuild property called UseGlobalApplicationHostFile. By default, the UseGlobalApplicationHostFile is specified and the value of it is not set, so you should see the following:

<UseGlobalApplicationHostFile />

As you can imagine from the property name, if set to true, it will indicate that for the project in question the global applicationhost.config file should be used, and that is precisely what we are looking for. Set this property to true:

<UseGlobalApplicationHostFile>True</UseGlobalApplicationHostFile>

Once it is set, we can see that our global applicationhost.config file (which is located in %USERPROFILE%\Documents\IIS Express\config\applicationHost.config) is again used and that my application can be launched for debug from Visual Studio correctly.

Job done!

Get Users SID with PowerShell

What is a User SID? It is user’s unique identifier, usually used in application to relate to a user in a unique way. Microsoft defines SID in the following way:

A data structure of variable length that identifies user, group, and computer accounts. Every account on a network is issued a unique SID when the account is first created. Internal processes in Windows refer to an account’s SID rather than the account’s user or group name.

Applications as TFS, MDS, etc use SID to relate to a user in their databases. For various reasons you may need to retrieve the SID for a given user in order to perform the desired operation. There are multiple ways of obtaining it, and what I do often see is leveraging the ActiveDirectory module in order to retrieve such a simple metric. Although ActiveDirectory module is a powerful it is an overkill for this particular task.
There is a much simpler way to retrieve it and that is by leveraging the .Net classes. Following is a call packed in a cmdlet.

function Get-UserSid
{
    [CmdletBinding()]
    param
    (
        [Parameter(Mandatory = $true)] [string]$Username
    )
    BEGIN
    {
        Write-Verbose "Entering script $($MyInvocation.MyCommand.Name)"
        Write-Verbose "Parameter Values"
        $PSBoundParameters.Keys | ForEach-Object { Write-Verbose "$_ = '$($PSBoundParameters[$_])'" }
    }
    PROCESS
    {
        if ($Username.Contains("\"))
        {
            $dl = $Username -split "\\"
        
            $domain = $dl[0]
            $user = $dl[1]

            $objUser = New-Object System.Security.Principal.NTAccount($domain, $user)
            $strSID = $objUser.Translate([System.Security.Principal.SecurityIdentifier]) 
            
            return $strSID.Value
        }
        else
        {
            throw "Username not in down-level logon name format (DOMAIN\UserName)."
        }
    }
    END { }
}

In case your computer is not part of a domain, you can just pass in as the domain parameter the host name.

This kind of information is relatively easy to find, I still wrote this as a reminder for myself.

Still, I hope it can help someone.