,
5 tweets,
2 min read
Read on Twitter
Tip: the "dotnet depends" global tool is awesome for figuring out what your dependencies are doing up and down the tree: nuget.org/packages/dotne…
For example, "what's pulling this in?" is quick to figure out with the tool:
For example, "what's pulling this in?" is quick to figure out with the tool:
To be fair, I always knew System.Drawing on a server would bite us in the ass *eventually*...I was just hoping eventually was later. Time to pay the piper.
Well if I solve that problem then it's System.Data.Common - fighting more with in-proc hosting tomorrow it is.
Well that was fun. It turns out that the reason this works in the debugger but not runtime is F5 in Visual Studio *changes folder permissions* so that the app pool can load assemblies at runtime from your NuGet cache. See how it adds the individual app pool here?
Fix is: granting IIS_IUSRS access to the NuGet package cache fixes it globally.
We're going to add this to our local dev setup tooling, but given the error message is not helpful debugging this at all...we'll file some issues to improve it.
We're going to add this to our local dev setup tooling, but given the error message is not helpful debugging this at all...we'll file some issues to improve it.
