Finally ... how to debug the startup of a Windows Service application

Do what this guy says: http://einaregilsson.com/run-windows-service-as-a-console-program/

Pasted here for posterity, here's the example of how to write a Windows Service such that it can execute in a console and a developer can debug the startup routine:

using System;

using System.ServiceProcess;

 

public partial class DemoService : ServiceBase

{

    static void Main(string[] args)

    {

        DemoService service = new DemoService();

 

        if (Environment.UserInteractive)

        {

            service.OnStart(args);

            Console.WriteLine("Press any key to stop program");

            Console.Read();

            service.OnStop();

        }

        else

        {

            ServiceBase.Run(service);

        }

 

    }

    public DemoService()

    {

        InitializeComponent();

    }

 

    protected override void OnStart(string[] args)

    {

        // TODO: Add code here to start your service.

    }

 

    protected override void OnStop()

    {

        // TODO: Add code here to perform any tear-down

        //necessary to stop your service.

    }

}

WADK Deployment Tools on Windows Server 2008 giving error "The program can't start because api-ms-win-downlevel-advapi32-l4-1-0.dll is missing from your system"

Got this error at an extremely inconvenient time when trying to write some automation scripts for Windows Optional Features using the DISM module as part of the Windows Assessment and Deployment Kit running on Windows Server 2008 R2: "The program can't start because api-ms-win-downlevel-advapi32-l4-1-0.dll is missing from your system"

It turns out that the installer for this particular product isn't reliable when you uninstall and then reinstall the ADK. The problem turned out to be that the PATH variable hadn't been updated on the second install, so the PowerShell module that was invoking the DISM.exe executable wasn't able to find the required DLLs, even though they were in the same path as the executable. Go figure.

MSDeploy: The underlying connection was closed: An unexpected error occurred on a send.

Our company has started deploying all of its numerous web applications via automated (or at least scripted) deployment with MSDeploy. This has worked fine, up until very recently where one machine in particular seemed to be cursed and simply didn't want to work. Even when we nuked the VM and completely recommissioned it from scratch from our VM web server template, we still kept getting the following error:

Error: Could not complete the request to remote agent URL 'https://myserver:10987/MSDeployAgentService'.
Error: The underlying connection was closed: An unexpected error occurred on a send.
Error: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.
Error: An existing connection was forcibly closed by the remote host
Error count: 1.

The problem turned out to be caused by the fact that we hadn't correctly configured the Management Service for MSDeploy (even though we use a custom port for the MsDepSvc deployment service, the Web Management Service (WMSvc) wasn't correctly configured): 

1. Because we were behind a load balancer, we needed to specifically set the IP address of the server
2. We were attempting to use SSL, but we didn't have a certificate specified in the Management Service configuration.

Here's what our configuration looked like in the end, obfuscated to protect the guilty:

Step 1:

Step 2:

Managing MSMQ through PowerShell

There's a module for that!

Import-Module MSMQ

See the page on MSDN.

Creating an MSMQ queue administratively through the Windows Control Panel

To create a message queue

1. In the Control Panel, double-click Administrative Tools, and then double-click Computer Management.
2. Expand Services and Applications, and then expand Message Queuing. ...
3. Right-click Private Queues, and then click New.
4. Enter a name for the private queue, and then click OK.

See the link here on MSDN.

Enabling MSMQ in Windows via PowerShell

First, let's start off by seeing which Windows features for MSMQ are available in your installation:

Get-WindowsOptionalFeature -Online | ? { $_.FeatureName -like '*msmq*' }

If you see a message like "Failed to load program with incorrect format", double check that you're running a 64-bit version of PowerShell if your machine is running a 64-bit version of Windows.

Then, let's enable the ones we actually need:

$packageResults = @(Get-WindowsOptionalFeature -Online | ? { $_.FeatureName -like '*msmq*' -and $_.State -ne 'Enabled' } | Enable-WindowsOptionalFeature -Online -All -NoRestart)

$packagesRequiringRestart = @($packageResults | ? { $_.RestartNeeded })

if ($packagesRequiringRestart.Count -gt 0)
{
    Restart-Computer
}

This script takes the packages with MSMQ in the name, enables them along with any requisite parent features and prevents restart during installation. Once complete, we check the results to see if any installations require a restart. If there are any that require a restart, we restart the computer. As with anything else in PowerShell, and IT in general, use judgement and critical thinking.

IMPORTANT: The Get-WindowsOptionalFeature cmdlet and associated module are part of the DISM module. This module is available built-in with Windows Server 2012 and up. In Windows 7 / Windows Server 2008, it's available as part of the Windows Assessment and Deployment Kit available here. Even though the page says the installer is for Windows 8.1, it works on Windows 7 / Server 2008

Configuration a web application for Application Warmup in IIS

Further to one of my previous blog posts about how to configure an ASP.NET web application for Application Initialization (warmup), here's the follow up: a powershell script for configuring the corresponding IIS application for warmup:


<# .SYNOPSIS Sets the required settings in the applicationHost.config file for an application to be able to automatically initialize. .PARAMETER WebSitePath The name of the web application that's to have it's settings configured for application warmup. .PARAMETER RestartService A switch to indicate that the W3SVC (IIS) service should be restarted after the change. #> function Set-WebApplicationInitialization { [CmdletBinding(SupportsShouldProcess = $true)] Param( [Parameter(Mandatory = $true)][ValidateNotNullOrEmpty()][string] $WebSitePath, [Parameter(Mandatory = $false)][switch] $RestartService ) $pathElements = $WebSitePath.Split('/') $site = $pathElements[0] $appSubPath = @($pathElements | select -Skip 1) -join '/' $webApp = Get-WebApplication -Site $site -Name $appSubPath if ($webApp -eq $null) { throw "Failed to find application '$appSubPath' under web site '$site'" } if ($PSCmdlet.ShouldProcess($WebSitePath, "Update application to use Application Initialization settings")) { $appPoolPath = "IIS:\AppPools\$($webApp.applicationPool)" Set-ItemProperty -Path $appPoolPath -Name 'autoStart' -Value 'true' Set-ItemProperty -Path $appPoolPath -Name 'startMode' -Value 'AlwaysRunning' Set-ItemProperty -Path $appPoolPath -Name 'processModel.idleTimeout' -Value '00:00:00' $applicationPath = "IIS:\Sites\$($WebSitePath)" Set-ItemProperty -Path $applicationPath -Name 'preloadEnabled' -Value $true Write-Verbose "Updated properties for web application '$appSubPath' running on pool '$($webApp.applicationPool)'" if ($RestartService.ToBool()) { if ($PSCmdlet.ShouldProcess("W3SVC", "Restart web service")) { Restart-Service W3SVC } } } }

Building a developer test lab with Test Controllers and Agents in VSTS

Microsoft has recently released their DevTest Lab resources to production in Azure. This great functionality can let you quickly build up a lab where you can test your products and tear it down.

Steps:

1. Create an Azure Resource Group project in Visual Studio for managing your DTL.
2. Add a Virtual Network resource to the template
3. Add a DevTest Lab resource to the template
4. In the portal, bind the virtual network to the DTL in the Settings tab of the DTL
5. Create a Virtual Machine to host your software. Use a Formula to install any pre-requisites that you want on the machine: e.g. Chrome, Notepad++, etc.
1. As a pre-requisite for connecting to a vNext workflow, you **MUST** have the Azure PowerShell cmdlets installed on the machine as part of the Formula for the VM
6. On the virtual machine, open a PowerShell console and enable remoting along with adding a corresponding firewall rule to remove the local-subnet-access-only restriction that's set by default:
1. PS> Enable-PSRemoting
2. PS> Set-NetFirewallRule –Name "WINRM-HTTP-In-TCP-PUBLIC" –RemoteAddress Any -LocalPort 5986
3. PS> Set-ExecutionPolicy RemoteSigned
4. PS> dir WSMan:\localhost\listener\*\Port # show the port on which WSMan is currently listening
5. PS> winrm set winrm/config/Listener?Address=*+Transport=HTTP '@{Port="5986"}' # Change the port on which WSMan runs, option 1
6. PS> Set-Item WSMan:\localhost\listener\*\Port 5986 # Change the port on which WSMan runs, option 2
7. Configure the machine as per the tools here, which is essentially the same as the above steps, with some extra ones as well: https://github.com/Azure/azure-quickstart-templates/tree/master/201-vm-winrm-windows
7. From another machine, run the following to ensure that your machine is connectable:
1. Test-WSMan -ComputerName mymachinedns.westus.cloudapp.azure.com -Port 5986
2. $sessionOpt = New-PSSessionOption -SkipCACheck
3. $session = New-PSSession -ComputerName [myvmname].westus.cloudapp.azure.com -Credential (Get-Credential) -Port 5986 -UseSSL -SessionOption $sessionOpt

Forcing addition of the "this" keyword with ReSharper

I hate using underscores for representing members of a type. It's idiotic. If you need a prefix to distinguish your local variables from your members with the same name, there's a built-in way of doing it: the 'this' keyword.

"But ... that's more typing ... it takes longer" = > NO! IT FUCKING DOESN'T

1) Between Intellisense in your tools and automatic code formatters, it can actually take less when you apply the formatter regularly and share the settings with your team.

2) The underscore is harder to type, especially on a QWERTY keyboard (I use Dvorak)

If you use ReSharper, the Code Cleanup feature can fix this up for you in short order. As part of your cleanup profile, ensure that you select "Arrange qualifiers" in the settings.

PowerShell script to execute an Entity Framework Migration

I got sick and tired of coming up with hacks for including Entity Framework migrations as part of my deployment processes, so I came up with a much cleaner hack in the form of a PowerShell script that can be used to execute a database migration given an assembly and a connection string. This script does have one caveat though: for some reason if it's run more than once in a given PowerShell session, it causes a stack overflow exception, and I haven't been able to figure out why. I guess I'll have to leave it as an exercise to you. Have at it:

Param(
    [ValidateNotNullOrEmpty()][string]$assemblyFile,
[ValidateNotNullOrEmpty()][string]$connectionString
#    [ValidateNotNullOrEmpty()][string]$server,
#    [ValidateNotNullOrEmpty()][string]$databaseName,
#    [ValidateNotNullOrEmpty()][string]$userName,
#    [ValidateNotNullOrEmpty()][string]$password
)

$assemblyFolder = [System.IO.Path]::GetDirectoryName($assemblyFile)

$OnAssemblyResolve = [System.ResolveEventHandler] {
  param($sender, $e)

  # First load the assemblies already in our app domain
  foreach($a in [System.AppDomain]::CurrentDomain.GetAssemblies())
  {
    if ($a.FullName -eq $e.Name)
    {
      return $a
    }
  }

  $fn = Join-Path $assemblyFolder "$($e.Name.Split(',')[0]).dll"

  if (Test-Path $fn)
  {
      $ass = [Reflection.Assembly]::LoadFile($fn)
      return $ass
  }

  return $null
}

[System.AppDomain]::CurrentDomain.add_AssemblyResolve($OnAssemblyResolve)

Set-Location ($assemblyFolder)

[System.Reflection.Assembly] $assembly = [System.Reflection.Assembly]::LoadFile($assemblyFile)

$types = $null

try
{
    $types = $assembly.GetTypes()
}
catch [Exception]
{
    $ErrorMessage = $_.Exception.Message

    throw "Failed to load types from assembly"
}

$configurationType = [System.Type]::GetType("System.Data.Entity.Migrations.DbMigrationsConfiguration, EntityFramework")
$migratorType = [System.Type]::GetType("System.Data.Entity.Migrations.DbMigrator, EntityFramework")
$connectionInfoType = [System.Type]::GetType("System.Data.Entity.Infrastructure.DbConnectionInfo, EntityFramework")

if ($configurationType -eq $null -or $migratorType -eq $null -or $connectionInfoType -eq $null)
{
    throw "Failed to load entity framework"
}

$migrationConfigurationTypes = @($types | ? { $configurationType.IsAssignableFrom($_) })

if ($migrationConfigurationTypes.Length -ne 1)
{
    throw "Failed to find single migration type for Entity framework in the assembly to migrate, found $($migrationConfigurationTypes.Length) migration configuration types"
}

Write-Warning "If you see an error similar to 'Could not find a connection string named [connection string name] in the application config', try changing your DbContext descendent to use the DbContext('connection string name') constructor syntax instead of DbContext('name=connection string name'). This is a known bug in EntityFramework."

#$builder = New-Object System.Data.SqlClient.SqlConnectionStringBuilder
# Need to use psbase, otherwise these properties throw an exception
#$builder.psbase.DataSource = $server
#$builder.psbase.InitialCatalog = $databaseName
#$builder.psbase.UserID = $userName
#$builder.psbase.Password = $password

#$connectionString = $builder.ToString()

$configuration = [System.Activator]::CreateInstance($migrationConfigurationTypes[0])
$connectionInfo = New-Object $connectionInfoType ($connectionString, "System.Data.SqlClient")
$configuration.TargetDatabase = $connectionInfo
$migrator = [System.Activator]::CreateInstance($migratorType, @($configuration))
$migrator.Update()

Write-Host 'Successfully migrated database'

Using the OAuth 2.0 configuration of HTTP Client Connectors with Dell Boomi (useful for Azure PaaS Web Applications that use Azure AD)

My company recently started using Dell's Boomi platform to connect to some of our PaaS applications running in Azure that use Azure Active Directory for authentication. We had tried previously to get the OAuth 2.0 security settings on the HTTP Client Connector working to no avail. Due to some of the work we have coming up for which we really wanted to be able to use the OAuth 2.0 configured connectors, I decided to try again, and got it working. Here's what I had to do in order to use an HTTP Client Connector with Azure AD:

• PRECONDITIONS:
• Must have two Web Applications defined in Azure AD: client application AppC, and service application AppS
• AppC must be setup for the following:
• Have an App Key defined
• In the manifest, must set to true the following settings: oauth2AllowImplicitFlow, oauth2AllowUrlPathMatching
• On the "Settings" tab of your HTTP Client, do the following:
• "URL" => The URL of the API to which you want to connect (underneath AppS).
• "Authentication Type" => OAuth 2.0
• "Client ID" => The Client ID of an Azure AD **Web Application** registered in Azure AD, that has **ALREADY BEEN PRECONFIGURED FOR ACCESS TO YOUR SERVICE**. This can be copied and pasted from the Azure web portal AD application page for your application. This is the Client ID in the configuration page for AppC.
• "Client Secret" => The App Key (in Azure terminology) of the Azure AD **Web Application** registered in Azure AD to be used as a client application for your service.
• "Authorization Token URL" => The "OAUTH 2.0 AUTHORIZATION ENDPOINT" copied out of the Azure AD "Applications" tab in the Azure Management Portal. This is the App Key (at least one of them anyway) for AppC in the Azure AD Management Portal.
• "Access Token URL" => The "OAUTH 2.0 TOKEN ENDPOINT" copied out of the Azure AD "Applications" tab in the Azure Management Portal.
• Under the "Add Authorization Parameter" link, you'll need to add 2 parameters. Click on the "Add Authorization Parameter" link twice to add them. You'll need the following for parameters:
• "grant_type" => "client_credentials"
• "resource" => The App ID URI of the target Web Application registered in Azure AD acting as the service to which your client Web Application is connecting. This is the App ID Uri of AppS.
• In the Azure AD portal for your Client Web Application, you'll need to add the OAuth callback URL for your Boomi account to the "Reply URLs" list for AppC. e.g. https://platform.boomi.com/account/[companyaccountname-11X11X]/oauth2/callback
• At the bottom of the page, click on the "Generate" button next to the "Access Token" label. Boomi will now attempt to connect to Azure AD. To do this, it will open up a new web page and attempt to authorize, so ensure that you have any pop-up blockers either turned off or configured to allow platform.boomi.com to open pop-ups.

Implementing Application Warmup with IIS 7.5 on Windows Server 2008 R2

In order to be able to support certain features of some of our applications, we've found the need to enable application warmup. However, this isn't built-in to IIS 7.5, but rather it's available as the Application Initialization module provided by Microsoft. In order to get this working, you'll need to do the following:

1. Install the Application Initialization 1.0 module available from Microsoft here.
2. You'll need to edit the applicationHost.config file on your server to enable Application Initialization. To do this, you'll need to open the file at %WINDIR%\System32\inetsrv\config\applicationHost.config in your text editor of choice and make the following changes:
• Find the 'application' element that you wish to enable for Application Initialization, which you can do with an XPath similar to "/configuration/system.applicationHost/sites/site/application" and once found, set the preloadEnabled="true" attribute on the XML element. Add the element if it's not already there.
• While on the 'application' element, take note of the 'applicationPool' value, because that's the Application Pool in which the application runs. Find the configuration node for that application pool (XPath: /configuration/system.applicationHost/applicationPools) and then set the following attributes on the <add> element for the application pool and its child 'processModel' element:
• <add .... startMode="AlwaysRunning">
• <processModel ... idleTimeout="0">
3. In your application's web.config file, you'll need to add the following elements:

<system.webServer>
<applicationInitialization remapManagedRequestsTo="/InitializationProxyPage.txt" skipManagedModules="true" doAppInitAfterRestart="true">

            <add initializationPage="/Services/MyCustomService.svc" hostName="localhost" />

        </applicationInitialization>

        <directoryBrowse enabled="true" />
</system.webServer>

You'll need to have the "InitializationProxyPage.txt" file in the root of your web application.

4. Enable "Anonymous" authentication in the Authentication panel of your application in IIS. This is necessary so that the warmup page can successfully execute a GET request for your initialization page to kick off the warmup.

5. If you use the system.webServer/security/authorization or system.webServer/security/authentication sections in your web.config to control access to the application, you'll also need to add the following under the /configuration element as a sibling to the system.webServer element:

<configuration>
<location path="InitializationProxyPage.txt">
        <system.webServer>
            <security>
                <authorization>
                    <clear />
                    <add accessType="Allow" users="*"/>
                </authorization>
            </security>
        </system.webServer>
    </location>
</configuration>
This will grant explicit access to the InitializationProxyPage.txt file to all users (including the App Pool Identity user) so that application warmup is guaranteed to have access to that file and can bootstrap your services.

Troubleshooting the dreaded "The build directory of the test run either does not exist or access permission is required." error message in Microsoft Test Manager

Our company is starting to use the Microsoft Test Manager a lot more to manage our testing, both manual and automated. Additionally, we've recently started on creating some new Test Controllers and Test Agents with an exotic network configuration. On one of these new Test Controllers, I've started creating Lab test runs, and been getting the error message "The build directory of the test run either does not exist or access permission is required." When you Google this error message, you get what's described in this post on MSDN. In my case, this was the former problem: the account under which the test controller was running couldn't see the build folder.

After reading that last statement, you might say "well, why didn't you check to make sure that the drop folder was in the place it should have been ?". And, I did. Sort of. Due to our network configuration and aliases, my user could see it on the expected place at the alias in my portion of the network, but the user under which the Test Controller was running (not the tests themselves as configured in the Microsoft Test Manager, but instead the Test Controller software, they're not the same user) couldn't because we have some synchronization going on. Once I logged on to the machine on which the Test Controller service was running ** AS THE USER UNDER WHICH THE TEST CONTROLLER WAS RUNNING ** and went to the network alias myself, I could finally see that the synchronization between the locations on the network that had the same alias wasn't running and the build that I expected to be there was in fact not running.

Problem solved.

Migrating code in TFS from one Team Project to another Team Project within the same Team Project Collection

My company has frequently had the issue of moving code around within the same Team Project Collection as shifting desires and motivations for the organization of our code have swayed our company. Previously, we've used tools such as the TFS Integration Platform available on code plex. That project has its share of issues, namely that:
a) It was half baked to begin with
b) It's no longer maintained and doesn't work for versions later than TFS 2012.

Fortunately for me, thanks to a fortuitous Stack Overflow post, I've found the following script to recursively move the content of one folder to another folder, and it even works across Team Projects within the same collection (but not across Team Project Collections):

Param(
    [Parameter(Mandatory = $true)][ValidateNotNullOrEmpty()][string] $SourceFolder,
    [Parameter(Mandatory = $true)][ValidateNotNullOrEmpty()][string] $TargetFolder
)

Get-TfsChildItem $SourceFolder |
    select -Skip 1 |  # skip the root dir
    foreach {
        & "C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\TF.exe" rename $_.serveritem $_.serveritem.replace($SourceFolder, $TargetFolder)
    }

In order to run the script above, you'll need both Visual Studio and TFS Power Tools installed. When you install the Power Tools, you'll need to ensure that the PowerShell module is selected in the installation options. Also, because the path to the Power Tools PowerShell module isn't put in the PSModulesPath by default, you'll have to manually import the module into your PowerShell settings like so (before you run the script):

Import-Module "C:\Program Files (x86)\Microsoft Team Foundation Server 2013 Power Tools\Microsoft.TeamFoundation.PowerTools.PowerShell.dll"

Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://localhost:xxxxx' is therefore not allowed access

While developing an adal.js app with OData in IISExpress, I'm getting the following error:

Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://localhost:44315' is therefore not allowed access

Turns out the problem is that I needed to include the CORS package from Microsoft:

Install-Package Microsoft.AspNet.WebApi.Cors

Once that's in there, I also need to enable CORS using the 'EnableCors' extension method on my HttpConfiguration.

Using ADAL.js correctly with AngularJS when setting up your endpoints

When searching around and using the tutorials on how to correctly use adal.js to authenticate your calls to Web API (or anything else) in Azure, you'll often see a block similar to this that you have to put in your App.js to configure your main module:

adalAuthenticationServiceProvider.init(
{
tenant: 'mytenant.onmicrosoft.com',
clientId: 'abc4db9b-9c54-4fdf-abcd-1234ec148319',
endpoints: {
'https://localhost:44301/api': 'https://some-app-id-uri/'
}
},
$httpProvider
);

You'll notice that this appears to be pointing to the Web API root of a service running on localhost, and you'd be right. For this to work correctly, you'll need to enable OAUTH 2 path matching in the application manifest of the **client** that's connecting to the service!

Creating your own repository for PowerShell modules

Apparently it's quite easy, according to Microsoft. All you need is a slightly tweaked NuGet repository.

Running and debugging Azure WebJobs locally on your development machine

Check out this article: https://github.com/Azure/azure-webjobs-sdk/wiki/Running-Locally

It shows you how to locally run and debug Azure WebJobs, which as it turns out is extremely handy because you can interact with all the Queues, Tables, Blobs etc as you normally would and get a full debugging environment.

Updating your Azure AD Application Manifest

We've recently found that as we develop more applications in Azure, we need to put safeguards on the deployment of the applications to ensure that they're configured correctly. Part of this means editing the application manifests to ensure that certain settings are always enforced on certain applications. Here's what Microsoft has to say about updating Application manifests.

Bottom line, if you want to automate anything to do with manifests, you'll have to write your own application to use the Azure Graph API libraries to retrieve the manifest / application settings and edit them.

Properly invoking scheduled WebJobs

Recently we've found the need to start using Scheduled Azure WebJobs. However, the examples out there are all gargbage, even in the case where you can find an actual example using a scheduled WebJob rather than a continuous WebJob. So, for the benefit of anyone interested, including future me, here's the proper way to invoke a Scheduled WebJob in the entry point of the WebJobs assembly:

    /// <summary>

    /// The main entry point to the scheduled webjobs.

    /// </summary>

    public class Program

    {

        /// <summary>

        /// Main entry point for the scheduled webjobs

        /// </summary>

        public static void Main()

        {

            IKernel kernel = new StandardKernel();

            kernel.Load(new ServicesScheduledWebJobsNinjectModule());

            var jobHostConfiguration = new JobHostConfiguration

            {

                JobActivator = new ServicesScheduledWebJobsActivator(kernel),

                DashboardConnectionString = ConfigurationManager.ConnectionStrings["AzureWebJobsDashboard"].ConnectionString,

                StorageConnectionString = ConfigurationManager.ConnectionStrings["AzureWebJobsStorage"].ConnectionString,

            };

            var host = new JobHost(jobHostConfiguration);

            // Must ensure that we call host.Start() to actually start the job host. Must do so in

            // order to ensure that all jobs we manually invoke can actually run.

            host.Start();

            // The following code will invoke all functions that have a 'NoAutomaticTriggerAttribute'

            // to indicate that they are scheduled methods.

            foreach (MethodInfo jobMethod in typeof(Functions).GetMethods().Where(m => m.GetCustomAttributes<NoAutomaticTriggerAttribute>().Any()))

            {

                try

                {

                    host.CallAsync(jobMethod).Wait();

                }

                catch (Exception ex)

                {

                    Console.Error.WriteLine("Failed to execute job method '{0}' with error: {1}", jobMethod.Name, ex);

                }

            }

        }

    }

What the above does is the following:

• Configures the JobHost to use a dependency injection container via a custom IJobActivator implementation that, in our case, uses the Ninject dependency injection container.
• Configures the JobHost with a custom configuration so that we can control various items, including the connection strings for the dashboard and jobs storage.
• Starts the JobHost. This bit is important, because all the other examples out there neglect that this needs to be done.
• Dynamically resolves all schedulable methods that should be invoked, using the NoAutomaticTriggerAttribute built in to the WebJobs SDK. This attribute is used internally by the SDK to determine which methods need to be invoked manually (i.e. on demand) rather than by a continuous invocation used by Continous WebJobs.

Continuous Delivery of Azure Web Services

See this:

https://azure.microsoft.com/en-us/documentation/articles/cloud-services-dotnet-continuous-delivery/

Debugging Azure web apps on localhost

To get this working, you need to have an app registered with your localhost app root registered for the redirect URI and login URI. Here's the really important part of you're using AAD authentication:

You need to disable all forms of Authorization in IIS and enable Anonymous authentication for the application in the IIS manager on the web app itself so that Azure AD can take over the authentication!

Using adal.js and getting error AADSTS65001: The user or administrator has not consented to use the application with ID '....'

It turns out that you have to actually go in and give your javascript web client permissions to access the web api application in the Azure Active Directory management portal. Go figure.

Using adal.js and getting error AADSTS70005: response_type="token" not supported

I've recently started using adal.js with OData in an AngularJS 1.5 application and been getting this error with attempting to connect my client-side XHR requests to my Web API application.

Following the advice here, changing the AAD manifest of the AngularJS web client from this:

"oauth2AllowImplicitFlow": false

... to this:

"oauth2AllowImplicitFlow": true

... seems to have solved the problem.

Getting CORS requests working in Web API 2

I've just recently started playing with using adal.js to connect to Azure Active Directory for authentication so that I can set up an AngularJS => Web API scenario with OData connections.

I followed the page on asp.net here.

However, I'm still running into the following problem: // TODO

Getting the Active Directory cmdlets (for scripted and remote management of your Windows Server machines)

To get the cmdlets, you'll need to install the Remote Server Administration Tools, available here.

Alternatively, you can follow the instructions on this blog: http://www.itgeared.com/articles/1072-how-to-install-rsat-on-windows-server_21/

How to move a shelveset from one branch to another in TFS

You're going to have to start by installing the TFS PowerTools for TFS 2013 (or whatever version is appropriate for you). Once you have the powertools installed and the tools added to your PATH (if they're not already added by the installer), run a command similar to the following in the command line:

tfpt unshelve /migrate /source:"$/ProjectName/Branch" /target:"$/ProjectName/Targetbranch" "My Shelveset Name"

This will unshelve your shelveset into your new branch for you.

WARNING: Before you do this, make sure you're unshelving into a clean branch with no Pending Changes, otherwise you could inadvertently overwrite or otherwise lose important changes.

Retrieving the list of Service Principals in your Azure subscription(s)

Recently I found that I needed to grant certain users permissions in my applications, specifically I needed to put Service Principals into groups in order to grant them permissions in my application so that they can access protected data.

I found out that in Azure PowerShell, there's the module 'MSOnline', which contains the following pertinent commands:

Connect-MsolService:

Connects your current session to your MSOnline account

Get-MsolServicePrincipal:

Retrieves a listing of all of the Service Principals in your subscription(s)

Enabling manipulation of Azure Active Directory groups through Web Applications via the Azure Graph SDK

In your application(s) (plural if you're using a web / native application delegating to a Web Services API which is doing the actual work), you'll need to go into their pages in the Azure Active Directory management page. Once there, edit the permissions of the applications to include the following:

Under the delegated-to application:

• Under "Application Permissions", select:
• Read and write domains
• Read and write directory data
• Read directory data
• Under "Delegated Permissions", select:
• Read and write directory data
• Read and write all groups
• Read all groups
• Access the directory as the signed-in user
• Read directory data

Under the top-level application:

• Under "Delegated permissions", select:
• Read and write directory data 
• Read and write all groups 
• Read all groups 
• Access the directory as the signed-in user 
• Read directory data

Getting the SQL Server PowerShell tools

They're apparently not that easy to find. The SQL Server PowerShell Tools come as part of the SQL Server Feature Pack for their respective versions. You can find the SQL Server 2014 Feature Pack (along with the PowerShell Tools) here.

Querying PowerShell for module and cmdlet information

I've recently realized that it's of incredible benefit to start designing our systems such that they're open and easily queryable by any system, particularly .NET and PowerShell. As a result, I've started designing modules for PowerShell to let my team administrate our systems. This has led me to realize that they need some of the basics of PowerShell to query what's available to them, because none of them have really used PowerShell before. The following commands should be of help to beginners:

Show the currently loaded PowerShell modules: Get-Module

Show the available PowerShell modules: Get-Module -ListAvailable

Show the cmdlets available in a particular module: Get-Command -Module [module name]

* in the case of our custom compiled C# module assembly, this is the name of the assembly (not the name of the assembly file, e.g. MyCompany.MyAssembly, not MyCompany.MyAssembly.dll)

Accessing TFS via PowerShell

I'm ashamed to admit that only today did I find out that there are PowerShell cmdlets for TFS.

You can load them into a PowerShell session by executing this:

add-pssnapin Microsoft.TeamFoundation.PowerShell

Once that's done, you can get started with the following commands:

Get-Help Get-TfsServer

See this post on Hey Scripting Guy.

AADSTS90093: User cannot consent to web app requesting user impersonation as an app permission.

According to the Azure Graph API team's blog, they've changed the way permissions are handled in Azure AD-authenticating apps.

This error has been driving me nuts for the past month while I've been able to get into an app we're writing in Azure using AD, but my team hasn't.

Here's how we fixed our issue:
1) I could get into our app (because I setup the permissions with my account in the management portal), but my team couldn't.
2) Had to go talk to one of our DevOps guys who's a Global Administrator in our Azure tenant, got him to remove the permission in the Azure AD Application, then re-add it.

Now my team could get in.

Hope this helps anybody stuck on this

SqlPackage.exe fails to deploy to Azure with error "The database platform service with type Microsoft.Data.Tools.Schema.Sql.SqlAzureV12DatabaseSchemaProvider is not valid."

I've recently started trying to deploy to one of my own databases in Azure using SqlPackage.exe. I've used it numerous times at work without problem, but on my own system at home, I keep running into the following error:

"Internal Error. The database platform service with type Microsoft.Data.Tools.Schema.Sql.SqlAzureV12DatabaseSchemaProvider is not valid. You must make sure the service is loaded, or you must provide the full type name of a valid database platform service."

As it turns out, you need at least SSMS CU#6 to get a version of SqlPackage.exe recent enough to deploy to Azure with SQL Azure v12. The copyright on the SqlPackage.exe executable must be 2015 (or later). Such a version comes with the latest versions of SQL Server Data Tools (SSDT). If you're unable to use the version of SqlPackage.exe that comes with SQL Server 2014 because it's too old ("C:\Program Files (x86)\Microsoft SQL Server\120\DAC\bin\SqlPackage.exe"), you can use the version that comes with SSDT for Visual Studio 2013 ("C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\120\sqlpackage.exe").

Setting up continuous Webjobs in Azure

First things first: you need to properly setup your dashboard:

This means that in the 'Application settings' area of the panel for your Web app, you need to go into the 'Connection strings' setting and add blob storage connection strings with the names 'AzureWebJobsDashboard' and 'AzureWebJobsStorage', with a type of 'Custom'.

Second: if you have continuous web jobs associated with a Web app, you need to ensure that the Web app setting 'Always On' is toggled *on*.

Setting up delegated authentication between web apps in Azure Active Directory - quirks

When setting up your Azure App ID for your web apps, it's extremely important that you follow the recommended format of "https://<your tenant name>/<your app name>"

Otherwise, delegated authentication will NOT work!!

Using ADAL in Javascript to enable use of Azure Active Directory from an AngularJS SPA

Check this out, apparently it came out last fall in Azure:

http://www.cloudidentity.com/blog/2014/10/28/adal-javascript-and-angularjs-deep-dive/

Enabling group membership claims in delegated tokens in Azure Active Directory

In your application manifest, add the following to the root object:

{
   ....
  "groupMembershipClaims": "All",
   ....
}

Fixing redirect loops in Azure web apps that use Azure Active Directory for authentication

We've recently been using Azure Active Directory to handle authentication for a bunch of our Line-Of-Business applications that we're moving into the cloud. Unfortunately, we've been noticing that in some circumstances, we encounter redirect loops that the browser can't break out of and I've been scratching my head over it. As it turns out, the loops had a common cause: going to a URL in the application that started with http://.

Since we're all good programmers here ;), we always want to be using best practices and enforcing secure connections anyway, but it also turned out to be the fix: adding [RequireHttps] to the top of our filters list in FilterConfig.cs solved the problem and closed a security hole at the same time.

As for the initial cause: why would anybody be using HTTP anyway ? It turns out that HTTP is the default scheme for URLs in the Azure portal when you're viewing the settings for an application and people were clicking on those links to go straight into the app.

Alex

Parameterizing ApplicationInsights.config

I've been working on a lot of web applications in Azure recently, and we're using Application Insights to analyze logs and instrument events in the application. Additionally, we're using MSDeploy to deploy all of our applications as we're trying to get to the point of having Continuous Delivery on-premise. Because we use multiple environments, we need to use the parameters.xml file and SetParameters files to set parameters at deployment time, meaning that we also need to parameterize the InstrumentationKey used by Application Insights to determine which instance of App Insights gets the instrumentation for which application.

This is a bit of a challenge because the XPath support for the parameters.xml file is incomplete and leaves something to be desired. At first glance, I tried to use the naive XPath expression to parameterize our InstrumentationKey:

Match="/ApplicationInsights/InstrumentationKey"

I realized that this wasn't working after checking our deployments, so after some Googling, I found the recommendation that to parameterize an *element* rather than an attribute, you need to use "/text()" in your XPath expression (which makes sense if you know enough about XPath and XQuery). So I tried it:

Match="/ApplicationInsights/InstrumentationKey/text()"

Still didn't work. Then I was stumped for a while and let things simmer.

After a couple more hours and getting frustrated, it hit me: when parameterizing another element a few weeks prior, I ran into issues because a parent element of the one that I wanted to parameterize overrode the default namespace. I checked the ApplicationInsights.config file, and sure enough, the default namespace was the non-empty namespace. I had to use a wildcard to solve the previous problem, so I tried the following:

Match="/*/InstrumentationKey/text()"

Still didn't work, much to my surprise this time. After a little bit more Googling around, I found out that this time it was because the *root* element itself used a non-empty namespace, and overrode the default. I stumbled across this response by Vishal Joshi to a comment on one of his blog posts, which included a suggestion for it using something I didn't even know you could do with XPath (and I've actually got quite a bit of experience using XPath): use the local-name query operator to match only on local name rather than fully qualified name. If you're querying a document that uses an empty default namespace, they're both the same, hence why the simple match expressions work 99% of the time. Updating my query to this:

Match="//*[local-name()='InstrumentationKey']/text()"

... worked like a charm!

Creating users in a SQL Azure database

... is not as straight forward as you would think. It has some slightly different requirements for syntax than what you'd normally use to create users in a local or on-premise SQL Server instance.

You can see the tutorial page on MSDN here.

Logging your application with App Insights instead of Windows Azure Diagnostics

We've recently started deploying applications to Microsoft Azure. Unfortunately, we don't use Cloud Apps for our web apps, and instead use MSDeploy on the command line to enable automated deployment. Consequently, we don't have any .csdef files in which to implement Windows Azure Diagnostics (WAD).

Fortunately, there's a suitable replacement for applications in Azure App Service (rather than Cloud Services): Application Insights. Not only does this provide a TraceListener for tracing your application, but also provides a whole suite of other useful diagnostics, making this something that you should really be using anyway.  Using the links here and here, I was able to get up to speed with App Insights within an hour and a half, and implement a working solution for our application.

Using the Azure Key Vault: an experiment

So, I've found this article on MSDN about how to use the Azure Key Vault for storing secrets, e.g. encryption keys. Let's see how it goes.

**UPDATE** : So, apparently we won't be able to use the Key Vault because use of the key vault at this time requires that your application be used in conjunction with Azure Active Directory, which ours does not. That's unfortunate.

A really quick note about deploying SQL Server .dacpac files to SQL Azure

When you're using SqlPackage.exe to deploy a .dacpac to Azure, you must have access to the 'master' table in order for the tool to retrieve information necessary to create a diff of the database and deploy the differences during the Publish action.

For that reason, you need the 'sa' account, because simply having 'db_owner' on the Azure database is not sufficient.

Debugging database deployments with MSDeploy and SqlPackage

I recently had problems deploying a database to Azure, and thanks to this article, I now know why. The best part of this experience is that I've learned to debug this in a much easier manner than relying on the unhelpful error message:

*** An error occurred during deployment plan generation. Deployment cannot continue.
Failed to import target model my-database-name. Detailed message Value cannot be null.
Parameter name: conn
Value cannot be null.
Parameter name: conn

The short of it is that:

1) you need to enable a log trace with these commands for dbDacFx and SSDT:

logman create trace -n DacFxDebug -p "Microsoft-SQLServerDataTools" 0x800 -o "%LOCALAPPDATA%\DacFxDebug.etl" -ets

logman create trace -n SSDTDebug -p "Microsoft-SQLServerDataToolsVS" 0x800 -o "%LOCALAPPDATA%\SSDTDebug.etl" -ets

2) Go execute the command that's causing you grief
3) Execute the following commands to stop the logging trace:

logman stop DacFxDebug -ets

logman stop SSDTDebug -ets

4) Open 'eventvwr' in the Run dialog available from the Start Menu
5) Go to the right side 'Actions' pane, and click on 'Open Saved Log'.
6) When prompted to convert the log, click 'No'.

The logs will display under the 'Saved Logs' folder in the left hand navigation tree, and you'll be able to inspect the errors that occurred. Good luck with deployment!

Adding extra files to your MSDeploy web package with MSBuild

I've recently started getting much more in depth with Azure. I've ported some web apps up into Azure, and now I need WebJobs. I've written the jobs, manually uploaded them into my web apps, tested them out and they work great. Now I need to ensure that the WebJobs get automatically deployed with my Web Application.

As it turns out, web jobs are just a sub folder with some naming conventions underneath the App_Data folder in your web application. Unfortunately, getting those files into that folder as part of the packaging process is a couple extra (non-obvious) steps.

Following this article on ASP.NET, I was able to add in the extra files. It took a lot more Googling than I care to admit to in order to find this article. As it turns out, you really need to pick your search terms well.

My website doesn't accept my Active Directory credentials and just keeps prompting me over and over. Or if it's Chrome, just gives me a middle finger straight up.

Recently, I've been having the problem of trying to reach some of the internal applications that my company develops that uses Windows Authentication. Thanks to this article:

http://www.leftycoder.com/windows-authentication-chrome-iis/

... I found out why. I had to remove the option for 'Negotiate' with Windows Authentication. The settings had changed when we moved our applications to a new IIS Web Site. Something to keep in mind.

Bitten by IIS, or lack thereof

Here at the office, we build a number of web applications. I recently started refactoring one such application to change and improve how we deploy it. As soon as I made the change to the .csproj to remove some old configurations and add new ones, I mysteriously started getting this error on our build machine (and only our build machine):

C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\Web\Microsoft.Web.Publishing.targets (2664): Filename: redirection.configError: Cannot read configuration file

After examining the changes I made, I figured "there's nothing that should be causing this. WTF?" Then after a while, I went on to our build machine and found that we didn't actually have IIS installed on the build machines (which is a good idea from a security standpoint, because there's really no reason for a build machine to have IIS installed). So why did this start suddenly ?

I went and examined the exact line that was causing the problem in the targets file, and the only thing that appeared to be including this conditional statement was the flag 'IncludeIisSettings'. Sure enough, the old configuration which we never used before and were using now had this set.

A problem with redirect loops in IIS (8.5) with ASP.NET MVC 5 (and Identity)

Ever see something like this ?

http://localhost:80/MyApp/Account/Login?ReturnUrl=%2FMyApp%2FAccount%2FLogin%3FReturnUrl%3D%252FMyApp%252FAccount%252FLogin%253FReturnUrl%253D%25252FMyApp%25252FAccount%25252FLogin%25253FReturnUrl%25253D%2525252FMyApp%2525252FAccount%2525252FLogin%2525253FReturnUrl%2525253D%252525252FMyApp%252525252FAccount%252525252FLogin%252525253FReturnUrl%252525253D%25252525252FMyApp%25252525252FAccount%25252525252FLogin%25252525253FReturnUrl%25252525253D%2525252525252FMyApp%2525252525252FAccount%2525252525252FLogin%2525252525253FReturnUrl%2525252525253D%252525252525252FMyApp%252525252525252FAccount%252525252525252FLogin%252525252525253FReturnUrl%252525252525253D%25252525252525252FMyApp%25252525252525252FAccount%25252525252525252FLogin%25252525252525253FReturnUrl%25252525252525253D%2525252525252525252FMyApp%2525252525252525252FAccount%2525252525252525252FLogin%2525252525252525253FReturnUrl%2525252525252525253D%252525252525252525252FMyApp%252525252525252525252FAccount%252525252525252525252FLogin%252525252525252525253FReturnUrl%252525252525252525253D%25252525252525252525252FMyApp%25252525252525252525252FAccount%25252525252525252525252FLogin%25252525252525252525253FReturnUrl%25252525252525252525253D%2525252525252525252525252FMyApp%2525252525252525252525252FAccount%2525252525252525252525252FLogin%2525252525252525252525253FReturnUrl%2525252525252525252525253D%252525252525252525252525252FMyApp%252525252525252525252525252FAccount%252525252525252525252525252FLogin%252525252525252525252525253FReturnUrl%252525252525252525252525253D%25252525252525252525252525252FMyApp%25252525252525252525252525252FAccount%25252525252525252525252525252FLogin%25252525252525252525252525253FReturnUrl%25252525252525252525252525253D%2525252525252525252525252525252FMyApp%2525252525252525252525252525252FAccount%2525252525252525252525252525252FLogin%2525252525252525252525252525253FReturnUrl%2525252525252525252525252525253D%252525252525252525252525252525252FMyApp%252525252525252525252525252525252F

As it turns out, IIS can generate redirect loops whenever there's a freshly deployed (installed) MVC application that hasn't had its application pool correctly setup.

Just thought I'd put this here in case anybody else runs across it.

Getting started with Azure in PowerShell

As it turns out, Azure has a ton of cmdlets available in the PowerShell command line to help you quickly and easily manage aspects of Azure.

• Install the Azure PowerShell from the Microsoft Web Platform Installer
• Install the Azure AD Module from the links on this page.
• After installing the Microsoft Online pack, you may have to copy the 'MSOnline' and 'MSOnlineExtended' folders from 'C:\windows\system32\WindowsPowerShell\v1.0\Modules' to 'C:\Windows\SysWOW64\WindowsPowerShell\v1.0\Modules' if you're running a server version of Windows
• Open a PowerShell session as Administrator
• Run the command "Import-Module azure"
• Run the command "Import-Module MSOnline"

Here are some of the ones you'll need to get started:

• Add-AzureAccount -- Allows you to enter credentials and register your account with PowerShell so that you can manage it
• Get-AzureAccount -- shows you the currently active accounts
• Get-AzureSubscription -- shows the subscriptions available for the currently selected azure account

Also, to manage the roles in your Azure Active Directory, check out this page on Microsoft's Azure section.

Beginning in version 0.8.0, the Azure PowerShell installation includes more than one PowerShell module. You must explicitly decide whether to use the commands that are available in the Azure module or the Azure Resource Manager module. To make it easy to switch between them, we have added a new cmdlet, Switch-AzureMode, to the Azure Profile module.

When you use Azure PowerShell, the cmdlets in the Azure module are imported by default. To switch to the Azure Resource Manager module, use the Switch-AzureMode cmdlet. It removes the Azure module from your session and imports the Azure Resource Manager and Azure Profile modules.

To switch to the AzureResoureManager module, type:

PS C:\> Switch-AzureMode -Name AzureResourceManager

To switch back to the Azure module, type:

PS C:\> Switch-AzureMode -Name AzureServiceManagement

By default, Switch-AzureMode affects only the current session. To make the switch effective in all PowerShell sessions, use the Global parameter of Switch-AzureMode.

To start log streaming for a specific web application, use this command:
PS C:\> Get-AzureWebsiteLog -Tail -Name mywebsitenamehere

Getting access to roles and group claims in Azure AD using the Graph API

Check this link out. It contains a tutorial on how to get Roles and Groups in Azure AD, so that you can have a single code-base for checking roles and groups regardless of whether you're using Azure AD or on-prem AD.

Also check out this link to an Azure AD example on GitHub for getting Group access in your applications

Implementing delegated authentication from an Azure MVC web app to an Azure Web API web service

Follow the information on this tutorial. Contained within that link, is this tutorial on authenticating a web app with delegated user identity to a web API service.

Authenticating users on an Azure web site (MVC) using Azure Active Directory (AAD)

Follow this guide provided on Github. It provides all of the information you need to enable the simplest form of Azure AD authentication in an MVC app. It can be used as the beginning step to getting a fully authenticated MVC web app / web API stack.

Creating an Intranet MVC 5 application using Windows Authentication that connects to a separate Intranet Web API 2 application also using Windows Authentication

Recently I wanted to create an Intranet MVC application using Windows Authentication that connects to a separate, pre-existing Intranet Web API 2 web service that also uses Windows Authentication. In order to get the Windows Authentication of the MVC application propagated to authenticate with the Web API 2 web service, I had to do the following:

1) Place the following in both applications' <system.web> sections in their respective configuration files.

        <authentication mode="Windows" />

        <authorization>

            <deny users="?" />

        </authorization>

2) Update the .NET aspnet.config file located at "C:\Windows\Microsoft.NET\Framework\v4.0.30319\Aspnet.config" to change the following settings to the following values:

        <legacyImpersonationPolicy enabled="false"/>

        <alwaysFlowImpersonationPolicy enabled="true"/>

 3) In the code for the MVC app that wants to call the Web API 2 app, do the following:

            WindowsIdentity identity = (WindowsIdentity) this.HttpContext.User.Identity;

            using (identity.Impersonate())

            {

                searchModel.SearchResults = this.webApiService.FindWebApiItems(searchModel.SearchCriteria);

            }

This last bit is necessary to ensure that the currently authenticated user in the MVC app gets correctly propagated to the Web API 2 app. In the service that's mentioned in the code above, you'll also need to do the following for interacting with Web API 2:

4) Use the following to connect to Web API 2:

            HttpClientHandler handler = new HttpClientHandler

            {

                PreAuthenticate = true, 

                UseDefaultCredentials = true, 

                Credentials = CredentialCache.DefaultNetworkCredentials

            };

            using (HttpClient client = new HttpClient(handler))

            {

                string result = client.GetStringAsync(uriBuilder.Uri).GetAwaiter().GetResult();

                IList<MyWebApiModel> webApiModels = JsonConvert.DeserializeObject<MyWebApiModel[]>(result);

                return webApiModels;

            }

You should now have working code to propagate Windows Authentication via services.

As a side note, apparently there's also a way to change the settings so that you don't have to modify the global aspnet.config file, you can do it on a per-AppPool basis. The technique is described here, though I've never tried it myself.

A little gotcha with the Microsoft Task Parallel Library (TPL) Dataflow library

I've recently started using the Microsoft TPL Dataflow library in order to help improve the performance of some of our product's scheduled jobs. However, today, I ran into a little gotcha that's pretty important. When you're linking one block to another block, you must always ensure that the source block links to at least one target block that accepts its messages, otherwise it'll most likely deadlock!

Resolving "Could not establish trust relationship for the SSL/TLS secure channel with authority 'localhost'" in IIS with WCF web services

If you get an error that looks like "Could not establish trust relationship for the SSL/TLS secure channel with authority 'localhost'" in IIS while testing WCF web services, it most likely means that you haven't correctly specified the certificate for your service in IIS. If you're certain you've correctly specified the certificate, it most likely means that the IIS user doesn't have access to it, so you'll have to go in and manually grant permissions for it.

Removing a certificate binding from a port in Windows

As many people don't know, in Windows certificates can be bound to ports for securing content transferred over those ports. IIS happens to be particularly negatively affected by this if another program has a certificate bound to a port that you want to use, e.g. 443 for serving web pages.

Use the information at the following page to find the certificate binding and delete it :

https://msdn.microsoft.com/en-us/library/ms733791(v=vs.110).aspx

The short version:

Find the port: netsh http show sslcert | grep -C 5 443

This command will show all the SSL certificates that are bound to ports on your machine.

Delete the port: netsh http delete sslcert ipport=0.0.0.0:443

This should help deal with some of the more annoying (and less verbose) errors when doing things like trying to configure WCF services to use SSL.

Creating ChannelFactory instances that are configured with Custom credentials in WCF

Check this out: Setting Client Credentials

I just discovered this wonderful piece of information on how to properly create ChannelFactory instances in WCF for clients.

Using Ninject in an IIS-hosted environment to create a WCF service instance that's in a shared assembly (i.e. not the web application assembly)

Recently I wanted to create several WCF services for some of our internal applications and host these services in multiple different servers. There'd be no difference in the code between the locations where they'd be hosted. In order to avoid code duplication, I wanted to make these WCF services common and then just host them in the IIS applications. However, it's not as simple as creating a new (shared) assembly, creating the WCF service in that assembly and then sharing it between the different services. When I tried this, I ran into the problem where even though I specified the service in the config section:

<system.serviceModel>

         ....

</system.serviceModel> 

 

... it still wouldn't find my service and load it (I'm using Ninject as a dependency injection container for my WCF services).  They key to getting the shared services to be found and loaded properly was to create a .svc file in each of the services where the WCF services were shared, and it looked something like this in each case:

<%@ ServiceHost Language="C#" Debug="false" Service="MyWcfSharedServices.MySharedWebService" Factory="Ninject.Extensions.Wcf.NinjectServiceHostFactory" %>

After adding the .svc file and using the path to it in the system.serviceModel configuration in the configuration file, everything worked perfectly.