Web.config transformation: Unrecognized attribute 'xmlns:xdt'. Note that attribute names are case-sensitive

Question

I'm getting this strange intermitent bug in a MVC 3.0 project When I build the project sometimes I get the following error message:

Unrecognized attribute 'xmlns:xdt'. Note that attribute names are case-sensitive.

This is referring to the standard web.config tranformation file (Web.Release.config copied below) There are no other errors or warnings. This is happening in debug mode and release. Sometimes it clears if I clean the solution

BEGIN UPDATE

Found the issue. In the MVC Project file (MyProject.csproj) I had set build views to true

<MvcBuildViews>true</MvcBuildViews>

Once put back to false the above error goes away. I'd like to have the view build as it stops alot of stupid view code errors etc and is a performance enhancement (pages are precompiled instead of jit)

Anyone know what this is causing the error? is this a bug?

END UPDATE

<?xml version="1.0"?>

<!-- For more information on using Web.config transformation visit http://go.microsoft.com/fwlink/?LinkId=125889 -->

<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
  <!--
    In the example below, the "SetAttributes" transform will change the value of 
    "connectionString" to use "ReleaseSQLServer" only when the "Match" locator 
    finds an atrribute "name" that has a value of "MyDB".

    <connectionStrings>
      <add name="MyDB" 
        connectionString="Data Source=ReleaseSQLServer;Initial Catalog=MyReleaseDB;Integrated Security=True" 
        xdt:Transform="SetAttributes" xdt:Locator="Match(name)"/>
    </connectionStrings>
  -->
  <system.web>
    <compilation xdt:Transform="RemoveAttributes(debug)" />
    <!--
      In the example below, the "Replace" transform will replace the entire 
      <customErrors> section of your Web.config file.
      Note that because there is only one customErrors section under the 
      <system.web> node, there is no need to use the "xdt:Locator" attribute.

      <customErrors defaultRedirect="GenericError.htm"
        mode="RemoteOnly" xdt:Transform="Replace">
        <error statusCode="500" redirect="InternalError.htm"/>
      </customErrors>
    -->
  </system.web>
</configuration>

Alfred

The web.release.config above is exactly as provided by MS – Alfred

I had never touched MvcBuildViews and it defaults to false. This error appeared all of a sudden – Malodorous

@AndrewHarry it would be nice to mark one of the answers as correct, after all this time =) – Pernas

@AndreCalil I would mark one as the 'Answer' but as you say it was a long time ago and I wouldn't have a clue which is the best – Alfred

Also I'm not getting this error now so i'm guessing it was a bug which subsequent updates to the framework have now fixed? – Alfred

@AndrewHarry I'm not sure, but selecting on of the answers would be somewhat polite, you know? – Pernas

@AndrewHarry note that you assume that MvcBuildViews prevents "jitting" (or code gen + compilation + jitting really) on the server. Note that it actually does not do any of these things. It only helps validate your build. See this thread - https://mcmap.net/q/46465/-compile-views-in-asp-net-mvc – Selia

@YishaiGalatzer Cheers for pointing that out! – Alfred

Answer 1

I ran into the very same problem. You will find lots of banter out there related to MvcBuildViews and various error conditions. But none seem to mention this particular error. A quick fix that worked for me was to delete the contents of the "obj" directory for the affected web project, then rebuild.

Midweek

Good one. I was about to set MvcBuildViews to false against my will just to get rid of this error. Thanks! – Cyn

Boy, I thought 'Clean Solution' meant exactly that. Guess I was wrong. – Treenatreenail

Declaring this the winner – Alfred

Not working for me in VS 2019. I ran Clean solution, I deleted obj as well as bin, and ran Rebuild All. – Improvise

Answer 2

This is kind of a workaround, but you may add the following line to your pre-build commands:

del $(ProjectDir)obj\* /F /S /Q

Right click your project > Properties > Build Events > Pre-build

Pernas

Remember to wrap quotes around the $(ProjectDir)obj\* part if your project is located in a path that has spaces in it. – Decennial

I had to add this as a post build event as well to get things running – Stodgy

This issue was pretty annoying, as it was not happening for every build. Thanks @AndreCalil doing what you suggested fixed that for me! – Staple

@SlickShinobi thanks for the feedback, glad it helped – Pernas

Answer 3

This works with Continuous Integration and WebDeploy:

This problem occurs the moment I set

<MvcBuildViews>true</MvcBuildViews>

in my Project file, which I need to do.

After reading and testing everything I found about this problem I have a wokraround, that also works with WebDeploy via MSBuild

MSBUild.exe ... /p:DeployOnBuild=true

You (only) need to delete the TransformWebConfig subfolder in your buildfolder during the pre- AND post-build events. It even works with continuous integration servers which break if no folder exists

Pre-build event command line:

if exist "$(ProjectDir)obj\$(ConfigurationName)\transformwebconfig\" del "$(ProjectDir)obj\$(ConfigurationName)\transformwebconfig\*" /F /S /Q

Post-build event command line:

if exist "$(ProjectDir)obj\$(ConfigurationName)\transformwebconfig\" del "$(ProjectDir)obj\$(ConfigurationName)\transformwebconfig\*" /F /S /Q

This even works fine with Resharper which will sometimes get confused, if you delete the whole obj folder.

Make sure to set the Run the post-build event to always!!

UPDATE: Replaced debug and release with $(ConfigurationName) and removed resulting duplicate line

Statesmanship

I wish I had a full understanding of why this happens. When I was running my TeamCity server on my local machine everything worked fine. As soon as we moved TeamCity to a dedicated buildserver we started running into this issue. Perhaps it's worth starting an MS Connect issue for. – Stodgy

Connect issue created here: connect.microsoft.com/VisualStudio/feedback/details/933625/… – Stodgy

I've tried several solutions including the Pre/Post-build event command line. This seems to have only worked the first time, but subsequent builds keep failing. So far only MvcBuildViews=false seems to offer the most consistent fix, but will not be an acceptable workaround for every project. – Sitsang

Answer 4

I resolve my conflict by doing the same thing that Job said. Removing the attribute

xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform"

From the main Web.config and leave it into the Web.debug.config and Web.release.config

Pressor

Answer 5

just remove the xmlns:xdt attribute from the web.config, but keep it in web.release.config and web.debug.config.

Your transform will still work - and so will your website.

Quartermaster

YOU ARE THE SAVIOUR!.. HOW COME NOBODY USED THIS SOLUTION.. thanks a ton @JOB.. this worked in case of winforms, app.config - slowcheetah transformations! – Fredrick

Answer 6

There is another workaround from Microsoft Team. See details here.

Just copy-paste this snippet into your .csproj or .vbproj file:

<PropertyGroup>
  <_EnableCleanOnBuildForMvcViews Condition=" '$(_EnableCleanOnBuildForMvcViews)'=='' ">true</_EnableCleanOnBuildForMvcViews>
</PropertyGroup>
<Target Name="CleanupForBuildMvcViews" Condition=" '$(_EnableCleanOnBuildForMvcViews)'=='true' and '$(MVCBuildViews)'=='true' " BeforeTargets="MvcBuildViews">
  <ItemGroup>
    <_TempWebConfigToDelete Include="$(BaseIntermediateOutputPath)**\Package\**\*" />
    <_TempWebConfigToDelete Include="$(BaseIntermediateOutputPath)**\TransformWebConfig\**\*" />
    <_TempWebConfigToDelete Include="$(BaseIntermediateOutputPath)**\CSAutoParameterize\**\*" />
    <_TempWebConfigToDelete Include="$(BaseIntermediateOutputPath)**\TempPE\**\*" />
  </ItemGroup>
  <Delete Files="@(_TempWebConfigToDelete)" />
</Target>

This will automate the process of cleaning 'obj' folder using Build Targets.

Toler

Answer 7

I've found this works better for me:

del "$(ProjectDir)obj\*" /F /Q
del "$(ProjectDir)obj\$(ConfigurationName)\AspnetCompileMerge\*" /F /S /Q
del "$(ProjectDir)obj\$(ConfigurationName)\CSAutoParameterize\*" /F /S /Q
del "$(ProjectDir)obj\$(ConfigurationName)\Package\*" /F /S /Q
del "$(ProjectDir)obj\$(ConfigurationName)\ProfileTransformWebConfig\*" /F /S /Q
del "$(ProjectDir)obj\$(ConfigurationName)\TempPE\*" /F /S /Q
del "$(ProjectDir)obj\$(ConfigurationName)\TransformWebConfig\*" /F /S /Q

otherwise build(s) complain about edmxResourcesToEmbed disappearing.

Kalvn

@AndreCalil No, not me. – Kalvn

Nevermind, so. Some guy simply downvoted without telling me why. Go figure! – Pernas

Answer 8

I have seen this too. Specifically, it had been reproducible when changing between build configurations in Visual Studio.

My workaround previously had been to delete everything in the \obj folder, but after going through my web.config closely, I found it had some erroneous text sitting outside an element (i.e. it was invalid XML).

Seemingly the config transforms was just swallowing up an exception when trying to perform the transformation.

Fixed up my web.config to be valid, and all is working as expected now.

Hope this helps someone

Anaximander

Answer 9

I've also run into this issue. For me it was caused by my having created a new debug configuration called, "DevDebug". I fixed it by making a copy the web.debug.config, named web.DevDebug.config and added it to the project.

Then, when I attempted to run the aspnet compiler, it was satisfied that it could find the right configuration version of the config file to merge in.

Whitewall

Answer 10

I just change below on web.config

<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">

to

<configuration>

It fixed the problem

Supposed

Answer 11

1. Right click on the project, click Publish
2. Goto Settings -> File Publish Options
3. Uncheck Precompile during publishing

This will prevent the web.debug.config/web.release.config injecting the file back to the web.config if you are using visual studio publish.

Petuntse