Yair Halberstadt
Yair Halberstadt

Reputation: 6861

Purpose of Accord.Dll.Config

I noticed this in a csproj for a project:

  <ItemGroup Condition="'$(MSBuildThisFileDirectory)' != '' And HasTrailingSlash('$(MSBuildThisFileDirectory)')">
    <Content Include="$(MSBuildThisFileDirectory)..\packages\Accord.3.5.0\build\Accord.dll.config">
      <Link>Accord.dll.config</Link>
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </Content>
  </ItemGroup>

It was causing the build to fail, as the config could not be found in the packages directory when restoring using dotnet restore

The Accord.dll.config looks like this on github:

<!-- Mono library mapping mechanism -->
<configuration>
  <dllmap dll="ntdll.dll">
    <dllentry os="linux,solaris,freebsd" dll="libc.so.6"/>
  </dllmap>  
</configuration>

I presume that means that if I don't want to run my project on mono, I can safely delete this?

Upvotes: 0

Views: 470

Answers (1)

zivkan
zivkan

Reputation: 15081

The title of your question is "Purpose of Accord.Dll.Config", and given the content you copied in your question, the purpose is to map any P/Invoke using "ntdll.dll" to "libc.so.6" on Linux, Solaris and FreeBSD. So, on one hand, sure, if you're not going to run your app on these platforms you probably don't need this file.

However, I'm confused why it's in your project at all. The package doesn't appear to modify your csproj, so it appears someone manually added it to the csproj. Instead, the package contains a file build/accord.targets which contains the same contents. Considering you appear to be using packages.config, NuGet should have modified the project to import the accord.targets file, with a condition saying when the file exists, so that restore succeeds, but also adding a target saying that if the file does not exist on build, fail the build with a message saying that packages have not been restored.

Given your csproj appears to have been manually modified, if your project is under source control you could consider looking up who modified the csproj in this way and ask them about it. But you're using version 3.5.0 of the package, and version 3.6.0 was released on the 7th of July 2017, meaning your project is probably at least 2 years old and the details about why the csproj was edited might be forgotten by now.

Anyway, I suggest yes, delete that item group from your csproj. Not because you don't run on mono, but because it never should have been added to your project in the first place.

Upvotes: 1

Related Questions