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

SciSharp.TensorFlow.Redist package is not copying tensorflow.dll to output directory. #361

Closed
Nucs opened this issue Aug 21, 2019 · 5 comments

Comments

@Nucs
Copy link
Member

commented Aug 21, 2019

SciSharp.TensorFlow.Redist-Windows-GPU and SciSharp.TensorFlow.Redist nuget packages are not performing copy correctly in cases when the project is:

  1. targeting netstandard
  2. targeting netcore (need to verify)
  3. Located in an unusual location relative to the solution directory which contains the folder packages folder.

The redists fail to copy tensorflow.dll to output directory because it can't find /packages folder.

When a project targets netstandard, ../../packages does not exist.
Instead it uses global nuget cache folder: %userprofile%\.nuget\packages

Here is the msbuild file that takes care of resolving the copying:

scisharp.tensorflow.redist.1.14.0.nupkg\build\netstandard2.0\SciSharp.TensorFlow.Redist.props

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

  <!--
  NuGet packages.config doesn't support native assemblies automatically,
  so copy the native assemblies to the output directory.
  -->
  <ItemGroup Condition="Exists('packages.config') OR
                        Exists('$(MSBuildProjectName).packages.config') OR
                        Exists('packages.$(MSBuildProjectName).config')">
    <Content Include="$(MSBuildThisFileDirectory)\..\..\runtimes\win-x64\native\*.dll"
             Condition="'$(PlatformTarget)' == 'x64'">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <Visible>false</Visible>
      <Link>%(Filename)%(Extension)</Link>
    </Content>
    <Content Include="$(MSBuildThisFileDirectory)\..\..\runtimes\win-x86\native\*.dll"
             Condition="'$(PlatformTarget)' == 'x86'">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <Visible>false</Visible>
      <Link>%(Filename)%(Extension)</Link>
    </Content>
  </ItemGroup>

</Project>
@Nucs Nucs added the bug label Aug 21, 2019
@Nucs

This comment has been minimized.

Copy link
Member Author

commented Aug 21, 2019

Related issues, #340 #297

@chaami

This comment has been minimized.

Copy link

commented Aug 21, 2019

Hi,
My understanding is that the nuget default behavior when resolving dependencies is to install the packages in the global user repository.
Visual studio should be able to do what's needed when running/debugging to make the dlls available when needed, a copy being made only in cases of publish.
Are you specifying that your project is targeting the win-x64 runtime ?
Are you getting an error saying that the tensorflow.dll couldn't be found when attempting to run ?
Kind regards.

@Oceania2018

This comment has been minimized.

Copy link
Member

commented Aug 21, 2019

@chaami Thanks for contribution.

Do you change the name SciSharp.TensorFlow.Redist to SciSharp.TensorFlow-Cpu.Redist.
The script is original written by @harishsk.
Can you PR and I will assign @harishsk to review it.

@Nucs

This comment has been minimized.

Copy link
Member Author

commented Sep 24, 2019

This issue still persists.
You still can't use SciSharp.TensorFlow.Redist-Windows-GPU and SciSharp.TensorFlow.Redist for .netstandard projects that are set to Output type: Console Application.

@Nucs Nucs reopened this Sep 24, 2019
@Nucs

This comment has been minimized.

Copy link
Member Author

commented Sep 26, 2019

After looking into it further, I think this issue is irrelevant as explained here:

It doesn't make sense to create a .NET Standard console app.

You can think of .NET Standard like you would an interface in C#. .NET Standard is an interface, then there's concrete implementations of it in .NET Framework, .NET Core and other platforms. .NET Standard makes sense for class libraries, but a console app needs to actually run on a specific concrete implementation.

Thus, there is no Visual Studio project template for .NET Standard console apps. You can create a console app for .NET Framework or .NET Core and then consume .NET Standard class libraries.

@Nucs Nucs closed this Sep 26, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.