search

dotnet / project-system

The .NET Project System for Visual Studio
MIT License
967 stars 385 forks source link

Unmanaged DLLs of a nuget package show up in the root .csproj in vs2017 Solution Explorer #3302

Closed Petermarcu closed 6 years ago

Petermarcu commented 6 years ago

@leblancdavid commented on Fri Feb 16 2018

We have a nuget package which consumes unmanaged dlls that need to be copied to the output directory. That seems to work fine. However when adding a reference to the package for a .csproj in Visual Studio 2017, the dlls show up in the root directory of the .csproj in the Solution Explorer. I can't seem to find a way to hide those, I'm not sure if it's an issue with our nuget package or vs2017. Has anyone experienced this or know what could cause that?

@cdrnet commented on Sat Feb 17 2018

Yes, I'm seeing this as well.

In my case, this is related to an ItemGroup along the lines of the following being added through a .targets file, for example as in the MathNet.Numerics.MKL.Win NuGet package:

<ItemGroup>
  <None Include="..">
    <Link ../>
    <CopyToOutputDirectory../>
  </None>
</ItemGroup>

Such <None> items used to be hidden in earlier VisualStudio versions, now it seems they always show up. Should such libraries be packaged differently now?

@Petermarcu commented on Tue Feb 20 2018

@Pilchie do you know which repo this should be tracked in?

@Pilchie commented on Thu Feb 22 2018

dotnet/project-system is probably the right repo.

@cdrnet can you try adding a <Visible>False</Visible> metadata to your <None Include?

Also, are these packages being referenced from SDK style projects, or regular ones? If regular, using packages.config or <PackageReference> (or project.json)?

@dsplaisted commented on Thu Feb 22 2018

This was intentional, I think. I don’t have the details immediately available but I can probably find them.

@cdrnet commented on Thu Feb 22 2018

In my case, with VS 15.6.0 Preview 5.0:

@cdrnet commented on Thu Feb 22 2018

If I add <Visible>False</Visible>, then the files no longer show up, but their folders are still visible as empty link folders (in my case the files are structured in an x64 and an x86 folder, using %(RecursiveDir) in the link). So it does not really help much to remove the noise.

cdrnet commented 6 years ago

Example project where the files and folders are visible: https://github.com/mathnet/mathnet-numerics/blob/master/examples/netcore20-console-csharp/netcore20-console-csharp.csproj

Pilchie commented 6 years ago

@dsplaisted if you could dig up the details you mentioned, I'd appreciate it.

Pilchie commented 6 years ago

@davkean or @lifengl - any ideas here?

lifengl commented 6 years ago

That is the side effect of adding path to all external items in the .Net Core SDK .props/.targets file (to show external globbings in the project automatically). I think there is a way suppress it for some items.

Pilchie commented 6 years ago

Ping @dsplaisted do you have any details on this?

dsplaisted commented 6 years ago

IIRC, the csproj.dll project system hides all items from solution explorer that are not directly defined in your project file (ie if they’re from an imported .props or .targets file they won’t show up).

In order to support globs outside of the project cone (ie ), we decided that CPS should show items outside the project cone if they have Link metadata defined on them. That is why the behavior is different for this package for SDK-style projects. The solution is to set Visible metadata to false on these items.

The SDK also automatically sets the Link metadata on items outside the project cone. That affects some NuGet packages, but not MathNet.Numerics.MKL.Win, since that package explicitly sets the Link metadata.

dsplaisted commented 6 years ago

If I add <Visible>False</Visible>, then the files no longer show up, but their folders are still visible as empty link folders (in my case the files are structured in an x64 and an x86 folder, using %(RecursiveDir) in the link). So it does not really help much to remove the noise.

@lifengl This sounds like it might be a bug in CPS

Pilchie commented 6 years ago

Thanks @dsplaisted - @lifengl should we file a VSTS bug on CPS for the folder issue?

lifengl commented 6 years ago

Yes, that is our bug. Please open a bug...

Sent from my phone

On Mar 2, 2018, at 11:35 AM, Kevin Pilch notifications@github.com<mailto:notifications@github.com> wrote:

Thanks @dsplaistedhttps://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdsplaisted&data=02%7C01%7C%7C25e451e0bd7145ea0f5008d58074c7ac%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636556161401787877&sdata=sTizBzoZsFGSetnbe2yVkrWKIRcyocFAkXf%2BNBM6mpA%3D&reserved=0 - @lifenglhttps://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flifengl&data=02%7C01%7C%7C25e451e0bd7145ea0f5008d58074c7ac%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636556161401787877&sdata=u9QRd5TxAXfoLOATNS4jR3ZmInZZD2haYc272d8%2FpK8%3D&reserved=0 should we file a VSTS bug on CPS for the folder issue?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdotnet%2Fproject-system%2Fissues%2F3302%23issuecomment-370029242&data=02%7C01%7C%7C25e451e0bd7145ea0f5008d58074c7ac%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636556161401787877&sdata=lQotxz2ABjwqE%2BUUBmfBf8ScOMRB3r2uOaTHVzpJ2OI%3D&reserved=0, or mute the threadhttps://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FALGWwqTlCL-ywszsoEEGKCOdSUkPdY6Qks5taZ8JgaJpZM4SP049&data=02%7C01%7C%7C25e451e0bd7145ea0f5008d58074c7ac%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636556161401787877&sdata=7xRuRJf%2FoecxDGjtV0UzJ2gA1ykgnwG2KYnFSVhcuZU%3D&reserved=0.

Pilchie commented 6 years ago

Filed internal issue 577356 to track. Going to close this as external.

jakehockey10 commented 6 years ago

Could you please update this with any updates to the ticket that can't be tracked by those who don't have access?

davkean commented 6 years ago

@jakehockey10 If you file a developer community item (Help -> Send Feedback -> Report a Problem) I'll dup the internal bug against it so that you can track it,

jakehockey10 commented 6 years ago

@davkean thanks!

https://developercommunity.visualstudio.com/content/problem/215427/unmanaged-dlls-of-a-nuget-package-show-u-in-the-ro.html

davkean commented 6 years ago

Done. Sorry for the boilerplate comment, it automatically added it when I associated the internal bug with the feedback item.

jakehockey10 commented 6 years ago

no problem, thanks for doing that @davkean

alexanderkozlenko commented 6 years ago

Including this piece of MSBuild script in a project can serve as a temporary workaround for hiding empty folders with invisible None items from the project tree:

<ItemGroup>
  <NoneInvisible Include="@(None->WithMetadataValue('Visible', 'false'))" />
  <None Remove="@(NoneInvisible)" />
</ItemGroup>
<Target Name="IncludeNoneInvisible" BeforeTargets="PrepareForBuild">
  <ItemGroup>
    <None Include="@(NoneInvisible)" />
  </ItemGroup>
</Target>
thomaslundgaard commented 5 years ago

Any news on this?

Kryptos-FR commented 4 years ago

One year later, several iteration of Visual Studio and it is still an issue. I have a external package which I don't have any control upon that adds more than 60 files which all show up on the tree. It makes working with that particular project very unpleasant.

image

There should be an option on the package reference to hide imported items.

drewnoakes commented 4 years ago

Relates to #6290.

davkean commented 3 years ago

To follow up, this has been fixed and is available in the latest ~16.8 Preview~.

davkean commented 3 years ago

Correction; the fix will be in 16.9 Preview 2 when it releases.

greg-stein commented 1 year ago

Hello there. Sorry for necroposting.

I have a project that uses some nuget package with native DLLs. After nuget installation the file that is included into csproj is this:

<ImportGroup Label="ExtensionSettings">
    <Import Project="..\packages\AlpaoSdk.3.8.1.249\build\native\AlpaoSdk.targets" Condition="Exists('..\packages\AlpaoSdk.3.8.1.249\build\native\AlpaoSdk.targets')" />

The contents of the file above are:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" >
  <ItemDefinitionGroup>
    <ClCompile>
      <AdditionalIncludeDirectories>$(MSBuildThisFileDirectory)..\..\build\native\include\;%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>
      <PreprocessorDefinitions>HAS_ALPAOSDK;%(PreprocessorDefinitions)</PreprocessorDefinitions>
    </ClCompile>
  </ItemDefinitionGroup>

  <ItemDefinitionGroup>
    <Link>
      <AdditionalLibraryDirectories>$(MSBuildThisFileDirectory)..\..\build\native\$(Platform)\;%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories>
      <AdditionalDependencies>asdk.lib;%(AdditionalDependencies)</AdditionalDependencies>
      <DelayLoadDLLs>ASDK.dll;%(DelayLoadDLLs)</DelayLoadDLLs>
    </Link>
  </ItemDefinitionGroup>

  <ItemGroup>
    <AlpaoFiles Include="$(MSBuildThisFileDirectory)..\..\build\native\$(Platform)\*.dll" />
    <AlpaoFiles Include="$(MSBuildThisFileDirectory)..\..\build\native\*.dat" />
    <None Include="@(AlpaoFiles)" Visible="False">
      <Visible>False</Visible>
      <Link>%(FileName)%(Extension)</Link>
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
  </ItemGroup>    
</Project>

Tried to add Visible=False as an element and as attribute as you can see neither worked. I end up with bunch of files in my SolutionExplorer.

VS22, Version 17.6.2, latest as for today. Old-style csproj.

Any clue what could be done?

drewnoakes commented 1 year ago

@greg-stein please open a feedback ticket. You're using old style projects which are not owned by this repo or team. A feedback ticket can be routed to the correct people. Thanks.