Fun Times Updating a Very Old Azure Web Application

Back in the pre-history days of .NET (1999), Microsoft promised the new platform would end DLL hell. The .NET platform did make versioning monumentally easier. And yet I spent half an hour recently trying to get a common package (Entity Framework 6) to install in a project that never had that package in the first place—because of a version conflict with .NET itself.

When I tried to install EF6, the NuGet package installer failed the installation with the message “This operation would create an incorrectly structured document”. A quick check of StackOverflow suggested a couple of possible causes:

  • The Entity Framework installer creates an invalid web.config file because it gets confused about the older project’s XML namespaces.
  • The EF installer chokes on .NET 4.5 and .NET 4.5.1 because it’s broken.

Anyone who’s spent time with Microsoft products should immediately suspect that hypothesis #2 is unlikely. No, seriously: Microsoft releases things that have bad usability, rude behavior, and incomplete features all the time, but they have some incredible QA people. This fits that pattern: the installer script works fine. It just has pretty dismal error reporting.

So after removing every trace of EF from the relevant files, and downgrading the app to .NET 4.0 from .NET 4.5.1, EF still wouldn’t install. Only at this point did I start thinking about the problem.

Let’s review: I had an error message about an incorrectly-structured document. The document in question was almost certainly web.config, which I could tell because the EF6 installation kept changing it. The web.config file is an XML document. XML allows you to specify a namespace. This particular XML document had a namespace defined. A Stack Overflow commenter had mentioned namespaces. Um…

At this point I changed the web.config header element from this:

<configuration xmlns="">

to this


That fixed it.

The moral of this story: read error messages carefully, form hypotheses based on the data you have available, and even before that, stop and think. And even if you’re not a Microsoft developer working on NuGet package installer scripts, always give as much detail as possible in error messages, so that developers who read them can spend less time trying to understand why the operation they thought was simple took so long to accomplish.