110

Has anyone seen this error and know how to fix it?

The "TransformXml" task could not be loaded from the assembly C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.Tasks.dll.

Could not load file or assembly 'file:///C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.Tasks.dll' or one of its dependencies. The system cannot find the file specified.

Confirm that the declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.

I read elsewhere that the problem is when you don't have SQL Server installed. But I do have SQL Express 2012 x64 installed with SP1. I am also running VS 2013 Professional.

I have ran this exact same solution in VS 2012 express with no problems.

Jeroen
  • 60,696
  • 40
  • 206
  • 339
allencoded
  • 7,015
  • 17
  • 72
  • 126
  • 1
    This should be a nuget package. I don't like this hidden references inside of my project. – Jaider Jun 24 '15 at 21:25
  • You should mark the answer from Benjamin Scheibe as the correct one. It seems to be the best solution – BHuelse Apr 03 '18 at 08:03

11 Answers11

181

The answers provided by Dai Bok and emalamisura work fine as long as you use Visual Studio 2012. For VS 2013 this fails as well. In order to make this work with all versions of Visual Studio you should:

  • Open the project file (.csproj) of the project failing to load
  • Search for <Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets" />
  • Change it to <Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v$(VisualStudioVersion)\Web\Microsoft.Web.Publishing.targets" />
  • Reload the project

That will set the correct version of Visual Studio dynamically and properly.

Ben Sch
  • 2,909
  • 4
  • 20
  • 23
  • 2
    I like your solution Benjamin, but the problem I was having was that the v11 folder was missing, possiblly because we have some people using vs2010 and have not upgraded to vs2012 yet – Dai Bok Nov 16 '14 at 15:12
  • 8
    This got me started on the right path, but the change I made was to the node. My AssemblyFile was using the wrong version. Just needed to change the version here. Another option would be to use a version macro instead of explicitly setting the version. – Scott Feb 28 '15 at 21:30
  • 6
    `$(VisualStudioVersion)` is returning an earlier version :( – Jaider Jun 24 '15 at 21:22
  • 1
    This can be a parameter: http://stackoverflow.com/questions/20002532/build-vs2013-on-a-tfs-build-server-with-only-vs2013 – Jaider Jun 24 '15 at 21:38
  • 1
    I just used this to update a .proj that was having this error in VS 2015. Worked perfectly. – Hypnovirus May 26 '16 at 20:41
  • 2
    Perfectly works while upgrading from VS2015 to VS2017. Now I can open the solution in both IDEs. – Yury Schkatula Jul 18 '17 at 16:42
  • 1
    In my case, we were using SlowCheetah for config transformation during our development phase, now that we're using Azure DevOps for our deployments we don't use SlowCheetah any longer (and removed the NuGet package) but the project file still had references to it. Removed them and we're off to the races, thanks for pointing me in the right direction! – Mike Devenney Jan 14 '19 at 21:03
  • Glad that this post is still helping some folks out there! :) – Ben Sch Jan 27 '19 at 11:29
  • Note that you can see what `$(MSBuildExtensionsPath)` resolves to by looking at your error. In the OP's case, it is `C:\Program Files (x86)\MSBuild` For me, it was `C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild` (I'm using VS 2019) – David Mar 21 '19 at 15:53
  • Worked for me for VS2017 -> VS 2019 – mikka Nov 09 '20 at 08:55
  • On Nov 25th 2022, this stopped working for me on my Azure Build Agents - (was last working on Nov 23rd) – bkwdesign Dec 21 '22 at 18:03
30

To get mine to work, I just copied my v10.0 folder and renamed it to v11.0, and things seems to work well from then on. That's the quick fix for now.

As this is probably not the best solution, and although it works, I was going to try installing the Microsoft Windows SDK for Windows 7 and .NET Framework 4 Windows SDK for Windows 7 and .NET Framework 4, but it is taking to long to download.

Dai Bok
  • 3,451
  • 2
  • 53
  • 70
11

To fix the issue,

  1. Find the Visual studio Installer in your computer
  2. Click or tap to start the installer, and then select Modify.
  3. From the Individual Components screen, select Asp.net and web development tools and then select Modify/Install.

This solved the issue as it creates the dll's in the mentioned path.

  • 2
    I'm using VS2017 and performing this step does not create those files. I think maybe something else you selected (or in combination with ASP.net and web development tools) that added it. Not sure what though :( – Kris Jul 27 '17 at 19:35
  • I've selected only that. Try selecting Web related components and install. Good Luck though. – Vinodhini Ramasamy Jul 31 '17 at 09:57
  • I just tried the whole of the web workflow and still don't have those files. I feel like this solution is so close. Wish it could be pin pointed since I have limited space on my HDD to install components – Robert Snyder Aug 28 '17 at 13:45
  • 5
    For VS2017, I did `Tools → Get Tools and Features... → Individual Components: Windows 10 SDK (10.0.14393.0) and ASP.NET and web development tools `. This seems to have done the trick. – John Jones Sep 06 '17 at 22:59
  • Tried this for VS2022 but none of the extra installs fixed it for me. I noticed mine was referencing a path with an odd value in it called \vCurrent, looked like this => C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VisualStudio\vCurrent\Web\ I figured vCurrent might be v17.0 (current version) but it was not. I had to manually copy the DLLs (Microsoft.Web.Publishing.Tasks.dll & Microsoft.Web.XmlTransform.dll) into that directory & then it worked immediately. – raddevus Aug 17 '22 at 18:24
10

I've been combating this problem on our build server for several days, so I figured I'd document the resolution I came to. First, my build server has the web publishing extensions installed. I can use the TransformXml task to my heart's content inside of a web application project.

To use it outside of a web application project, I tried to add the UsingTask element to my project and point it to the right place using ms build properties (as Benjamin demonstrated). However, they weren't there on my build server (those with easy access to the file system of their build server can probably skip this and just install the relevant package to Visual Studio). I even went so far as to hard code visual studio versions, but it always dropped that error on me.

I finally gave up, pulled the DLLs from my local PC:

C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\Web\Microsoft.Web.Publishing.Tasks.dll
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\Web\Microsoft.Web.XmlTransform.dll

I uploaded them to source control and added that folder to my build's workspace (Edit Build Definition -> Source Settings -> Source Control Folder). From there, I don't even need to reference the folder -- here's what my UsingTask looks like:

  <UsingTask TaskName="TransformXml" AssemblyFile="Microsoft.Web.Publishing.Tasks.dll" />

Now I can use the TransformXml task to my heart's content from any project.

bvoyelr
  • 920
  • 8
  • 11
  • 9
    The [MSBuild.Microsoft.VisualStudio.Web.targets](https://www.nuget.org/packages/MSBuild.Microsoft.VisualStudio.Web.targets/) package has the necessary targets to build without VS installed. For Example: . See [this](https://coderwall.com/p/qvrchq/getting-teamcity-to-build-asp-net-mvc-3-web-solutions) blog for more details – moonpatrol Mar 24 '15 at 01:10
  • 1
    Hey @moonpatrol, you should make it an answer, because I prefer this way - installing package and then referring it - absolutely universal solution :-) I just tried it, and works perfectly. Thank you anyway! if you make it an answer, just ping me and I will vote. – Tengiz Jun 08 '16 at 18:18
  • Thanks for showing the full path to the files it is looking for. That helped a ton. I just went to a system that had those files and copied them to the new one. But, check this out --- The path that it was looking for in mine had an odd value in it called vCurrent, looked like this => C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VisualStudio\vCurrent\Web\ I figured vCurrent might be v17.0 (current version) but it was not. I had to copy those DLLs to the path shown above & then it instantly worked. Crazy – raddevus Aug 17 '22 at 18:21
7

For VS2019

<UsingTask TaskName="TransformXml" AssemblyFile="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(MSBuildToolsVersion

I replaced MSBuildToolsVersion with VisualStudioVersion.

vik_78
  • 1,107
  • 2
  • 13
  • 20
  • By this document "https://learn.microsoft.com/visualstudio/msbuild/whats-new-msbuild-16-0?view=vs-2019" change **MSBuildToolsVersion** with **VisualStudioVersion** then I change that propety working well like this "**$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)**" – Kim Ki Won Jun 14 '20 at 02:28
6

Because there are only v12.0, v14.0 and v15.0 in my VisualStudio folder, I edit my project file and change the reference path from v10.0 to v14.0. Then the project builds successfully.

Before:

<UsingTask TaskName="TransformXml" AssemblyFile="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.Tasks.dll" />

After:

<UsingTask TaskName="TransformXml" AssemblyFile="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v14.0\Web\Microsoft.Web.Publishing.Tasks.dll" />
Blade
  • 131
  • 1
  • 4
3

Solutions provided seem to work for using VS as an IDE, but if you use DotnetCore via CLI or on a unix based system this does not work.

I found that the following seem to work

  <PropertyGroup>
    <XmlTransformDllPath Condition="'$(XmlTransformDllPath)' == '' AND '$(MSBuildRuntimeType)' == 'core'">$(MSBuildSDKsPath)/Microsoft.NET.Sdk.Publish/tools/net5.0/Microsoft.NET.Sdk.Publish.Tasks.dll</XmlTransformDllPath>
    <XmlTransformDllPath Condition="'$(XmlTransformDllPath)' == '' AND '$(MSBuildRuntimeType)' != 'core'">$(MSBuildSDKsPath)/Microsoft.NET.Sdk.Publish/tools/net472/Microsoft.NET.Sdk.Publish.Tasks.dll</XmlTransformDllPath>
    <XmlTransformDllPath Condition="!Exists($(XmlTransformDllPath))">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\Web\Microsoft.Web.Publishing.Tasks.dll</XmlTransformDllPath>
  </PropertyGroup>
  <UsingTask TaskName="TransformXml" AssemblyFile="$(XmlTransformDllPath)" />

This solution takes into account netcore, full .net

For some reason MSBuildSDKsPath and MSBuildExtensionsPath32 are different on windows when using CLI vs VS2019

CLI: MSBuildSDKsPath = C:\Program Files\dotnet\sdk\5.0.103\Sdks MSBuildExtensionsPath32 = C:\Program Files\dotnet\sdk\5.0.103

Vs2019 MSBuildSDKsPath = C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Sdks MSBuildExtensionsPath32 = C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild

Which on my Mac returns /usr/local/share/dotnet/sdk/5.0.201

Only problem I see is with the tools/net5.0 part of the name which changes ever release

Also created https://github.com/dotnet/sdk/issues/16469 and answers this on The "TransformXml" task was not found (error MSB4036) on TeamCity build

Max Hamulyák
  • 228
  • 1
  • 7
  • This was the only way to get my azure CI pipeline (vmImage: windows-2019) to build my net48 project using the SDK project style and the `task: DotNetCoreCLI@2` build step (and simultaneously support the standard developer experience in VS 2019) Thank you 1,000,000 x's – bkwdesign Sep 22 '21 at 16:32
  • Because the part with `tools/net5.0` changes with every release - which I noticed on my Azure Build Agents that stopped building my projects. I had to modify a bit, and use this instead: `tools/$(WasmNativeWorkload)` – bkwdesign Dec 28 '22 at 13:55
2

The correct answer to this is to unload the project in question and then edit the csproj file, look for an entry where they are referencing the 10.0 path and change it to point to 11.0 instead.

emalamisura
  • 2,816
  • 2
  • 29
  • 34
1

You need two things to make it work:

1) Install Visual Studio Build Tools (You don't need the whole Visual Studio, only the VS Build Tools) with selected "Web development build tools" option on your build server https://www.visualstudio.com/pl/thank-you-downloading-visual-studio/?sku=BuildTools&rel=15

2) Ensure that path to Microsoft.Web.Publishing.Tasks.dll is correct

  <UsingTask TaskName="TransformXml" AssemblyFile="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(MSBuildToolsVersion)\Web\Microsoft.Web.Publishing.Tasks.dll" />
cezarypiatek
  • 1,078
  • 11
  • 21
1

For me it started working just by adding reference to the NuGet package MSBuild.Microsoft.VisualStudio.Web.targets v14.0.0.3

Even no need to add UsingTask element to the project file as it mentioned by the package author

https://github.com/pdonald/nuget-webtargets

Just install the NuGet package. The package automatically sets the $(VSToolsPath) property to use the targets file in the tools folder.

And then I was able to use TransformXml and other tasks, defined in the package, for instance to transform app.config

  <Target Name="app_config_AfterCompile" AfterTargets="AfterCompile" Condition="Exists('app.$(Configuration).config')">
    <!--Generate transformed app config in the intermediate directory-->
    <TransformXml Source="app.config" Destination="$(IntermediateOutputPath)$(TargetFileName).config" Transform="app.$(Configuration).config" />
    <!--Force build process to use the transformed configuration file from now on.-->
    <ItemGroup>
      <AppConfigWithTargetPath Remove="App.config" />
      <AppConfigWithTargetPath Include="$(IntermediateOutputPath)$(TargetFileName).config">
        <TargetPath>$(TargetFileName).config</TargetPath>
      </AppConfigWithTargetPath>
    </ItemGroup>
  </Target>
Community
  • 1
  • 1
Bill
  • 409
  • 1
  • 6
  • 6
  • FYI - I tried this in VisualStudio 2022 & mine still wouldn't build & I got the same error about the transform xml. – raddevus Aug 17 '22 at 14:10
1

Just in case someone is using an SDK-style csproj, you can achieve this without having to install Visual Studio on the build server.

  1. First you should install the SlowCheetah nuget package to your project. Once you install it, you'll see the following in your SDK-style project.

    <PackageReference Include="Microsoft.VisualStudio.SlowCheetah" Version="3.2.20">
            <PrivateAssets>all</PrivateAssets>
            <IncludeAssets>runtime; build; native; contentfiles; analyzers</IncludeAssets>
    </PackageReference>
    
  2. Then make sure you add the GeneratePathProperty="true" attribute (see below). This is very important for the next part because it'll help you grab the path of where the nuget package is restored on your machine. George Dangl explains it in his article here.

    <PackageReference Include="Microsoft.VisualStudio.SlowCheetah" Version="3.2.20" GeneratePathProperty="true">
            <PrivateAssets>all</PrivateAssets>
            <IncludeAssets>runtime; build; native; contentfiles; analyzers</IncludeAssets>
    </PackageReference>
    
  3. Import the SlowCheetah targets into your project:

    <Import Project="$(PkgMicrosoft_VisualStudio_SlowCheetah)\build\Microsoft.VisualStudio.SlowCheetah.targets" />
    
  4. You can now use an target command (in this case after publish) to apply some custom transformations. If you need to, you can always hard-code the file names below instead of using the variables in the below example.

    <Target Name="AfterPublishs" AfterTargets="Publish">
         <TransformTask Source="Web.config" Transform="Web.$(Configuration).MyCustomTransformFile.config" Destination="$(PublishDir)\Web.config" />
    </Target>
    

If you haven't used SlowCheetah before, I recommend checking it out. They have a Visual Studio extension that will make it easier for you to preview transform files.

Eric Chhun
  • 191
  • 1
  • 4