You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Newer versions of rules_dotnet brought support for the "build" folder that some NuGet packages have. According to #369, this implementation was based on NETStandard.Library as an example of the expected directory structure (where dlls are under framework and lib/ref directories).
However, not all NuGet packages structure their "build" folder in the same way as NETStandard.Library, e.g. coverlet.collector and NUnit3TestAdapter have dlls directly under a framework directory and Microsoft.TestPlatform.TestHost has dlls under framework and architecture directories. rules_dotnet won't collect these dlls and therefore they won't be available to the build.
The text was updated successfully, but these errors were encountered:
I have a very naive suggestion for a workaround (at least for my purposes): Expose all the files of a NuGet package as a filegroup. This filegroup would exist alongside the other filegroups and would help enable the consumer to do whatever wonky custom thing they need to do when a more "official" solution is not available.
Newer versions of rules_dotnet brought support for the "build" folder that some NuGet packages have. According to #369, this implementation was based on NETStandard.Library as an example of the expected directory structure (where dlls are under framework and lib/ref directories).
However, not all NuGet packages structure their "build" folder in the same way as NETStandard.Library, e.g. coverlet.collector and NUnit3TestAdapter have dlls directly under a framework directory and Microsoft.TestPlatform.TestHost has dlls under framework and architecture directories. rules_dotnet won't collect these dlls and therefore they won't be available to the build.
The text was updated successfully, but these errors were encountered: