Microsoft.Data.SqlClient is not compatible with AssemblyLoadContext unloading

[agocke]

See dotnet/runtime#31377 for context. The fundamental issue is that unloadability is based on GC references, so SqlClient containing a strong references via event handlers and similar. The suggested fix is that for callbacks like the TimerCallback in Microsoft.Data.SqlClient.SqlConnectionFactory, support for listening to the Unload event could be added and these roots could be cleared, so that the app could be unloaded.

[lcheunglci]

Thanks for identifying the issue. The MDS team is working on a new release. I believe someone will follow up with this issue as soon as it's out. In the meantime, is there a repro sample that I could use to try?

[Wraith2]

I have made some changes to help unloading in the past such as #913 but it needs a specific case to track into and isolate the roots. Without specific guidance on patterns that need to be followed to allow unloadability there's a lot of library to cover.

[agocke]

@janvorli might have some ideas since he investigated the original bug

[janvorli]

@Wraith2 I've put some guidelines on troubleshooting unloadability issues in the past: https://docs.microsoft.com/en-us/dotnet/standard/assembly/unloadability#troubleshoot-unloadability-issues. I would like to understand what additional details you'd like to get. I'd be happy to provide help with that.

[Wraith2]

I've followed the unloadability debugging process using windbg before. What I'm really looking for are design patterns that i can look for in the code which are likely to cause unload problems. Are there know things like timers for example that I can investigate without an example and determine if they need unload support adding.

[JRahnama]

@agocke thank you for opening the issue.
@Wraith2 thanks again for the support. Will you be looking into this issue?

[janvorli]

The things to look for are:

• TimerCallback instances referencing methods from the Microsoft.Data.SqlClient assembly
• GC handles and static members holding references to objects of types from the Microsoft.Data.SqlClient assembly.
• Threads executing code from the Microsoft.Data.SqlClient assembly at the unload time. E.g. threads that never exit and just loop forever.
• Async methods from the Microsoft.Data.SqlClient assembly that can be waiting for something to complete at the unload time.

It is difficult to create an exhaustive list, but these are likely to be the most frequent offenders.

[Wraith2]

@JRahnama yes I will look into this.
@janvorli that's the sort of information I was looking for. I appreciate that there can't be a definitive list.