Open handerss-spotfire opened 2 years ago
The solution of setting PrivateAssets
to compile
to protect against transitive dependencies is suggested by @nkolev92 here: https://github.com/dotnet/sdk/issues/11803#issuecomment-744729221
For our use case this works well except for the fact that the resulting deps.json
files sometimes contain ".Reference" entries which break at runtime. This issue is one such reproducible case, but unfortunately we get these additions even without CopyLocalLockFileAssemblies
. Is there anyway to turn this type of behavior off in general?
Is PrivateAssets=compile
+ DisableTransitiveProjectReferences
the best way to protect against compiling against transitive dependencies.
This issue is one such reproducible case, but unfortunately we get these additions even without CopyLocalLockFileAssemblies. Is there anyway to turn this type of behavior off in general?
Not sure, @dsplaisted do you have any guidance here?
Setting
CopyLocalLockFileAssemblies
causes runtime exceptions for projects wherePrivateAssets
is set tocompile
. This is because the resulting.deps.json
file will contain a ".Reference" entry which does not contain the necessary runtime dll.Example
This project uses a facade library which is meant to wrap some API (in this case
System.Security.Cryptography.ProtectedData
). To protect consuming projects from the wrapped library the package reference has its private assets set to compile. This works well unless the Facade library adds theCopyLocalLockFileAssemblies
and sets it true. This addition causes the consuming program's.deps.json
to get a reference entry added, in this case it'sSystem.Security.Cryptography.ProtectedData.Reference/5.0.0.0
, which in turn results in the program crashing with a runtime error.The example program below can be run with
dotnet run --project ./Transitive/Transitive.csproj
and results in the following output:Facade/Facade.csproj
Facade/Facade.cs
Transitive/Transitive.csproj
Transitive/Program.cs