Azure Web App deployment fails to build class library project that uses C# 6 features

Update 2015-10-12: The Azure team resolved this issue last month, and you no longer need to perform the steps that follow.

With last week’s announcement that Azure Web Apps support .NET 4.6, I excitedly upgraded one my of solutions to .NET 4.6 and pushed the changes to my git repo. Unfortunately, there was a deployment error similar to the following:

CultureHelper.cs(19,20): error CS1056: Unexpected character '$' [D:\home\site\repository\Dev14_Net46_Mvc5.Common\Dev14_Net46_Mvc5.Common.csproj]

Failed exitCode=1, command="D:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe" "D:\home\site\repository\Dev14_Net46_Mvc5\Dev14_Net46_Mvc5.csproj" /nologo /verbosity:m /t:Build /t:pipelinePreDeployCopyAllFilesToOneFolder /p:_PackageTempDir="D:localTempf8ad415b-73f5-4460-8aea-9a9643c0590f";AutoParameterizationWebConfigConnectionStrings=false;Configuration=Release /p:SolutionDir="D:\home\site\repository\.\\"

An error has occurred during web site deployment.

You can read the full details in the issue I filed on Github, but basically if your web application project references a class library project that uses C# 6 features (in my case, string interpolation), Azure Web Apps will fail to build it during deployment. Luckily, there is a simple workaround. In your Web App’s Settings screen in the Azure Portal, add the following App setting:

App settings workaround

Or, in text form:


Kudos to David Ebbo and the Project Kudu team for a quick response, a workaround, and a permanent fix. (As noted in the Github issue, they still need to thoroughly test the fix before rolling it out, so in the meantime, you’ll need to apply the workaround.)

Upgrading RDLC schema from 2008 to 2010 in Visual Studio 2013

 Disclaimer: This worked for me, but as with all undocumented hacks, proceed at your own risk.

There may be a better way to do this, but I couldn’t find it. I trust that your .rdlc files are in source control, and that you can rollback to a previously working version if this causes problems.

For various reasons, I needed to upgrade my RDLC report’s schema version from the default 2008 version to the 2010 version.

When you create a basic, empty RDLC report in Visual Studio 2013, here’s what the namespace declaration looks like:

RDLC default schema

To coerce Visual Studio 2013 into upgrading the report’s schema to the 2010 version, do the following to your report:

  1. Open the Toolbox

  2. Drag an Indicator onto your report

  3. Save your report

  4. Delete the newly-added Indicator from your report

  5. Save your report

Or, in animated gif form:

Add and remove an Indicator

When you’re done, the report’s namespace declaration should look like this:

RDLC with 2010 schema

Hope this helps.

Azure WebJob with status “Never Finished”

I was a little confused as to why one of my Azure WebJobs had a status of “Never Finished”:

Never Finished

Fortunately, WebJobs have pretty good logging functionality that you can access from your Azure Website’s WebJobs Dashboard. In my case, I found the following entry:

[03/18/2015 14:43:00 > b46397: SYS INFO] WebJob is stopping due to website shutting down

Ah. Yes. In fact, I had updated the site’s configuration in the Azure Management Portal shortly after kicking off this job, so it was definitely a case of PEBCAK.

Hope this helps.

Ensuring a SQL Server column copies as text to an Excel column

The problem arises when you have a column with character strings that look like numbers. Looking like a number isn’t a problem in and of itself, unless the value starts with the character “0”. Excel will try to treat the column’s values as a number, and therefore eliminate any leading 0s.

The trick is to set up the column properties in the spreadsheet before you copy the values into it.

  1. Open a new Excel spreadsheet
  2. Find the column that corresponds to the SQL column with string data that looks like number data
  3. Right-click on the column and select “Format Cells…”
  4. On the Number tab, select Text as the Category
  5. Click OK
  6. Back in SSMS, select the top-right corner of the grid, then right-click it
  7. Select “Copy with Headers”
  8. In Excel, paste the data into the spreadsheet

Now the column should properly maintain any leading 0s on the strings-that-look-like-numbers.

(I rarely need to do this, but when I do, I inevitably end up searching online for the solution. May as well document it here so that I can find it when I need it.)

Authentication fails with access_denied error while using Microsoft.Owin.Security.Google 3.0.0

Just a quick tip:

If you’re trying to use Google Oauth 2.0 to authenticate users in your MVC 5 application, start with this tutorial:

Code! MVC 5 App with Facebook, Twitter, LinkedIn and Google OAuth2 Sign-on

When you try to log in using a Google account, you’ll get an access_denied error back from Google. To resolve the issue, read this blog post:

Changes to Google OAuth 2.0 and updates in Google middleware for 3.0.0 RC release

In a nutshell, you need to enable Google+ API access for your application from the Google Developers Console.

More info in this Katana Project issue.

Enumerating HttpModules: MVC Edition

About 6 years ago, I wrote a post about Enumerating HttpModules in ASP.NET. On my current project, I once again needed to view the loaded HttpModules, but this time in ASP.NET MVC. The code is very similar; it just has some MVC-isms and has been LINQ-ified now.

Here is the relevant code:

public ActionResult Index()
    // Get the modules for the current application.
    var modules = HttpContext.ApplicationInstance.Modules;

    // Convert the collection of keys to an IEnumerable<string>, and then use the keys to
    //  index into the list of modules to create a dictionary.
    //  * Key = module key name
    //  * Value = module full type name
    var loadedModules = modules
        .Select(moduleKey => new { Key = moduleKey, Module = modules[moduleKey] })
        .ToDictionary(m => m.Key, m => m.Module.GetType().FullName);

    return View(new HomeIndexModel(loadedModules));

And here is what the output would look like in the default ASP.NET MVC Bootstrap template:

Loaded HttpModules

The sample code is available on GitHub: EnumerateMvcHttpModules

Happy enumerating!

CSC : warning CS1685: The predefined type ‘System.Runtime.CompilerServices.ExtensionAttribute’ is defined in multiple assemblies in the global alias

In one of my ASP.NET MVC 5 projects that targets .NET 4.5.1, I noticed that I was getting a new compiler warning at build time:

CSC : warning CS1685: The predefined type 'System.Runtime.CompilerServices.ExtensionAttribute' is defined in multiple assemblies in the global alias

On a hunch, I fired up JetBrains dotPeek, loaded all of the assemblies in my bin directory, and did a Type search (Navigate -> Go to Everything / Type...). It turns out that Json.NET actually implements its own version of ExtensionAttribute:

// Type: System.Runtime.CompilerServices.ExtensionAttribute
// Assembly: Newtonsoft.Json, Version=, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed
// MVID: 2CCEAD7E-60D5-4E86-87A2-3819FCE6C567
// Assembly location: (redacted)\bin\Newtonsoft.Json.dll

using System;

namespace System.Runtime.CompilerServices
  /// <remarks>
  /// This attribute allows us to define extension methods without
  ///             requiring .NET Framework 3.5. For more information, see the section,
  ///             <a href="">Extension Methods in .NET Framework 2.0 Apps</a>,
  ///             of <a href="">Basic Instincts: Extension Methods</a>
  ///             column in <a href="">MSDN Magazine</a>,
  ///             issue <a href="">Nov 2007</a>.
  /// </remarks>
  [AttributeUsage(AttributeTargets.Assembly | AttributeTargets.Class | AttributeTargets.Method)]
  internal sealed class ExtensionAttribute : Attribute

Back in my web project, I looked at the properties for Newtonsoft.Json and noticed that the Runtime Version was set to v2.0.something. After reading through this Json.NET discussion thread on the matter, I decided to reinstall the NuGet package:

PM> Update-Package Newtonsoft.Json -Reinstall

And voilà! Newtonsoft.Json‘s properties once again showed that Runtime Version points to v4.0.30319, and the compiler warning went away. This modified my .csproj file, and diffing it immediately revealed the source of the problem. Newtonsoft.Json‘s hint path had somehow been set to this:


Instead of this:


Hope this helps.