Category Archives: Programming

Realtime MVC ModelState errors during debugging

While working on my most recent ASP.NET MVC project, I was having a tough time figuring out why my ModelState was invalid. It was due to the fact that I set the error messages to “Required” or “Invalid” for ALL of my model properties (to support the way the view presents the error messages). In retrospect, this probably wasn’t the smartest choice. Oh well, now I’m stuck figuring out another way to determine the properties causing Model validation to fail.

With Visual Studio 2015, I discovered a marvelous way to get the names of the properties with invalid values… buy using a watch! Watches now support lambda expressions (as long as there are no external dependencies, such as LINQ to SQL), so I thought… this would be a good time to test that functionality.

Since I was interested in the actual name of the property that was causing
ModelState.IsValid to return false, I used the following watch:

ModelState.Where(x => x.Value.Errors.Count > 0).Select(x => x.Key).ToList()

For those who don’t usually use watches, you may not know that a watch can be created directly in the watch window by just typing it in! That is what you will need to do here, since I’m guessing that this value is most likely not in your code…


If you get a message under Value saying “This expression causes side effects and will not be evaluated,” just click the refresh button to the right of the message to force-evaluate the watch. Once you do so, you’ll be able to expand the watch object to see your offenders!


Pretty neat!

allowDefinition=’MachineToApplication’ error after enabling MVC compile-time view checking

Two posts in one day?  Yesh… I’m just trying to make up for my extended hiatus from blogging!

Actually, this post supplements the previous one, but I think it is the more important of the two since I don’t believe there is a complete solution to this problem is anywhere else on the interweb (except for my answer on stackoverflow, which has ZERO upvotes… not that I’m counting LOL).

Here’s our scenario:

  1. The developer wants compile-time checking on views, so they set MvcBuildViews=true.
  2. The application builds fine, UNTIL they publish the project.
  3. Subsequent attempts to build the project result in a compile-time error: It is an error to use a section registered as allowDefinition='MachineToApplication' beyond application level. This error can be caused by a virtual directory not being configured as an application in IIS.

So what causes this issue? When the project is published the compiler, by default it uses <project-dir>\obj\ to place copies of the source files that it will work with. Unfortunately, these files are not automatically deleted when publishing is complete. The next time the developer compiles the project with MvcBuildViews=true, it will error out because the aspnet compiler includes the obj\ folder during compilation, since it is underneath the <project-dir> folder.

So how do we fix this? Well, you have four options:

  1. Set MvcBuildViews=false. I don’t really consider this a solution, so let’s move on.
  2. Delete the files in <project-dir>\obj\. Works, but can be a hassle since it has to be done after every publish.
  3. Change the path that publishing uses as an intermediate directory through the use of the <BaseIntermediateOutputPath> property in your project config file. See this link.
  4. Add a new section in your project config file that deletes the offending files for you on build (reference Microsoft Connect). I’ve even made it easy for you, just copy and paste:
    <_EnableCleanOnBuildForMvcViews Condition=" '$(_EnableCleanOnBuildForMvcViews)'=='' ">true</_EnableCleanOnBuildForMvcViews>
    <Target Name="CleanupForBuildMvcViews" Condition=" '$(_EnableCleanOnBuildForMvcViews)'=='true' and '$(MVCBuildViews)'=='true' " BeforeTargets="MvcBuildViews">
        <_TempWebConfigToDelete Include="$(BaseIntermediateOutputPath)**\Package\**\*" />
        <_TempWebConfigToDelete Include="$(BaseIntermediateOutputPath)**\TransformWebConfig\**\*" />
        <_TempWebConfigToDelete Include="$(BaseIntermediateOutputPath)**\CSAutoParameterize\**\*" />
        <_TempWebConfigToDelete Include="$(BaseIntermediateOutputPath)**\TempPE\**\*" />
    <Delete Files="@(_TempWebConfigToDelete)"/>

My recommendation would be to use either option 3 or 4.

ASP.NET MVC compile-time view checks in Visual Studio 2012

Anyone who has worked with MVC has suffered through runtime view errors.  This is because views don’t get compiled until IIS renders them.  In order to check for successful compilation, you can:

  1. Manually visit every view in the browser (easy but tedious)
  2. Create automated UI tests (harder)
  3. Turn on compile-time view checks (just easy)!

Since I like just easy, I’m going to show you how to turn on compile-time view checks:

  1. Unload the project (right-click on the project in Solution Explorer and select Unload Project
  2. Right-click the project again and select Edit *.csproj
  3. In the PropertyGroup section, add: <MvcBuildViews>true</MvcBuildViews>
  4. Save the csproj file and reload the project
  5. Eat a banana (optional)

Now, when running the build, visual studio will compile all of your views as well, and identify any errors.

IIS 7/.NET 4 System.DirectoryServices: The (empty) search filter is invalid

This is a silly error, but it has caught me a couple of times.  Surprisingly, there doesn’t seem to be a blog anywhere that talks about this specific issue.

Situation: you have an ASP.Net 4+ application running on IIS 7.  You navigate to the page and get a server error:


Specifically, “The (&(objectCategory=user)(objectClass=user)(|(userPrincipalName=)(distinguishedName=)(name=))) search filter is invalid.”  Note, that if you don’t have the pdb deployed, your source error will not show the actual error line, but rather “An unhanded exception was generated during the execution of the current web request.  Information regarding the origin and location of the exception can be identified using the exception stack trace below.”

This can be particularly vexing if application works on your development machine, but not in production.

Cause: The LDAP lookup is failing because your directory requires authentication, and you’re running an anonymous session with a local computer account.

Fix: In IIS, turn off Anonymous Authentication and turn on Windows Authentication instead.

Javascript Intellisense in Visual Studio 2012

After years of use, I tend to accumulate a lot of cruft on my work computer hard drives, so whenever I replace a machine or hard drive I like to start fresh and only pull down old files from the backup server as I need them.  Last week, I replaced the hard drive on my laptop, so I had to redo all of the settings on Visual Studio.  As I had forgotten how to do this, I figured I should write it down to help me next time… perhaps it will help you too?

When developing Visual Studio MVC projects, if you’re like me, you like to move directories around to make more sense of the layout (instead of the default structure that M$ gives you).  An example of this is creating a public directory to hold your publicly available files, like styesheets and scripts.  You’ll also notice that when you move your Javascript libraries, Intellisense breaks.  This happens whenever the _references.js file is moved from its expected location*.

To fix, simply go to Tools | Options | Text Editor | JavaScript | IntelliSense References.  Switch to the Implicit (Web) Reference Group and add a new reference that resolves to the new location of the _references.js file:


Note that if you want to use a path relative to your project, it has to be entered into the text box at the bottom, in the form of “~/whatever_dirs_below_project_root”.

* If you want Intellisense support for your Javascript libraries, you need to be sure that the library name is included in the _references.js file.  This is not all, however.  VS also needs a vsdoc.js file that provides the particular data needed by Visual Studio Intellisense (e.g. jquery-1.10.0-vsdoc.js supports jquery-1.10.0.js).  Note that you should NOT include the vsdoc file name in the _references.js file, just the main file.  Intellisense vsdoc files for jquery are available on the ASP.NET CDN at

Referenced assembly could not be resolved because it has a dependency which is not in the currently targeted framework

If you are using third-party development tools (like Ninject) with your .NET 4.0 project.  You may get the following error at compile time:

Warning: The referenced assembly "<Assembly>" could not be resolved because it has a dependency on "System.Web, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" which is not in the currently targeted framework ".NETFramework,Version=v4.0,Profile=Client". Please remove references to assemblies not in the targeted framework or consider retargeting your project.

This error is a result of .NET 4.0 targeting (by default) the .NET Framework 4 Client Profile.  This profile is a subset of the full profile and does not have the entire .NET class library.  To fix, go into Project Properties  | Application, and change the target framework to: .NET Framework 4.  Visual Studio will prompt you that your solution must be closed and reloaded.  Once you do this, the project should compile as expected.