Closed jeffaries closed 4 years ago
You'll need to use the netstandard build. I don't know if we have that in the nuget package but you can build locally.
On Tue, Apr 28, 2020, 1:17 PM Jeff Gueldre notifications@github.com wrote:
Hi, I try to deploy my project in Linux based Docker image. My project is targeting dotnet core 3.1 It seems that there is a dependency that is preventing from using CoreWF in this configuration.
It was not possible to find any compatible framework version The framework 'Microsoft.WindowsDesktop.App', version '3.1.0' was not found.
- No frameworks were found.
You can resolve the problem by installing the specified framework and/or SDK.
I noticed a dependency to System.Windows.Extensions... could it be the reason, and could it be avoided?
Thank you
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/UiPath-Open/corewf/issues/116, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAWZC7KONBG4F6EIK5GASCLRO42W5ANCNFSM4MTEQYNQ .
I have rebuilt a nuget package with netstandard build only. I have created a library with netstandard framework. This library is referencing the nuget package. I have created a .net core 3.1 console app that is launching a test in my library... All fine when launching directly the app. But same error when trying to start in Docker... What didn't I understand?
The dependency on System.Windows.Extensions is only in the netcoreapp3.1 target. It's included automatically when using that target framework. I think what's happening is that NuGet is trying to match the framework from your console app to the reference to CoreWf. There doesn't seem to be a way to force the reference to use the netstandard version (thread).
The best way to fix this is for us to create two packages: one for netstandard and one for netcore. Then if you're on non-windows platforms, you can target the netstandard version. You can work around this by building CoreWf locally only targeting netstandard. Then reference the assemblies directly:
<ItemGroup>
<Reference Include="System.Activities">
<HintPath>..\corewf\src\CoreWf\bin\Debug\netstandard2.0\System.Activities.dll</HintPath>
</Reference>
<Reference Include="System.Xaml">
<HintPath>..\corewf\src\CoreWf\bin\Debug\netstandard2.0\System.Xaml.dll</HintPath>
</Reference>
</ItemGroup>
This may solve it but I'm noticing that sometimes the System.Xaml.dll from Microsoft.WindowsDesktop.App gets pulled instead. We may have to change the name of our version of System.Xaml so that this doesn't happen.
That's by design. You cannot target 3.1 on Linux. We'll probably have a different approach in .Net 5.
If for some reason you must, you can always reference CoreWf indirectly, through a library that targets .Net Standard.
@jeffaries If I understand you correctly, you seem to be saying that you've used the workaround I described above. While I haven't tried that (our tests simply target netcoreapp2.1 on Linux), I don't see why it wouldn't work. Perhaps try it with some test projects. Going forward we will have a portable target for .Net 5 and a Windows only .Net 5 target.
Hi, I try to deploy my project in Linux based Docker image. My project is targeting dotnet core 3.1 It seems that there is a dependency that is preventing from using CoreWF in this configuration.
I noticed a dependency to System.Windows.Extensions... could it be the reason, and could it be avoided?
Thank you