Closed ghost closed 7 years ago
The short answer is that this is only the tip of the iceberg.
I could get past this error by removing the Microsoft.Build.Utilities.v4.0
reference,
and adding instead the Microsoft.Build.Utilities
NuGet dependency.
That solved the issue in the simplified reproducer I posted here, but in my real application I got further strange errors like:
error MSB4018: System.IO.FileNotFoundException: Could not load file or assembly 'System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. The system cannot find the file specified.
This and the original errors are just a symptom of a bigger problem: it's not safe to execute via dotnet
applications that were built in <=VS2015 targeted for .NET Framework instead of .NET Core. When executed by dotnet
, the runtime has a subset of .NET Framework features, and when the application tries to use something not in the runtime, it will of course crash. In my example my code is some Task
implementations compiled with VS2015, executed as part of dotnet msbuild
.
The solution seems to be to convert my .NET Framework application to .NET Core.
Your best option probably is multitargeting your tasks to a version of .net standard / .net core and .net framework like this and then use a different assembly based on $(MSBuildRuntimeType)
(UsingTask example.
@dasMulli Looks as if both of the links provided in your latest comment are now broken. Do you have updated links for your suggestion?
too bad.. updated them to permalinks
Hello, is there a fix for this? There are a lot of nuget DLLs that don't work int dotnet because of this.
I was able to dig through: https://github.com/aspnet/EntityFrameworkCore/issues/8336
And add this:
<PackageReference Include="Xamarin.Forms" Version="2.4.0.38779">
<ExcludeAssets>build</ExcludeAssets>
</PackageReference>
I could build originally via msbuild, but not dotnet build due to this, which caused issues in VSTS for building. After adding this, it got farther, but since I have xaml pages in there it seems to fail to generate anything :(
i keep getting:
/Users/jassim/.nuget/packages/xamarin.forms/2.4.0.280/build/netstandard1.0/Xamarin.Forms.targets(3,3): Error MSB4062: The "Xamarin.Forms.Build.Tasks.FixedCreateCSharpManifestResourceName" task could not be loaded from the assembly /Users/jassim/.nuget/packages/xamarin.forms/2.4.0.280/build/netstandard1.0/Xamarin.Forms.Build.Tasks.dll. Confirm that the
Same problem while loading C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Xamarin\iOS\Xamarin.iOS.Tasks.dll
@dasMulli
Your best option probably is multitargeting your tasks to a version of .net standard / .net core and .net framework ....
Just one little question:
Why use multi-targeting here? Isn't using netstandard20
enough?
It should run on all platforms using netstandard20
only?!
Why use multi-targeting here? Isn't using netstandard20 enough? It should run on all platforms using netstandard20 only?!
At least at the time of writing (2017) i believe VS didn't carry all necessary forwarding assemblies to load and run netstandard2.0 dlls. I believe this has now been mostly done, maybe @rainersigwald can comment on that.
(Basically when you reference a .NET Standard assembly / project, the build system will add some additional dlls for older versions of .NET Framework. Applications not built with this logic needed to add these assemblies manually in order to load .NET Standard assemblies).
Also do note that some Tasks like(d) to do some form of isolation using AppDomain on .NET Framework or AssemblyLoadContext on .NET Core so they needed to target both frameworks in order to use these specific APIs (e.g. to load a different version of Newtonsoft.Json than is included in Visual Studio).
.NET 4.7.2+ (which is now required by MSBuild) does handle netstandard2.0
assemblies pretty well. If your task has no dependencies, you can usually get away with just a .NET Standard implementation. When referencing other libraries, especially but not limited to native code, things can get hairy, and multitargeting is often still required.
It seems that the dependencies of a task DLL built with VS2015 cannot be loaded when using those tasks in
dotnet msbuild
. Here's a reproducer using simple dummy files.A primitive custom task,
SimpleTaskThatExtends
:A primitive targets file using the above task:
msbuild
works:I get:
The same command but run through
dotnet
doesn't work:I get:
If instead of extending
Task
inMicrosoft.Build.Utilities
I implementITask
inMicrosoft.Build.Framework
, then it works because it doesn't need to loadMicrosoft.Build.Utilities.v4.0
.I tried copying
Microsoft.Build.Utilities.Core.*
(.dll
and.xml
) in the same directory as the task dll. I tried both thenet46
andnetstandard1.3
versions. But the output is exactly the same.I've read #658 and I was under the impression that the problem there and in #858 was fixed in
15.1.1012
, which is the version I have (as you can see in the last output).The bigger picture is that I have a task library that I would like to use in the builds of both VS2015 and .NET Core projects. I would rather not have two versions of the tasks. Is there something fundamentally wrong with that?