Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing dependency when building a Docker image. #116

Closed
jeffaries opened this issue Apr 28, 2020 · 6 comments
Closed

Missing dependency when building a Docker image. #116

jeffaries opened this issue Apr 28, 2020 · 6 comments
Labels

Comments

@jeffaries
Copy link

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

@dmetzgar
Copy link
Contributor

dmetzgar commented Apr 28, 2020 via email

@jeffaries
Copy link
Author

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?

@dmetzgar
Copy link
Contributor

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.

@lbargaoanu
Copy link
Contributor

lbargaoanu commented Apr 29, 2020

That's by design. You cannot target 3.1 on Linux. We'll probably have a different approach in .Net 5.

@lbargaoanu
Copy link
Contributor

If for some reason you must, you can always reference CoreWf indirectly, through a library that targets .Net Standard.

@lbargaoanu
Copy link
Contributor

lbargaoanu commented Apr 29, 2020

@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.

@UiPath UiPath deleted a comment from watertree Jun 16, 2020
@UiPath UiPath locked as resolved and limited conversation to collaborators Jun 16, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants