Here's my experience as a consultant who has worked with several .Net shops:

A significant percentage of .Net teams (in more enterprisey companies) have tech teams who haven't seen anything other than Windows. Deploying on Linux gets shot down in meetings by senior decision-making folks who again have seen only Windows. It's a bit of self-preservation, plus fear of the unknown.

Not necessarily lambda candidates but from what I have seen: COM dependency, or native specialised assemblies (in my case math libraries, internal enterprise components that aren’t under development anymore), anything to do with system.drawing. The crypto library is also very integrated with windows, .net core only partially implemented the API.

AFAIK System.Drawing has been separated out adequately in Core?

System.Web is what comes to mind as a potential problem for a move like this, though.

>What dependencies do you imagine code running in lambdas would have that preclude Linux as a deployment candidate?

The context was "Shit-ton of .Net running in on-prem corporate environments still", not code already running in a Lambda. There are plenty of Windows dependencies/assumptions that are not GUI code. Porting a .Net service, for example, which would be pretty common. And just lots of mundane stuff that's still work, like logging, file locations, etc.

The TCP and socket APIs have significantly different async behavior. Double that if you want to cancel anything.

(That's the first thing I tried cross-platform. So maybe just my bad luck, but I have doubts everything will work smoothly.)