Because .NET 5's PublishSingleFile loads assemblies in memory instead of from files, SQLProvider needs to be able to load the drivers from the memory as well.
The current driver resolution logic remains untouched, but if it fails to load the expected assemblies, we then try to load them from the AppDomain instead.
This requires the users of SQLProvider to ensure that their driver is loaded into the AppDomain before creating the context. I tried other ways, such as getting the referenced assemblies of the executing assembly, but it would not work with a solution where the executing assembly relies on another project for data access through SQLProvider, so simply using the AppDomain seemed like the simplest way to support both single-project and multiple-projects solutions.
Types of changes
[ ] Bugfix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
Checklist
[x] Build and tests pass locally
[ ] I have added tests that prove my fix is effective or that my feature works (if appropriate)
[x] I have added necessary documentation (if appropriate)
Note: I would be happy to provide tests as well, but I am uncertain as to how to proceed. If you can push me in the right direction for that, I'll add them and update the pull request.
Further comments
As mentioned in the proposed changes, the current changes require users to statically "use" the driver in their own code for it to be loaded in the AppDomain. This creates an undesirable line of code to be added in the user's project, which I found to be acceptable, but instead of that, it could be imaginable that the assembly is passed by the user into the GetContext method call instead. It would be a bit cleaner than adding a typeof call I think, but I am unsure how I would make the change. If you prefer this second approach, I'll need a bit of help to get me in the right direction as to where changes would need to be made.
Thorium
commented
3 years ago
Proposed Changes
Proposed fix for issue #692.
Because .NET 5's PublishSingleFile loads assemblies in memory instead of from files, SQLProvider needs to be able to load the drivers from the memory as well.
The current driver resolution logic remains untouched, but if it fails to load the expected assemblies, we then try to load them from the AppDomain instead.
This requires the users of SQLProvider to ensure that their driver is loaded into the AppDomain before creating the context. I tried other ways, such as getting the referenced assemblies of the executing assembly, but it would not work with a solution where the executing assembly relies on another project for data access through SQLProvider, so simply using the AppDomain seemed like the simplest way to support both single-project and multiple-projects solutions.
Types of changes
Checklist
Note: I would be happy to provide tests as well, but I am uncertain as to how to proceed. If you can push me in the right direction for that, I'll add them and update the pull request.
Further comments
As mentioned in the proposed changes, the current changes require users to statically "use" the driver in their own code for it to be loaded in the AppDomain. This creates an undesirable line of code to be added in the user's project, which I found to be acceptable, but instead of that, it could be imaginable that the assembly is passed by the user into the GetContext method call instead. It would be a bit cleaner than adding a typeof call I think, but I am unsure how I would make the change. If you prefer this second approach, I'll need a bit of help to get me in the right direction as to where changes would need to be made.