When we use dotnet cli to build a .NET Framework project we get the following error when including Esri.ArcGISRuntime library, error MSB4062: The "DeploymentTask" task could not be loaded from the assembly net461\Esri.ArcGISRuntime.LocalServices.BuildTasks.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. 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.
This error is due to the dotnet cli using .NET Core and not .NET Framework for it's build tasks. The dotnet cli can not load the .NET Framework 4.6.1 dependent libraries for the Esri.ArcGISRuntime.LocalServices to complete the Esri DeploymentTask. Looking at the NuGet package(Esri.ArcGISRuntime.LocalServices), there is both a .NET Standard 2.0 and a .NET Framework 4.6.1 version of Esri.ArcGISRuntime.LocalServices.BuildTasks. I believe you can remove the .NET Framework 4.6.1 version and just use the .NET Standard version because .NET Standard 2.0 is compatible with .NET Framework 4.6.1 https://dotnet.microsoft.com/en-us/platform/dotnet-standard.
I have tested this myself by manually replacing the .NET Framework 4.6.1 Esri.ArcGISRuntime.LocalServices.BuildTasks library with the .NET Standard version and it successfully ran without errors and produced the expected results. I tested it also with Visual Studio 2022 and it was error free in both cases and produced the same results before and after the experiment of replacing the library. I believe this is the solution for this issue.
Can you please update the packages to resolve this error?
Thanks
To highlight the issue, it's with the fact that dotnet CLI uses .NET Core/5/6/7 and not .NET Framework to run tasks. The Esri build tasks are built in .NET Framework 4.6.1 and .NET Standard 2.0 which allows for msbuild to use the .NET Framework version of Esri build task and dotnet build to use .NET Standard 2.0 when building a .NET Core/5/6/7 project. The issue comes in when building a .NET Framework project with the dotnet CLI, as the CLI uses the .NET Framework version of the Esri build task since it matches the project .NET version but dotnet CLI can't load and run the build task since it's running .NET Core/5/6/7 instead. If you build a .NET Core/5/6/7 project using dotnet build and Esri it will work since it will use the .NET Standard 2.0 library for the project which allows the build task work properly.
The simple solution is to remove the .NET Framework 4.6.1 version of the build task and use only the .NET Standard 2.0 version. That works for both MSBuild and dotnet CLI with any combination of .NET project types(.NET Framework or .NET Core/5/6/7) and is fully compliant with what Esri currently supports. While my testing with our projects shows that this method will work, it would obviously be recommended that Esri test this to ensure that I have not overlooked anything. Here's a link to Microsoft showing that .NET Standard 2.0 is fully compatible with .NET Framework 4.6.1 (https://dotnet.microsoft.com/en-us/platform/dotnet-standard). If you look at the source code, you will notice they are the same besides calls to Log.LogError have an extra parameter at the end which is Array.Empty<object>(), and the references are slightly different because of what is included and not included in .NET Framework/Standard. Those differences shouldn't cause any issues for anyone.
Building .NET Framework applications with the dotnet cli is not currently supported. Either port your application to .NET 6, or use MSBuild to compile your application from commandline.
Is there a particular reason you want to use "dotnet build" instead of "msbuild /t:Build" ?
Running into this problem today, you can get AddIn and Server Object Extensions builds for ArcMap to work on newer IDE's like VS2022 and Rider whose development environment default to the default SDK MSBuild.dll, but you have to select MSBuild.exe from the 2022 folder as your MSBuild version. The BuildTasks library does look like it could be compiled for .NET Standard 2.0, although not without some refactoring, which would probably play nicer with the SDK packaged MSBuild.dll's.
I think some motivation for this is due to the fact that you can use the newer SDK style project format on applications that target older frameworks which is sometimes required to get proper project configuration and newer features in the UI's to work. For homogeneities sake, adhering to using the dotnet build command also restores your packages by default, I know some pipelines build without restoring, but still. Thorn in the side from a devops perspective.
This was addressed in the 200.1 build of the localservices package, and you can now use "dotnet build" with .NET Framework apps that references this package.
wrt restoring, you can use "msbuild /restore project.csproj" to achieve the same thing.
I meant to clarify that this was for the Enterprise SDK, not the Maps SDK. This is the only post I could find that mentioned issues with the `.targets` not building properly for the correct reasons.
@DevinCarlson1 I suggest you post that limitation in the Pro SDK area, since they probably don't look in the Maps SDK forum.