Can not compile because dll-missing error?

[thimmey]

I just installed VS2013 and compiled my project. everything worked. After Iadded SlowCheetah I get the following error during compilation.

The SlowCheetah.Xdt.TransformXml-Task could not be loaded from the C:\Users\User\AppData\Local\Microsoft\MSBuild\SlowCheetah\v2.5.10\SlowCheetah.Xdt.dll-Assembly. The File or Assembly "file:///C:\Users\User\AppData\Local\Microsoft\MSBuild\SlowCheetah\v2.5.10\SlowCheetah.Xdt.dll" or a dependency could not bge found. The system could not find the file. Make sure that the -declaration is correct, that the assembly and all dependencys are available and that the task contains a public class which implements Microsoft.Build.Framework.ITask.

Kind Regards Tim

[sayedihashimi]

When you right clicked Add Transform did it not install the NuGet package? From the error it looks like it was not installed for some reason.

[thimmey]

Hi,

I installed it, uninstalled it, and reinstalled it again. I use Visual Studio 2013 German.

Can I provide something else?

[thimmey]

I Just checked with a new Project. If I create a new Project, Add-Transform brings up a Dialog which asks me to modify the Project Settings. But compiling doesn't work.

[nicholi]

I just had a similar weird issue when updating the NuGet package itself in a project, but forgot to update the extension as well (under Tools->Extensions and Updates). After updating the extension compiling worked again.

[thimmey]

Do I have to install the nuget package as well as the extension? I had never installed the package when I was on VS 2010.

EDIT:

Even with installing it as a NuGet package its not working. Same Error.

[thimmey]

I'm not sure what I've exactly done. But after showing "prewiew transform", the compilation of all projects is working now.

[jasonkcarter]

I get exactly the same error on a fresh install of VS 2012 w/ Update 3 and SlowCheetah 2.5.10. I checked the userDir\AppData\Local\Microsoft\MSBuild\SlowCheetah\v2.5.10, and all my source code from the last compiled project is in there instead of SlowCheetah.Xdt.dll.

This seems to happen when a project that uses SlowCheetah has a project reference to a project that does not use SlowCheetah.

Edit: I should also mention that I am using NuGet package restore on this solution.

Edit 2: If you delete the userDir\AppData\Local\Microsoft\MSBuild\SlowCheetah\v1 directory and the v2.5.10 directory, then rebuild, everything works fine. So it looks like the bug is something to do with the existence of the v1 directory.

[dufkaf]

for me it works even if v1 directory is there but I started with older version of slow cheetah and just upgraded to latest, I don't think I installed slow cheetah nuget package ever and I don't have any nuget packages in my project.

Quick workaround for new installation of 2.5.10 seems to be to generate new solution/web project, install slow cheetah via nuget console there, build it and then throw it away. Then building works also for other projects. At build time it executed some powershell script so maybe it installed missing stuff to some shared location?

[sayedihashimi]

I can't reproduce this error. Is it happening consistently? Can someone help with repro steps here?

[jasonkcarter]

It happens pretty consistently when I have more than one solution that utilizes SlowCheetah open simultaneously, or when I switch git branches and reload my projects. I'll see if I can narrow down some test conditions for you.

Edit: Also, I am running on Visual Studio 2012 Premium and Windows 8.1. I just ran the compatibility troubleshooter on devenv.exe to change the compatibility mode to Windows 8. I haven't seen any SlowCheetah problems ever since, but it may still be too early to tell. I'll keep you informed.

[wilson0x4d]

Confirmed, happens for me as well.

Repro steps given by others seem pretty clear:

1) new system 2) build an existing web project using an old version of slowcheetah 3) install/update slow cheetah via vs extensions/addins dialog 4) attempt to re-build existing web project, build fails

Confirmed VS2010 and VS2012 ... two different computers. Seems to happen consistently grumble

Makes me wonder if this is going to work on the build server after i check in my changes, or if I'll also have to fix the problem there as well. :( ticktock==$$$ flush

[wilson0x4d]

AppData\Local\Microsoft\MSBuild\SlowCheetah\v2.5.10 contains the output of a web project, no SlowCheetah assemblies exist.

SlowCheetah is not installed as a nuget package in any of our projects, but even if we added this it's unlikely that the web projects would build.

It's not clear to me where I should acquire the DLLs it's expecting to find here, should I just copy them over from the 1.0 folder, or should I uninstall and go back to the old version?

[wilson0x4d]

I see, the magic installer PS1 in the nuget package fixes the contents of AppData and modifies the project content to refer to the tools path from the nuget package.

Instead of "AppData\Local\Microsoft\MSBuild\SlowCheetah\v2.5.10\"

it is now installed into

"AppData\Local\Microsoft\MSBuild\SlowCheetah\v2.5.10.2\"

This new folder contains the assemblies SlowCheetah requires to build, these were previously missing after updating slowcheetah from 1.0 to 2.5.10.

The original v2.5.10 folder contains some garbage contents from one of my web projects. I doubt this was the intent.

Seems the current extension installer is broken, or the version released via Extension Manager is bugged and is clobbering the AppData folder.

I've deleted the contents of "v2.5.10" and replaced it with that from the "v2.5.10.2" folder (suspecting it's the same anyway, being a .2 build revision.) I then opened the targets file and corrected the paths to refer to v2.5.10 instead of v.2.5.10.2. I then uninstalled the nuget package from my solution and reverted the csproj changes which the installer.ps1 has made. I then deleted the v2.5.10.2 folder.

This corrected my environment. However, it's worth noting that SlowCheetah is still copying a bunch of build outputs into the v.2.5.10 folder when I build. I can't convey how sloppy this seems. Is this really necessary? Seems like a job for an /obj/ folder if it's really needed for the build/transform process.

[sayedihashimi]

Sorry about the issues here,

@wilson0x4d sorry about the file copies, it's not intentional to copy your files, Did you customize any SlowCheetah MSBuild properties? I haven't been able to repro the source file copy issue. To be on the safe side I've updated how I copy the needed files by using a hard coded list of file names. I just released on nuget.org 2.5.10.3 which just contains this one change (d185b2f43725688ed994f76c7d08d85965123477). I'm hoping that will address the file copy issue.

I think there is a mis-match happening between the VS tooling and the nuget package that the project is using. Currently when Add Transform is clicked it checks to see if the nuget package is installed, and if so it continues. So it never tries to update the nuget package or enforce a minimum version.

Since there seems to be a potential conflict here I'm thinking to check for a minimum version of 2.5.10.3 and then install if necessary.

Let me know if anyone has a concern with that approach.

[sayedihashimi]

There is also some code that exists to fall back to %localappdata% for the source of the MSBuild files. I think this may be causing issues. Because of this I'll make the following changes.

1. When Add Transform is invoked check to see if the NuGet package is installed
2. If it is not installed, install it
3. If there is an error let the user know that the NuGet package was not installed

This along with the minimum version check of 2.5.10.3 hopefully should fix most issues people are seeing.

I'll keep working on these issues until they are all solved. Sorry for all the issues with this release. Changing .targets file location caused a few more issues than I anticipated.

[JohnGalt1717]

I'm also getting this on multiple machines against VS.net 2012. Works fine on VS.net 2013 in every attempt so far. And note that it's referencing .2 when it should be in a .3 directory as the nuget package specifies and the extension that is properly installed says it is.

[sanddigital]

I've also had an issue with the described problem.

To fix this in my case was to delete the 'SlowCheetah' folder in the project 'Properties' folder. I also deleted the Nuget 'packages' folder so Nuget would restore everything from scratch.

In my case, the project had the 'SlowCheetah' folder due to being apart of a VSIX project template. Since then, I have removed the folder from the template.

[sanddigital]

As it turns out the only proper way I could fully fix this issue was to fully uninstall via Nuget then reinstall via Nuget. There must have been older files sitting on my machine that kept the transforms working. I tested this by running on a machine where there was no reference to SlowCheetah.

[mharen]

The problem goes away if I add this line to the existing SlowCheetah property group in my .csproj:

<PropertyGroup Label="SlowCheetah">
    <sc-MSBuildLibPathLocal Condition="'$(sc-MSBuildLibPathLocal)'==''">
        $(MSBuildProjectDirectory)\..\packages\SlowCheetah.2.5.10.3\tools\
    </sc-MSBuildLibPathLocal>
</PropertyGroup>

I'm guessing there's a more elegant solution out there...

[helmerm]

Hi,

For me this had to do with the import order of the NuGet and SlowCheetah target files.

If NuGet comes first it will extend BuildDependsOn property with the RestorePackages target and then SlowCheetah extends the BuildDependsOn with the CopyAssembliesToLocalPath target.

This means, it tries to copy the files which are not there yet.

On the first build the target CopyAssembliesToLocalPath will exit with an error, since the slowcheetah files have not been downloaded yet. error MSB3030: Could not copy the file "xxxxxxxxxxx\packages\SlowCheetah.2.5.10.3\tools\Microsoft.Web.XmlTransform.dll" because it was not found.

This leaves an empty \AppData\Local\Microsoft\MSBuild\SlowCheetah\v2.5.10.2\ directory and the CopyAssembliesToLocalPath target will not be executed anymore, because of the !Exists('$(sc-MSBuildLibPathLocal)') condition.

After I deleted the empty v2.5.10.2 everything worked as expected.

[CThuleHansen]

I had trouble using slowcheetah on teamcity. I did as mharen and changed the transforms.targets from

<PropertyGroup>
    <sc-MSBuildLibPathLocal Condition=" '$(sc-MSBuildLibPathLocal)'=='' ">$(LocalAppData)\Microsoft\MSBuild\SlowCheetah\v2.5.10.2\</sc-MSBuildLibPathLocal>
  </PropertyGroup>

to

  <PropertyGroup>
    <sc-MSBuildLibPathLocal Condition=" '$(sc-MSBuildLibPathLocal)'=='' ">$(LocalAppData)\Microsoft\MSBuild\SlowCheetah\v2.5.10.3\</sc-MSBuildLibPathLocal>
  </PropertyGroup>

In short i've changed v2.5.10.2 to v2.5.10.3 in the buildlibpathlocal, which fixed it.

[C0BR4cH]

For me the problem lied in the *.csproj file. Changing it from:

  <ItemGroup>
    <None Include="App.config">
      <SubType>Designer</SubType>
      <TransformOnBuild>true</TransformOnBuild>
    </None>
    <None Include="App.Debug.config">
      <DependentUpon>App.config</DependentUpon>
      <IsTransformFile>True</IsTransformFile>
    </None>
    <None Include="App.Release.config">
      <DependentUpon>App.config</DependentUpon>
      <IsTransformFile>True</IsTransformFile>
    </None>
  </ItemGroup>

To:

  <ItemGroup>
    <None Include="App.config">
      <SubType>Designer</SubType>
      <TransformOnBuild>true</TransformOnBuild>
    </None>
    <None Include="App.Debug.config">
      <DependentUpon>App.config</DependentUpon>
      <IsTransformFile>True</IsTransformFile>
      <SubType>Designer</SubType>
    </None>
    <None Include="App.Release.config">
      <DependentUpon>App.config</DependentUpon>
      <IsTransformFile>True</IsTransformFile>
      <SubType>Designer</SubType>
    </None>
  </ItemGroup>

made all the difference for me.

[sanddigital]

I have been experiencing this problem on a number of different machines. I have tried the solution that CThuleHansen has suggested:

Simply change v2.5.10.2 to v2.5.10.3 in the sc-MSBuildLibPathLocal in the "Project/Properties/SlowCheetah/SlowCheetah.Transforms.targets" file

Works a treat.

[GiscardBiamby]

I was having this same problem for my build running in TeamCity with VS2012 (but it worked fine on my local machine using VS2013).

CThuleHansen's solution worked for me.

[jochenvangasse]

I'm experiencing the same issue on machines that don't have the VS Extension installed. On machines that do have the extension installed, all is well.

Is the extension required/supposed to be installed?

[medianick]

For me, App.config files were not transforming at all (using 2.5.10.3) until I swapped the order of the SlowCheetah PropertyGroup and Import statements in my .csproj files. That fixed the problem locally but builds failed on our build server until I applied CThuleHansen's solution, which was to update Properties\SlowCheetah\SlowCheetah.transforms.targets from this:

<sc-MSBuildLibPathLocal Condition=" '$(sc-MSBuildLibPathLocal)'=='' ">$(LocalAppData)\Microsoft\MSBuild\SlowCheetah\v2.5.10.2\</sc-MSBuildLibPathLocal>

To this:

<sc-MSBuildLibPathLocal Condition=" '$(sc-MSBuildLibPathLocal)'=='' ">$(LocalAppData)\Microsoft\MSBuild\SlowCheetah\v2.5.10.3\</sc-MSBuildLibPathLocal>

Seemingly, it was picking up an older SlowCheetah file from somewhere without this.

[samunro]

DELUXEnized's solution worked for me and is simpler than editing the targets file. Just be sure to repeat this procedure on all machines and for all users that have the problem. This is his solution in a nutshell.

Delete all subfolders of the following folder.

\AppData\Local\Microsoft\MSBuild\SlowCheetah\

Our TFS build server had the same problem however this fix did not help. There, I copied the contents of this folder.

\AppData\Local\Microsoft\MSBuild\SlowCheetah\v2.5.10.2

Into the following folder - it was referenced in the error returned from the build server. You may need to swap NetworkService for something else depending on how your build server is configured.

C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Microsoft\MSBuild\SlowCheetah\v2.5.10.2

[Hildesheim]

@medianick/@CThuleHansen's solution worked for me when having the problem in TeamCity. Thanks! :-)

[TheBeardedLlama]

Hi guys, have a look at my pull request #137 I think I figured out why we're having this problem.

[ccoleHcg]

Visual Studio 2010. When I ran my console app, my app.config did not change per what the preview described. I installed NuGet, but that didn't help, so I'm not sure if that was necessary to get at the solution. What fixed it was C0BR4cH solution above. I added the line that was missing to the .csproj file, then everything worked. Thank you, C0BR4cH!!!!!

[tillig]

I also ran into this just now in VS2013. I don't have any extension installed, just using SlowCheetah from NuGet. The solution from @mharen fixed it for me.

[michaelvolz]

The problem still exists and as @tillig mentioned, the solution from @mharen did the trick. Thanks a lot!

https://github.com/sayedihashimi/slow-cheetah/issues/114#issuecomment-28297255

[leniel]

I also got this error right now in Visual Studio 2013 Update 2 while upgrading SlowCheetah from v2.5.10.2 to v2.5.10.4.

Here's the error:

Error   47  The "TransformXml" task could not be loaded from the assembly C:\Users\Leniel\AppData\Local\Microsoft\MSBuild\SlowCheetah\v2.5.10.4\Microsoft.Web.XmlTransform.dllSlowCheetah.Xdt.dll. 
Could not load file or assembly 'file:///C:\Users\Leniel\AppData\Local\Microsoft\MSBuild\SlowCheetah\v2.5.10.4\Microsoft.Web.XmlTransform.dllSlowCheetah.Xdt.dll' or one of its dependencies. 
The system cannot find the file specified. 
Confirm that the <UsingTask> 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.   Vortex.CBA.Portal

I have 3 folders in C:\Users\Leniel\AppData\Local\Microsoft\MSBuild\SlowCheetah:

• v1
• v2.5.10.2
• v2.5.10.4

The only difference in content is that v1 has an additional file: Install-Manifest.xml

I applied the fix by @mharen and now I can build the ASP.NET MVC 5 app just fine.

Here is the <PropertyGroup Label="SlowCheetah"> before applying the fix. Maybe it can help...

 <PropertyGroup Label="SlowCheetah">
    <SlowCheetahToolsPath>$([System.IO.Path]::GetFullPath( $(MSBuildProjectDirectory)\..\packages\SlowCheetah.2.5.10.4\tools\))</SlowCheetahToolsPath>
    <SlowCheetah_EnableImportFromNuGet Condition=" '$(SC_EnableImportFromNuGet)'=='' ">true</SlowCheetah_EnableImportFromNuGet>
    <SlowCheetah_NuGetImportPath Condition=" '$(SlowCheetah_NuGetImportPath)'=='' ">$([System.IO.Path]::GetFullPath( $(MSBuildProjectDirectory)\Properties\SlowCheetah\SlowCheetah.Transforms.targets ))</SlowCheetah_NuGetImportPath>
    <SlowCheetahTargets Condition=" '$(SlowCheetah_EnableImportFromNuGet)'=='true' and Exists('$(SlowCheetah_NuGetImportPath)') ">$(SlowCheetah_NuGetImportPath)</SlowCheetahTargets>
</PropertyGroup>

This is how it is now:

 <PropertyGroup Label="SlowCheetah">
    <sc-MSBuildLibPathLocal Condition="'$(sc-MSBuildLibPathLocal)'==''">
        $(MSBuildProjectDirectory)\..\packages\SlowCheetah.2.5.10.4\tools\
    </sc-MSBuildLibPathLocal>
</PropertyGroup>

---

Am I crazy or this is the culprit?

`Microsoft.Web.XmlTransform.dllSlowCheetah.Xdt.dll``

Would this be just something spit by Visual Studio or it really tried to load that thing? :D I don't think so.

[sayedihashimi]

I just updated to 2.5.10.5, can you try again?

On Sat, May 17, 2014 at 6:10 PM, Leniel Macaferi notifications@github.comwrote:

I also got this error right now in Visual Studio 2013 Update 2 while upgrading SlowCheetah from v2.5.10.2 to v2.5.10.4.

Here's the error:

Error 47 The "TransformXml" task could not be loaded from the assembly C:\Users\Leniel\AppData\Local\Microsoft\MSBuild\SlowCheetah\v2.5.10.4\Microsoft.Web.XmlTransform.dllSlowCheetah.Xdt.dll. Could not load file or assembly 'file:///C:\Users\Leniel\AppData\Local\Microsoft\MSBuild\SlowCheetah\v2.5.10.4\Microsoft.Web.XmlTransform.dllSlowCheetah.Xdt.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. Vortex.CBA.Portal

I have 3 folders in C:\Users\Leniel\AppData\Local\Microsoft\MSBuild\SlowCheetah:

• v1
• v2.5.10.2
• v2.5.10.4

The only difference in content is that v1 has an additional file: Install-Manifest.xml

put piche

I applied the fix by @mharen https://github.com/mharen and now I can build the ASP.NET MVC 5 app just fine.

Here is the before applying the fix. Maybe it can help...

$([System.IO.Path]::GetFullPath( $(MSBuildProjectDirectory)..\packages\SlowCheetah.2.5.10.4\tools)) true $([System.IO.Path]::GetFullPath( $(MSBuildProjectDirectory)\Properties\SlowCheetah\SlowCheetah.Transforms.targets )) $(SlowCheetah_NuGetImportPath)

— Reply to this email directly or view it on GitHubhttps://github.com/sayedihashimi/slow-cheetah/issues/114#issuecomment-43428606 .

[sayedihashimi]

FYI this problem should be fixed for VS and CI scenarios in 2.5.10.5. Sorry about 2.5.10.4 that had a bug in it.

[leniel]

WOW... fast response and NuGet package. :)

Updated to 2.5.10.5. After building the project it created the folder 2.5.10.5 and the project compiled just fine... now it WORKS!

Thanks Sayed. :+1:

[sayedihashimi]

OK thanks for verifying. Closing.

[sstreiger]

The first version to install on this machine of slow-cheetah 2.5.10.5 There are 3 projects in the solution that use the Slow-cheetah packages and they refer to version="2.5.10.3".

While building it´s looking for the slow-cheetah dlls at folder v2.5.10.2, that exists, but is empty. I can remove and readd the packages if that will solve the issue, but I´m concerned on what would happen with other installations, when future versions of the Slow-cheetah extensions are released.

[sayedihashimi]

You should update the nuget packages to the latest versions. I'm not following your concerns.

[sstreiger]

First, I want to let you know how much I appreciate the time & effort that guys like you devote to build such useful tools and to help troubleshooting other devs mistakes!

OK, I updated the packages and everything worked OK. :-)

What I´m concerned is if this packages updates may require other dev machines to update their slow-cheetah extension to be able to compile and run.

[sayedihashimi]

@sstreiger since the logic is contained in the NuGet package, it travels with the project. No need to update local tools.

[sayedihashimi]

FYI for compilation users don't need to install the SlowCheetah Visual Studio extension, just the NuGet package into the project. You just need the Visual Studio extension to _Add Transforms_ to a project. Running transforms happens at build and uses .targets in the NuGet package so no need for all users to install the extension.

[wilson0x4d]

we don't say thanks enough, but I have to note that every time I've had a concern with SlowCheetah you've consistently managed to find a solution. i am still using slowcheetah today, depending on the project at hand, and wanted to say thanks for all the hard work you put in (and may even continue to put in) on this tooling.

i wish that Microsoft could pull this in as first-class functionality within Visual Studio. this fills an important role for many devs out there, and there's a huge void that requires manual tooling without it.

THANK YOU.