Tag Archives: asp.net

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="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:


Instead of this:


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.

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.

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()
        _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
        _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)];
    }//END IF
/* ---------------------------------------------------------------------- */

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

Enumerating HttpModules

One common ASP.NET performance tip is to remove any HttpModules that your application does not use.  You can take a peek at which modules are loaded by the framework on your behalf by examining the framework's Web.config file, but how do you find out which modules are actually loaded in the current context?

Fortunately, the HttpApplication instance provides a Modules collection that you can loop through:

// Get a collection of modules loaded for the current context.
HttpModuleCollection modules = HttpContext.Current.ApplicationInstance.Modules;

// Enumerate the loaded HttpModules and do something with them.  For example, you can
//  create a table, listing each module by key and full type name.
// NOTE: the key is the same key specified in Web.config to add the module.
foreach (string moduleKey in modules.Keys)
    IHttpModule module = modules[moduleKey];

    // Do something with the module key and/or the HttpModule.

You can then use the Modules collection create a table like this:  

And boom, there you have it: a list of HttpModules that are loaded for the current context.  You can use this information to determine which HttpModules are needed by your application, and which ones you can safely remove.