Fody: Fody does not work in the dotnet cli
I added Fody to a project created with dotnet new and set up my own FodyWeavers.xml. However, dotnet build fails with
/Users/yavorgeorgiev/.nuget/packages/fody/2.0.7/build/netstandard1.4/Fody.targets(53,5): error MSB4062: The "Fody.WeavingTask" task could not be loaded from the assembly /Users/yavorgeorgiev/.nuget/packages/fody/2.0.7/build/netstandard1.4/../../Fody.dll. Could not load file or assembly 'Microsoft.Build.Utilities.v4.0, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified. [/Users/yavorgeorgiev/Projects/foo/foo.csproj]
/Users/yavorgeorgiev/.nuget/packages/fody/2.0.7/build/netstandard1.4/Fody.targets(53,5): error MSB4062: 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. [/Users/yavorgeorgiev/Projects/foo/foo.csproj]
0 Warning(s)
1 Error(s)
According to https://github.com/dotnet/cli/issues/5457 it seems that a way to solve this would be to provide two sets of assemblies - one built with the regular .NET Framework and another built with .NET Core, and switch between the two based on the value of MSBuildRuntimeType.
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Reactions: 5
- Comments: 20 (11 by maintainers)
Commits related to this issue
- don't build when packing see Fody/Fody#330 — committed to tpluscode/NullGuard by tpluscode 7 years ago
OTOH one can use a combination of MSBuild and dotnet test --no-build. So, not really that important anymore to me since that’s a simple workaround.
I’d really like to see it working as well. While MSBuild can be used, there is another collateral: nunit tests won’t run because they run only using dotnet test which doesn’t work with fody due to this problem.
Any news on this? We are considering testing Fody out for one of our projects and this is unfortunately a showstopper for us.
Based on my understanding, I don’t see this thing would affect weaver implementations, but rather is isolated to the plumbing supported by the Fody engine, no? If so, it shouldn’t be a major effort to address.
That’s fine, I suppose, if they want to support
dotnet buildthey will have to opt-in by shipping assemblies for both runtimes. If they don’t care about .NET Core they will continue happily working on .NET Framework. But for weavers that want to support .NET Core and don’t mind shipping two sets of assemblies Fody’s lack of support for the .NET CLI is currently a blocker.@simoncropp, that my have been true back in June, but not any longer. 😃
@tpluscode i doubt many people are using dotnet build yet given it runs on .net core and is incompatible with many existing msbuild tasks
but to be fair msbuild from the command line still works
Wait, so any project that uses Fody will not build from the CLI? Sounds pretty important for anyone building in a CI pipeline 😉