Tag Archives: asp.net

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

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:

MSBUILD_PATH=%ProgramFiles(x86)%\MSBuild\14.0\Bin\MSBuild.exe

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.)

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=6.0.0.0, 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="http://msdn.microsoft.com/en-us/magazine/cc163317.aspx#S7">Extension Methods in .NET Framework 2.0 Apps</a>,
  ///             of <a href="http://msdn.microsoft.com/en-us/magazine/cc163317.aspx">Basic Instincts: Extension Methods</a>
  ///             column in <a href="http://msdn.microsoft.com/msdnmag/">MSDN Magazine</a>,
  ///             issue <a href="http://msdn.microsoft.com/en-us/magazine/cc135410.aspx">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:

<HintPath>..packages\Newtonsoft.Json.6.0.3\lib\net20\Newtonsoft.Json.dll</HintPath>

Instead of this:

<HintPath>..packages\Newtonsoft.Json.6.0.3\lib\net45\Newtonsoft.Json.dll</HintPath>

Hope this helps.

Unable to start debugging on the web server

If you’re getting this error when trying to debug an ASP.NET Web application on IIS7 or greater, check the system.webServer element in your Web.config.  If you have the httpErrors element configured, you won’t be able to debug.  For your local dev environment, remove or comment out the httpErrors element, and you should be good to go.

<WAG>
From my ASP.NET 1.1 days, I have a hazy memory of Visual Studio’s debugging startup process requesting a bogus URL on the target Web site, and then doing something with the 404 response prior to launching the debugging session.  Obviously, if it’s expecting a 404 or the page to contain certain text, redirecting to an error page will prevent you from launching the debugger successfully.
</WAG>

If you happen to know specifically why this happens, please leave a comment (or contact me if comments are closed), and I will gladly update this entry.

"HTTP Error 401.1 – Unauthorized" when using Windows Authentication on IIS7.5

You may have run into this error while trying to develop a site that uses Integrated Windows Authentication on Windows Server 2008 R2 with IIS7.5.  I sure did, and I beat my head against the wall for a couple of hours trying to figure it out.

It turns out to be a security mechanism built into Windows, and the workaround is simple.  Just choose one of the two methods listed in this Microsoft KB article:

You can find a more detailed explanation here:

Hope this saves you some time.

(h/t to this ServerFault.com question/answer: IE 8 Authentication Denied on local SharePoint Site)

Another code snippet of the day

Today’s a good day. Check this out:

private static Dictionary&lt;string, string&gt; _dict = new Dictionary&lt;string, string&gt;();

static MyPage()
{
    //_dict.Add(&quot;item1&quot;, &quot;val1&quot;);
    //_dict.Add(&quot;item2&quot;, &quot;val2&quot;);
    //_dict.Add(&quot;item3&quot;, &quot;val3&quot;);
    //_dict.Add(&quot;item4&quot;, &quot;val4&quot;);
}

private void InitDictionary()
{
    try
    {
        _dict.Add(&quot;item1&quot;, &quot;val1&quot;);
        _dict.Add(&quot;item2&quot;, &quot;val2&quot;);
        _dict.Add(&quot;item3&quot;, &quot;val3&quot;);
        _dict.Add(&quot;item4&quot;, &quot;val4&quot;);
    }//END TRY
    catch
    {
        _dict.Clear();
        _dict.Add(&quot;item1&quot;, &quot;val1&quot;);
        _dict.Add(&quot;item2&quot;, &quot;val2&quot;);
        _dict.Add(&quot;item3&quot;, &quot;val3&quot;);
        _dict.Add(&quot;item4&quot;, &quot;val4&quot;);
    }//END CATCH
}

So what happened here? The guy decided that initializing the static dictionary variable in the static constructor wasn’t good enough, and that he needed to do it on every page request, so he created an instance method to do the initialization. For some reason, though, he kept getting an exception when initializing the dictionary after the first page view. Hmm… bettter just swallow the exception, clear the dictionary, and try again.

*slaps forehead*

Code snippet of the day

Just ran across this awesomeness today:

string campaignId = null;

/* ------------------------------------------------------------------------
 * see if the campaign id is in the request query params, so that a default
 * based on the url can be set.
*/
foreach (object key in Request.Params)
{
    string objCampaign = Convert.ToString(key);
    if (string.Compare(objCampaign, &quot;campaignid&quot;, true) == 0)
    {
        campaignId = Request[Convert.ToString(objCampaign)];
        break;
    }//END IF
}//END FOREACH
/* ---------------------------------------------------------------------- */

Huh. Well, that’s one way to do a Request.QueryString[“campaignid”] lookup.