Too many files in output directory

[EO3-Kopf]

Using the build tasks adds a lot of (unnecessary) files to the output directory:

• dSPACE.Runtime.InteropServices.dll
• Microsoft.Build.Tasks.Core.dll and all its dependencies

All this files have nothing to do with the COM-Server I am building and they are not needed to run it. Is there a way preventing these files to be copied to the output directory?

I assume they are put in the output directory because they are referenced by the dSPACE.Runtime.InteropServices.BuildTasks-package.

[EO3-Kopf]

Maybe you should add <PrivateAssets>all</PrivateAssets> to the <PackageReference Include="microsoft.build.tasks.core" Version="17.0.0" /> in dscom.build.csproj to prevent this behaviour?

[EO3-Kopf]

I managed to get the expected behaviour by deleting runtime; from the IncludeAssets.
Thus the reference in the .csproj file shall look like

    <PackageReference Include="dSPACE.Runtime.InteropServices.BuildTasks" Version="0.17.0" NoWarn="NU1701">
      <IncludeAssets>build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
      <PrivateAssets>all</PrivateAssets>
    </PackageReference>

instead of

    <PackageReference Include="dSPACE.Runtime.InteropServices.BuildTasks" Version="0.17.0" NoWarn="NU1701">
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
      <PrivateAssets>all</PrivateAssets>
    </PackageReference>

[marklechtermann]

Hi @EO3-Kopf, if you have a fix for the problem, feel free to submit a pull-request.
We would be happy about it :-)

[EO3-Kopf]

Hi @marklechtermann, I would if knew where / what to change. I think it has something to do with the publishing of the nuget package. Since I have not yet published on nuget.org I don't know how to influence the PackageReference. (The one shown at https://www.nuget.org/packages/dSPACE.Runtime.InteropServices.BuildTasks#package-reference contains runtime; And it is obviuosly the same reference that is added to the project file when installing this package. I don't know how to change this behaviour.) However I could do a pull request and change readme.md at the respective point; but this would only be a workaround.

[EO3-Kopf]

🤔 @marklechtermann, as it seems I am not allowed to create a new branch. At least I don't find the respective button here. How to create a pull request then?

[marklechtermann]

Hello @EO3-Kopf,

contributing to open source projects in GitHub is actually quite easy.
In most projects, such as dscom, you can not directly create a branch.
This is not desired for security reasons.
Instead you have to create a fork.
On the top right corner of the dscom github site you will find the button "Fork".
If you click on this button, you can create a fork.
This fork is then part of your account.
After the code change you can make a pull request, so that your fork is taken over into the main branch of dscom.

Here you can find more information:
https://www.freecodecamp.org/news/how-to-fork-a-github-repository

If you have any questions, please feel free to contact me.
You are also welcome to send me a direct message on twitter.
https://twitter.com/marklechtermann

[carstencodes]

Maybe you should add <PrivateAssets>all</PrivateAssets> to the <PackageReference Include="microsoft.build.tasks.core" Version="17.0.0" /> in dscom.build.csproj to prevent this behaviour?

In contrast to #145 and #146 this seems to be the correct solution for this. Following the NuGet Specification and the Microsoft Learning Center, it would be more correct and actually drop the dependencies.

I'll try myself to get more or less handy with this. In the end, removing the assets should not be the way.

[EO3-Kopf]

Yes, I think that might do the trick. Eliminating the cause is always better than mending the symptoms.

[SOsterbrink]

If I understand you correctly, the problem here was how the Build Task was included in the built project and not with the build task itself.
In that case this Issue can be closed and the Pull Request #145 can be abandoned, right?

Or did I misunderstand your discussion?

[carstencodes]

@SOsterbrink I think we can abandon the PR, but the issue still remains open. I'm currently updating the package references,

[carstencodes]

#150 was merged. The dependencies are no longer reflected to the nuspec file.