Having issues with hot reloading and locked DLLs

[KatoStoelen]

Describe the bug
I can't seem to get hot reloading to work. The plugin DLLs are locked by dotnet.exe even with EnableHotReload = true.

The hot-reload sample in this repository yielded the same results.

Using .NET Core SDK v3.1.100 on Windows.

To Reproduce
Steps to reproduce the behavior:

1. Install .NET Core SDK v3.1.100 on Windows
2. Clone this (DotNetCorePlugins) repository
3. Run /samples/hot-reload/run.sh
4. Output:

run.sh: Use CTRL+C to exit
TimestampedPlugin: this plugin was compiled at 9:05:24 a.m.
run.sh: Rebuilding plugin...

C:\Program Files\dotnet\sdk\3.1.100\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Publish.targets(155,5): warning MSB3026: Could not copy "C:\Source\DotNetCorePlugins\.build\obj\TimestampedPlugin\Debug\netstandard2.0\TimestampedPlugin.dll" to "C:\Source\DotNetCorePlugins\samples\hot-reload\bin\plugins\TimestampedPlugin\TimestampedPlugin.dll". Beginning retry 1 in 1000ms. The process cannot access the file 'C:\Source\DotNetCorePlugins\samples\hot-reload\bin\plugins\TimestampedPlugin\TimestampedPlugin.dll' because it is being used by another process.

Expected behavior
The plugin DLL is successfully overwritten and the PluginLoader gets reloaded.

[natemcmaster]

I don't have a Windows machine to debug this, so help would be appreciated in understanding why this is working on macOS and not Windows.

The plugin DLLs are locked by dotnet.exe

How do you know this? The log output in the repro you shared just says "because it is being used by another process."

[Andale-online]

This may occur in many circumstances. Even an open explorer.exe pointing to that directory may have a lock on files. I think there are some tools like sysinternals process explorer, which can show you who's locking the file.

[KatoStoelen]

Previously, I've used such tools for figuring out which process is locking some file. However, while trying to delete the plugin DLL I figured out that Windows actually tells you which process is locking the file, nowadays.

From the hot-reload sample (./run.sh):

From my own custom built host (executed with dotnet path/to/myhost.dll):

It's very deterministic. Disposing the PluginLoader makes no difference either. The process needs to be stopped to unlock the DLL.

[Andale-online]

I'm on Win10 / VS2019 - does that fit? Think I'm gonna try the sample later. We will see...

[KatoStoelen]

Thanks @Andale-online. I'm eager to hear about the results :)

Personally, I do not have VS2019 installed, but I can't see any reason why that should make a difference? I guess the .NET Core runtime/SDK version is the most important?

[natemcmaster]

Thanks for the report @KatoStoelen - I setup a Windows VM so I could repro, and have prepared a fix: #108. I'm planning to release the fix soon as 0.3.2

[KatoStoelen]

Thanks for fixing this @natemcmaster - awesome work.

I did however stumple upon a similar issue with Microsoft.Data.SqlClient and sni.dll (a plugin accessing a database). sni.dll is still locked by the host process. I'm guessing the loading of unmanaged DLLs are now slightly different than managed DLLs? Would it be possible to implement the same fix for loading unmanaged DLLs?

[natemcmaster]

@KatoStoelen - can you open a separate issue for that? I don't think it's currently possible to hot reload unmanaged libraries using AssemblyLoadContext, but we can investigate workarounds.