SNI.dll file locked when ASP.NET (Framework 4.8) App is running in IIS

Describe the bug
The SNI.dll file is loaded/locked by IIS when using a Microsft.Data.SqlClient connection in a ASP.NET 4.8 Framework website but is not unloaded when the app is shutdown. Subsequent attempts to build or deploy the site are blocked by the error Unable to delete file "bin\x86\SNI.dll". Access to the path '...\bin\x86\SNI.dll' is denied. Every other dll in the bin folder can be deleted even while the web app is still running save for this one.
To reproduce
1.) Create an ASP.NET MVC website on the 4.8 Framework
2.) Add the Microsoft.Data.SqlClient package
3.) In the HomeController.Index method open a SqlConnection and execute an arbitrary command
using (var connection = new SqlConnection("<connection string here>"))
{
    connection.Open();
    new SqlCommand("SELECT 1", connection).ExecuteNonQuery();
}

4.) Cause the site to shutdown by modifying the web.config or stopping the debugger.
5.) The SNI.dll file remains locked and cannot be replaced or modified without shutting down IIS or the application pool associated with the website
Expected behavior
The SNI.dll should be unlocked (like the rest of the files in the bin folder) so that a site can be updated through deployment or build.
Further technical details
Microsoft.Data.SqlClient version: v1.1.0
.NET target: Framework 4.8
SQL Server version: SQL Azure
Operating system: Windows 10 Professional / Windows Server 2016 Datacenter (Azure VM)

The SNI.dll library appears to be loaded in the SNINativeMethodWrapper static initializer but the handle is not kept or freed anywhere else in the code.
 IntPtr pDll = LoadLibrary(localFolder + subfolder + SNI);
 if (pDll == IntPtr.Zero)
 {
    throw new System.ComponentModel.Win32Exception("Failed to load " + localFolder + subfolder + SNI,
   new System.ComponentModel.Win32Exception(Marshal.GetLastWin32Error()));
}

@jakenuts
Could you also verify and confirm if same behaviour is observed with System.Data.SqlClient?

I tried removing the SqlClient packages, changing the using statement to using System.Data.SqlClient which creates a SqlConnection from the System.Data 4.0.0 framework assembly and no SNI.dll is copied to the bin folder so no issues there.
I tried installing the System.Data.SqlClient 4.8 package and it does not appear to rely on a SNI.dll for this 4.8 project and all the files in the bin folder can be deleted while the web app is running.
I then replaced that package with Microsoft.Data.SqlClient but kept the using statement as "using System.Data.SqlClient". This copied the SNI.dll to the bin/x86 folder but it is not loaded or locked when executing the command.
Changing the using statement to "using Microsoft.Data.SqlClient" and running the app caused the SNI.dll to be loaded and it is locked until I terminate the IIS process.

I tried some alternative setups where the data call DoData() was moved to a .NET Standard 2.0 library as that's the one my project uses. It demonstrated the "could not load file or assembly" error that shows up alot in Google searches, performed as expected when both project referenced System.Data.SqlClient 4.8, but moving to them both the Microsoft.Data.SqlClient replicates the file locking issue above.
[Setup 1]
ASP.NET NET 4.8 Project

no data assemblies referenced

.NET Standard 2.0 Library

System.Data.SqlClient 4.8 referenced
Using System.Data.SqlClient

No SNI dll in bin
Calling DoData() from the webapp into the library generates

System.IO.FileNotFoundException: 'Could not load file or assembly 'System.Data.SqlClient, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.'
[Setup 2]
ASP.NET NET 4.8 Project

System.Data.SqlClient 4.8 referenced

.NET Standard 2.0 Library

System.Data.SqlClient 4.8 referenced

No SNI dll in bin
Calling DoData() from the webapp into the library succeeds, all files can be deleted

[Setup 3]
ASP.NET NET 4.8 Project

no data assemblies referenced

.NET Standard 2.0 Library

Microsoft.Data.SqlClient 1.1.0 referenced
using Microsoft.Data.SqlClient;

No SNI dll in bin
Calling DoData() from the webapp fails with the 'could not load' exception

[Alternate Setup 4]
ASP.NET NET 4.8 Project

System.Data.SqlClient 4.8 referenced

.NET Standard 2.0 Library

Microsoft.Data.SqlClient 1.1.0 referenced
using Microsoft.Data.SqlClient;

No SNI dll in bin
Calling DoData() from the webapp fails with the 'could not load' exception

[Alternate Setup 4]
ASP.NET NET 4.8 Project

Microsoft.Data.SqlClient 1.1.0 referenced

.NET Standard 2.0 Library

Microsoft.Data.SqlClient 1.1.0 referenced
using Microsoft.Data.SqlClient;

SNI dll copied to bin
Calling DoData() succeeds, SNI.dll is locked until IIS process killed

Looking at the System.Data.SqlClient repository, there are some references to the necessity of holding onto and freeing the handle from SNI.dll (can't dig up where they load it). It doesn't appear that the handle loaded in Microsoft.Data.SqlClient is kept or later released which might explain why it sticks around.
From LocalDBAPI.Common.cs in System.Data.SqlClient
    //This is copy of handle that SNI maintains, so we are responsible for freeing it - therefore there we are not using SafeHandle
    private static IntPtr s_userInstanceDLLHandle = IntPtr.Zero;

   internal static void ReleaseDLLHandles()
   {
      s_userInstanceDLLHandle = IntPtr.Zero;
      s_localDBFormatMessage = null;
   }

Thanks for the details @jakenuts
I just opened up System.Data.SqlClient .NET framework library source code and I didn't see any call to "LoadLibrary" there (since our code is imported from there), here's the only way it's loaded for every API:
[DllImport("SNI.dll", CallingConvention = CallingConvention.Cdecl, EntryPoint = "SNIAddProviderWrapper")]
internal static extern uint SNIAddProvider(SNIHandle pConn, ProviderEnum ProvNum, [In] ref uint pInfo);

Which is also present in our case in SNINativeMethodWrapper.cs
I'm trying to understand why we added LoadLibrary call in there, which seems to be primary difference and cause of this behaviour.

Hi @jakenuts
I modified the way we load DLLs to test if we can fix the locking and still load SNI.dll properly, please try the NuGet package attached and let me know if you still experience lock:
Microsoft.Data.SqlClient.2.0.0-dev.nupkg.zip
You can use this nuget package in your application by referencing as under:
<PackageReference Include="Microsoft.Data.SqlClient" Version="2.0.0-dev" />
I'll proceed with PR once we have confirmation over expected behaviour.

Hi @jakenuts
I tried creating ASP.NET application to try reproduce issue but I cannot reproduce the problem using steps you mentioned above. I get file in use errors for "Roslyn" instead which I cannot delete, everything else I'm able to clean normally.
Application I tried:
WebApplication1.zip
Can you provide me a simple application which you're able to reproduce with if I missed something as I'm new to ASP.NET MVC architecture.

Sorry, had to run out, missed that package (was dying to try it but life ran away with me). Here is the most minimal ASP.NET 4.8 app I could come up with (at least tonight) to demonstrate it. I stripped out all the MVC and other stuff and just open the connection in the Global.asax startup. If you load it up & restore the packages, run it in IIS it should show a mostly blank page and when you close it the SNI.dll will still be locked. As you mentioned the roslyn folder also locks at points, but it can be deleted when the web app is shut down. Let me know if that works.
LockingWebApp48.zip

Sorry, I should have included that the Roslyn folder cannot be deleted while the app is running. Here is a minimal ASP.NET 4.8 project that demonstrates the issue (at least on my machine). You'll need to run it on IIS or IIS Express to reproduce the locking. I'm also connecting to Azure SQL in my connection string (stupidly posted that earlier, thus the deletion) but have replaced that with the localhost one from yours. Later I'll take a look at the two projects and see if there are any relevant differences.
LockingWebApp.zip

Here's another sample app that is even more 'minimal'. It uses owin and creates a connection to a non-existent LocalDb which is enough to use the SNI.dll imports. Once you open the project, restore the packages and run the app it should demonstrate the problem. Replacing the using statement for Microsoft.Data.SqlClient with System.Data.SqlClient resolves the issue.
LockingWebApp.zip

Hi @jakenuts
I tried your samples but still cannot reproduce any problem.
I apparently have localdb installed, but I also tested with random server name in connection string just to trigger exception case. I don't see any locking problems with SNI.dll.
Just to confirm the steps:

Open application in VS and run with IIS
Stop debugging app
Delete bin and obj folders manually

I can delete totally fine!

My Environment details are:

Windows 10 Enterprise
Visual Studio Enterprise 2019 (16.4.1)
.NET Framework 4.8.03752
IIS Version 10.0.18362.1

Did I miss something?
P.S. I'm also checking with my team internally if someone can reproduce in their environment.

Thanks! I tried loading the project on a different machine and for whatever reason it differs in that "stop debugging" or closing the browser window also closes IISExpress which then releases the DLL. On my machine IISExpress stays active even after I've stopped debugging.
When I tried with "Start without debugging" on the new machine, IISExpress stays active and when you try to rebuild, or if you delete all the rest of the files the SNI.dll remains locked. This replicates what is happening in production where full IIS remains running and once the dll is loaded it cannot be moved or updated until you kill the application pool.

I just tried creating an Azure App Service for the sample and published it there. Unfortunately it's way better at detecting changes than my VM deployment so it doesn't try to update the SNI.dll as they match so deployment succeeded without an issue. I was able to go into the console there and confirm that all the files in the bin directory could be deleted save for the SNI.dll though.

Hi @jakenuts
Yes I can reproduce the behavior now. The behavior with "Start without Debugging" happens because application is running on IIS in a detached mode and is Active on IIS Server from "bin" directory. What you mean to do it redeploy on top of Active application's "bin" directory. SNI.dll is locked in the process since it's a loaded library, from where you pointed above. Since the application is "Active", the DLL will stay loaded there.
If you stop the site, that would free the lock and SNI.dll can be deleted.

This seems to be expected behavior with Microsoft.Data.SqlClient.
With System.Data.SqlClient, you would not see this behavior because SNI code is inbuilt in "System.Data.dll" hence there was no external loading done. The Native SNI code in there is shared between all ADO.NET providers. This is not the case with Microsoft.Data.SqlClient as SNI.dll needs to be loaded from an external NuGet package "Microsoft.Data.SqlClient.SNI" in current process.
You can say that SqlClient (for .NET Framework) is incomplete without this referenced "SNI.dll". The reason why it's referenced externally from Microsoft.Data.SqlClient is that SNI native implementation continues to be a closed source, and is not open sourced yet.

I was wondering if SNI.dll stayed loaded even after App was Shutdown/Stopped, as mentioned in the first comment, that doesn't seem to be the case.

It is a bit of a standout though as you can update/delete every file in a website (save for the roslyn folder) during deployment save for this one. Even after adding an App_Offline.htm file which is part of the standard deployment process the DLL remains locked so the only way to deploy is to stop the site entirely while the files are copied over. It's not a terrible workaround but it does mean that requests will come back with 500(?) responses instead of the App_Offline content which is slightly more polite.
Is it possible that the rest of the bin files are shadow copied somewhere such that they don't appear locked even when they loaded into the IIS process?

I'm not an IIS expert, but there seem to be workarounds, with "Touch" tasks, you can try. I got some info from Developer Community Post.
Ideally, as discussed on Stack Overflow, the best approach is:

Take the outage and allow IIS to cleanly release locks and clean up after itself to preserve server stability.
If not feasible, you can either create another site on the same box, or set up a new box with the new content, and move the domain name/IP across to "promote" the new content to production.

I will close the issue as the behaviour is "By Design".
Thanks!

It seems impervious to the App_Offline method, but I can live with the "restart application pool" workaround as I'm hoping to eventually migrate away from the 4.8 legacy bits anyway. I really appreciate your help, thanks, have a great holiday!

I'm surprised this issue is locked.  while it might be 'as it worked before' with the previous version of sqlclient, it's not really ideal behavior, right?  recycling the app pool isn't always reliable, and additionally  I hit this issue frequently on my development box on just compiling.

Hi @vishnu4
Firstly, this happens only with apps active or running in IIS, and you must stop the app safely in order to clean the bin directory and recompile.
Secondly, Microsoft.Data.SqlClient (.NET Framework) needs to load native library Microsoft.Data.SqlClient.SNI (SNI.dll) and since it is not part of Full Framework it needs to be loaded explicitly to work. It is not unloaded due to the fact that driver cannot function at all without SNI.dll, and as I mentioned above their separation was done for security and legal reasons.
This design is not the same as System.Data.SqlClient, so even if you may think 'it worked before for S.D.S', technically, their designs are very different from each other.
Microsoft.Data.SqlClient (.Net Core) on the other hand also references SNI.dll from runtime native libraries but they're part of .NET Core SDK so you'll not encounter issues there. And since moving forward .NET Core is the primary focus and .NET Framework is not longer active, we recommend users to port over to .NET Core if this issue becomes a big hurdle in development.

I get that it happens when apps are active or running in IIS.  i'm not debating that.  I understand that the designs are very different as well, i'm not debating that either.  I'm just saying my use cases are not edge or unique, and even though i don't have a solution to this issue, i don't think it should be closed or ignored.
The 2 places i see this issue are:

on deploy via azure devops, i've now added a 'recycle app pool' task, which runs fine, but SNI.dll was still seen as locked during some of my deploys (while it is trying to purge the bin directory).  so either the recycle wasn't good enough, or i need to change the task so that IIS is stopped entirely during the deployment process.
when i'm on my development machine I can run the app, work in it, and then rebuild again.  50% of the time my rebuild fails because the file is locked.  this definitely makes development difficult if i have to add the extra step of recycling the app pool or restarting IIS between every build.

I understand i'm in .net framework, and that is a purgatory that i should try to get myself out of, but the move to use microsoft.data.sqlclient was part of that move for me, but it's actually making the move harder because of these issues.  I have a large monolith .net framework app and i am gradually moving projects towards .net standard.  This gradual move is what is causing my issue apparently.
So the solution is that i can't move gradually?  I have to move everything to .net core immediately, all in one go without doing things in steps?  That just doesn't seem realistic, which is the only point i'm trying to make here.  This issue is making development more difficult, and the only solution seems  to be to move everything BACK to .net framework so i can use System.Data.SQLClient instead, which prevents me from ever really moving to .net core.
.Net core is the primary focus.  Great, totally down with that.  Shouldn't that mean that aiding users from migrating from .Net Framework to .Net core should be important then?

Hi @cheenamalhotra ,
Do you have any ETA for this to be solved? We are waiting this issue to be solved to update our 2.1 version to 3.1.

is this issue be solved? we are waiting for this. to update to 3.1

for develop debug condition ,temporary solution：
before you rebuild project，execute the bat，then sni.dll will be unlocked
bat content:
c:\windows\system32\inetsrv\AppCmd.exe stop apppool /apppool.name:"your pool name"
ping -n 5 127.1>nul
c:\windows\system32\inetsrv\AppCmd.exe start apppool /apppool.name:"your pool name"

Hi @agevorg @chumacn
We investigated the same and currently the driver design does not support implementing unload behavior since the DLL is loaded in a static class instance. A great deal of changes are needed in the driver to support this, and that hasn't been prioritized yet.
Recommended solution with this design is to undeploy and re-deploy your app in IIS to perform safe unload of SNI.dll.

Hi @agevorg @chumacn
We investigated the same and currently the driver design does not support implementing unload behavior since the DLL is loaded in a static class instance. A great deal of changes are needed in the driver to support this, and that hasn't been prioritized yet.
Recommended solution with this design is to undeploy and re-deploy your app in IIS to perform safe unload of SNI.dll.

so when update to fix？previous version work well。but the latest version do lock the dll

Hi @cheenamalhotra; Just chiming in that this issue is blocking others as well. As large projects are not always dynamic and able to shift as quickly there is an expectation of status quo from the behavior and deployment process. Please consider this another vote to raise the priority for this issue.
Thanks!

Hi @cheenamalhotra, just chiming in with our experiences. Our case is slightly different, and harder to work around.  We cannot currently move to full .NET Core for this application (it is big) and we cannot use the System.Data.SqlClient.dll either because we want to use EFCore.
We load libraries into separate appdomains, and later unload them to upgrade them without restarting the entire process. But since SNI.dll is locked, we are unable to update those libraries after the appdomain is unloaded.
We are using shadow copy, but SNI.dll is not shadow-copied.
I have create a reproduction repo here: https://github.com/steinmr/SNILockedRepro

Hi @steinmr @jimbromley-avanade
I understand your concerns. We have been investigating on making this experience better but the problem is the fact that this is Native/Unmanaged DLL that is loaded in the IIS process.
We also managed to remove the LoadLibrary() call (changes will be merged with PR #570) but because this is a Native DLL, once loaded by the application, it stays loaded.
We have limited experience with IIS but how do you normally work with Native DLLs and unload them from process without unloading them from managed code? Have you used solutions involving  common directory like C:\Windows\System32\inetsrv outside your bin folder such that your local bin can be safely deleted?
I'm wondering because we're now moving away from strong path LoadLibrary(), and would be able to load DLL if it's loaded in the process from any directory, maybe this could bring a potential solution?

@cheenamalhotra Than you for your assistance. I tried the PR, but now I can not delete Microsoft.Data.SqlClient.SNI.x64.dll

@steinmr
Yes the problem is going to stay if you use it as it is because DLLs are still going to be copied with the driver. As I said earlier, what's changed is we do not LoadLibrary() from strong path in the new design.
Have you tried to move Microsoft.Data.SqlClient.SNI.x64.dll to a different location that's also loaded in IIS, rather than keeping it in the same bin folder?

@cheenamalhotra Hi, thank you for your continued help, really appreciated.
Just to be clear, I'm not using IIS, this is a simple console app.
We do not currently have any special handling for native DLLs, as far as I know all DLLs are either managed or part of the full .NET framework.
But with the following modifications to my example repo, I was able to "shadow copy" the native DLL, and thus it was loaded from the shadow-copied folder, instead of the bin folder. This means that it fixes my problem. This requires PR #570
But this feels pretty clunky, and I agree with @vishnu4 that such issues will be blockers for moving over to netcore, which is the end goal for all of us I think.
private static AppDomain CreateAppDomain(FileInfo file)
{
    var appDomainSetup = new AppDomainSetup { ShadowCopyFiles = "true" };
    var appDomain = AppDomain.CreateDomain(file.Name, null, appDomainSetup);
    appDomain.AssemblyLoad += AppDomain_AssemblyLoad;
    return appDomain;
}

private static void AppDomain_AssemblyLoad(object sender, AssemblyLoadEventArgs args)
{
    const string lib = "Microsoft.Data.SqlClient";
    if(args.LoadedAssembly.ManifestModule.Name == $"{lib}.dll")
    {
        foreach (var file in new string[] { $"{lib}.SNI.x64.dll", $"{lib}.SNI.x86.dll" })
        {
            var targetFile = Path.Combine(Path.GetDirectoryName(args.LoadedAssembly.Location), file);
            if(!File.Exists(targetFile)) // Shadow copy native DLL
                File.Copy(Path.Combine(AppDomain.CurrentDomain.BaseDirectory, file), targetFile);
        }
    }
}

Hi @jakenuts
That sounds great!
Just to clear your doubts, in .NET Core you will not have these issues as there we have runtime native DLLs which are loaded in process from NuGet Package cache folders and there is no transitive copy performed. You can give it a try in example apps and let us know if you face any issues.
These DLLs and issues associated with it are only applicable to .NET Framework and it is this transition phase that I believe is a little difficult to configure but with improvements we are coming with in #570 we hope to make the transition process smoother.

Thanks  @cheenamalhotra
Any plans on adding this to 1.1 in addition to 2.0?

Hi @steinmr
This change required good amount of design changes in both SNI packaging and driver consumption and isn't a patch.. so no, backporting wouldn't be possible. This shall be available starting v2.0.

Hello @cheenamalhotra,
I faced the same issue on IIS.
I updated the Microsft.Data.SqlClient and Microsft.Data.SqlClient.SNI to the 2.0.0 version but the Microsoft.Data.SqlClient.SNI.x64 is still locked by the IIS.
Do you have any thoughts on why it happened?

This breaks our build pipeline because our unit tests encounter the same problem. We are trying to progressively migrate to .NET Core and migrating to EF Core was one of the planned milestones for that. We have no way to migrate to EF Core without this issue fixed. Is there any workaround?

@berezovskii @ssg
The above comment(https://github.com/dotnet/SqlClient/issues/354#issuecomment-632312605) is a workaround to perform shadow copy of DLLs to a different folder and load DLLs from there. That way an App redeployment wouldn't be obstructed with loaded DLLs.

Hi, faced this issue also.
If anyone is using TFS to deploy their applications I updated IIS Web App Deploy task as a workaround until a better solution is found.
-usechecksum

Hi, is this issue resolved? I'm still receiving this error on ASPNET 4.8 using Microsoft.Data.SqlClient 2.0.1.

@rbiq
The only resolution to this issue is to not have an external Native dependency in use at all, which is an ultimate long term goal for us but extremely unlikely in near sight future. Native SNI Dlls are very stable/performant in every way and it's extremely hard to replace them. Even if we start today, it will take a very long time of testing/improvements in order to build trust in customer applications before it's officially replaced, and this effort is not planned yet for .NET Framework. The Managed implementation we have for .NET Core driver is also under constant improvements/testing, but it has it's own challenges to overcome to be comparable with native implementation.
As of possible mitigations in current state, they are detailed in above discussions.

@cheenamalhotra I guess I can continue to kill w3wp.exe in development environment to overcome the issue. However what i'm really trying to understand is the impact of this in production. Currently we're deploying manually to our product environment which entails pasting the bin folder manually. Will this cause any unforeseen issues in there? Also i believe this was a dependency on Microsoft.Data.SqlClient when I installed it from nuget in a .netstandard 2.0. This netstandard library is referenced in the aspnet 4.8 web app project. So if I replace this lib with good old System.Data.SqlClient will this issue go away? I think EF Core installed in the netstandard should still work with System.Data.SqlClient, amiright?

I don't see any issues with manual deployment if it's designed this way. If you want it automated, you'd need some downtime to stop the application - deploy and restart, which is also possible solution. If you downgrade driver to System.Data.SqlClient, it would solve the bin directory issue because the driver is not loaded from there, but from framework itself. But you'll also have to also downgrade EF Core version and I wouldn't recommend doing that just for deployment ease.
The best advisable solution is to load SNI dlls from any another directory other than bin directory by shadow copying them to that directory. That will not block you to redeploy application as native DLLs will not be loaded from that location. The driver loads them to the bin directory as that's the only directory driver is eligible to access, but you can control that and place it to any other location that you don't expect to block you. Do remember to replace the SNI dlls when you upgrade version of Microsoft.Data.SqlClient (if SNI reference also updates), to make sure you're getting all updates from native side too.

Understood. thanks for the response. I'm currently developing on NET48 classic Webforms aspx and deploying on IIS. To my understanding the AppDomain is more or less managed by IIS and so I'm not sure where I would apply the above steps to launch an appdomain and shadow copy the file. Can you please shed some light on it? thanks for all your help.

This is going to make development irritating for a large team for the next few months :( Thankfully we are just switching to Standard as an intermediate step between  moving to Core at some point next year so at least will be able to say 'it's only for a few months hopefully'
I find the best way to clear the lock is kill the w3wp.exe for the relevant user in TaskManager>>Details. Shutting the IIS site or stopping the relevant app pool does not prevent the issue (in our case we build into IIS from TFS so are often 'changing' code and re-building so will hit this a lot)
It might be possible to automate this to 'hide' the problem. So I will try to look at that next.

@rbiq
It is not our expert area to advise on .NET WebForms and IIS application design. I'd recommend seeking advice on design ideas from experts in IIS application area.

I found the easiest way to clear the process lock was to force IIS reset in one of the project builds

iisreset /stop

iisreset /restart

Stops the error occurring and allows the build to occur. Might have secondary advantages in ensuring IIS doesn't have any hangups with previous operations as well.

To avoid our devs having to manually kill the process we have added an iisreset command to one of the project builds which will nicely avoid the problem.
<PropertyGroup>
  <PreBuildEvent>iisreset /stop</PreBuildEvent>
</PropertyGroup>
  <PropertyGroup>
    <PostBuildEvent>
iisreset /restart
    </PostBuildEvent>
  </PropertyGroup>

@matrimsaric unfortunately we're seeing:
The command "iisreset /restart" exited with code 5. Please verify that you have sufficient rights to run this command.
Did you face the same issue? If so, how did you build it in admin mode?

@rbiq
It is not our expert area to advise on .NET WebForms and IIS application design. I'd recommend seeking advice on design ideas from experts in IIS application area. You may find some helpful tips from the discussion above.

Unfortunately this issue doesn't seem to be related to webforms and iis per se. This is about referencing MDS into webforms and how it works with webforms. If you could write a hack to unload the dll when app domain is being shutdown and provide that as an additional dll to load along with MDS and other refs that'd solve our problem.

@matrimsaric no luck with that either. It won't run. At this point I'm resorting to running a batch file manually before every build.

I think you should mention someone from the asp.net team, preferably someone who worked previously on the asp.net fwk team.
The concept of shadow copy is here to handle the case of dll locking. Perhaps the native library could be included as a shadow copy member and then be loaded from the DynamicBase directory which will be different from the current directory you deployed your application in (see https://shazwazza.com/post/Developing-a-plugin-framework-in-ASPNET-with-medium-trust.aspx for example).
The concept of shadow copy is to copy the files from the app in a unique directory where locking could occurs. Then, original directory is still writable and when a new app is started, a new directory will be created.
I am sure there are people at MS which could help you handle this better in a IIS / ASP.NET scenario.

Based on the comments from https://stackoverflow.com/questions/2445536/unload-a-dll-loaded-using-dllimport I was creating the following class and then call the Microsoft.Data.SqlClient.SniUnloader.RegisterForUnload() method from the Init-method in the global.asax and this releasing the locked SNI-assembly when I test with the rebuild solution inside Visual Studio.
using System;
using System.Diagnostics;
using System.Linq;
using System.Runtime.InteropServices;

namespace Microsoft.Data.SqlClient
{
    public static class SniUnloader
    {
        private static bool _registered;
        private static readonly object _registrationLock = new object();

        [DllImport("kernel32.dll", SetLastError = true)]
        private static extern bool FreeLibrary(IntPtr hModule);

        public static void RegisterForUnload()
        {
            if (!_registered)
            {
                lock (_registrationLock)
                {
                    if (!_registered)
                    {
                        AppDomain.CurrentDomain.DomainUnload += CurrentDomain_DomainUnload;
                        _registered = true;
                    }
                }
            }
        }

        private static void CurrentDomain_DomainUnload(object sender, EventArgs e)
        {
            var moduleName = Environment.Is64BitProcess
                ? "Microsoft.Data.SqlClient.SNI.x64.dll"
                : "Microsoft.Data.SqlClient.SNI.x86.dll";

            ProcessModule module =
                Process.GetCurrentProcess().Modules.OfType<ProcessModule>()
                    .FirstOrDefault(x => x.ModuleName == moduleName);

            if (module is object)
            {
                FreeLibrary(module.BaseAddress);
            }
        }
    }
}

nice! I tried your code in my own project and have not hit any issues yet (I am calling it prior to the Configuration if that makes any difference). I also have the force IIS reset in the build process as a further complicating factor.

Hello @cheenamalhotra
For me, this seems to be a bug in the .NET Core framework (SqlClient). Actually, an unmanaged ressource that is not released properly. Is this exact ?
I'm currently having deployment issue with Azure Devops that seems to be related to this problem:

Is there any plan to release a fix for this problem ?
Thanks for your help,

The below code was not working but creating an IIS module that shadow copy the DLL was working much better, see https://github.com/Tasteful/SNILoader

How/where does this SNILoader fit into the code? Is this a project you add to an existing solution? You said it's an IIS module, but I can't figure out how to install it as a module to IIS.

The below code was not working but creating an IIS module that shadow copy the DLL was working much better, see https://github.com/Tasteful/SNILoader

@Tasteful, how/where does this SNILoader fit into the code? Is this a project you add to an existing solution? You said it's an IIS module, but I can't figure out how to install it as a module to IIS.

The below code was not working but creating an IIS module that shadow copy the DLL was working much better, see https://github.com/Tasteful/SNILoader

@Tasteful, how/where does this SNILoader fit into the code? Is this a project you add to an existing solution? You said it's an IIS module, but I can't figure out how to install it as a module to IIS.

Build and package the project into a nuget-package. If you publish the package, think of reading and understand the license for the different included components.
Add a reference to the created nuget-package and make a clean build of the solution.
Ensure that the SNI-dll file not exists in the bin-folder.
Test your solution to ensure that it is working with the shadow copying of the SNI-dll into the temporary folders for ASP.NET files.

When deploying into production for the first time the SNI-dll will still be there in the bin-folder and block the deployment and you need to do some workaround to get the files updated.

Build and package the project into a nuget-package. If you publish the package, think of reading and understand the license for the different included components.
Add a reference to the created nuget-package and make a clean build of the solution.
Ensure that the SNI-dll file not exists in the bin-folder.
Test your solution to ensure that it is working with the shadow copying of the SNI-dll into the temporary folders for ASP.NET files.

When deploying into production for the first time the SNI-dll will still be there in the bin-folder and block the deployment and you need to do some workaround to get the files updated.

This worked perfectly. Thank you!

Hitting this issue here. Not using azure but xcopy deployment on premises with fw 4.7.2. It seems to me that the shadow copy mechanism that was so useful under .netfw was completely forgotten while designing .net core. I am hitting so many unexpected issues with these porting steps that I'm starting to think if it would be easier to just hand out the rewrite to our java team :-(

But my application is not running under .net core: it is running under the full .net 4.7.2 framework/IIS. One would expect that the native library would be unloaded when IIS recycles the application, but it does not.
I tried with the usual workarounds, like placing an app_offline.htm in the app root, or touching the web.config file - they do not work either, the file remains locked. Only a full Application Pool restart seems to unlock the file.
Basically, using this component breaks xcopy development on the .net framework.
I don't see how reaching the .net core team would help: the previous comments suggest that this component does not unload the library when the AppDomain is recycled. It is not an issue with the runtime, as shadow copy/xcopy deployment usually works fine on the full framework.

It seems to me that the shadow copy mechanism that was so useful under .netfw was completely forgotten while designing .net core.

Please also note that Shadow Copying is planned for .NET 6.

Based on the fact that shadow copying is now planned for .NET 6, maybe the team could try to see if there could be a mechanism to detect and use the native library from the shadow copy location instead of the original location?
This solution could be useful for .net fwk cases, but also for future .net 6 web apps. I am sure the .net team could gladly help for this kind of scenarios.

I only tested it for a couple of days, but I think I found an elegant solution to enable the shadow copy mechanism for the native assembly. I will publish on github it in the next few hours.

@lscorcia something similar to my https://github.com/Tasteful/SNILoader ?

I published my approach at https://github.com/lscorcia/sqlclient.snishadowcopy . It is similar to @Tasteful approach in the sense that it copies the native assembly under the shadow folder, but it takes advantage of the fact that Windows will first try to load the dll from the same location of the Microsoft.Data.SqlClient assembly so by copying the native assembly there, no explicit call to LoadLibrary is needed.
If anyone could confirm that this approach is actually working and it's not just a fluke in my tests, I would go on and publish a Nuget package.
Thanks!

@jakenuts is this still an issue or the solution provided by @lscorcia solved your issue? If the issue is solved please feel free to close the issue.

It's still an issue I'd say, having a locked file on the filesystem causes all sorts of development time and operational issues. They can be worked around (e.g. https://github.com/lscorcia/sqlclient.snishadowcopy) but it's a pretty poor experience by default.
Possibly the SqlClient project could start using the shadow copy approach that @lscorcia showed?

Has anyone tried adding explicit reference to Microsoft.Data.Sql 2.x?
I'm comming from a bit different issue, but seems like it could be a solution here as well.

The workaround by @lscorcia didn't work for me. I don't have a Microsoft.Data.SqlClient.x86.SNI.dll, but
Microsoft.Data.SqlClient.dll and the SNI.dll in a subfolder x86.
If I remove the SNI.dll from the x86 folder the app crashed when I try to access the database because the dll is not found, even if I copy it to the shadow copy location (it appears it always searches in the bin folder). Any ideas?

@EikeStein is this referring to Microsoft.Data,SqlClient or System.Data.SqlClient?

@EikeStein is this referring to Microsoft.Data,SqlClient or System.Data.SqlClient?

To Microsoft.Data.SqlClient (unless I'm totally lost)

I have the same issue with Visual Studio 2022. When I try to clean the project, I get the message
Unable to delete file "bin\Microsoft.Data.SqlClient.SNI.x64.dll". Access to the path 'C:\myprojcts\WebApplicationProject.Web\bin\Microsoft.Data.SqlClient.SNI.x64.dll' is denied.

Same here, we have a big solution in .NET 4.6.2, we are doing early steps to move on .NET Core.
But Microsoft is doing is best to prevent us to switch on .NET Core :-(

Ran into the same issue - website running in IIS and doing a rebuild in VS would error out on cleaning the bin folder because the SNI dll is locked.
Normally IIS copies all the dlls to some temp directory like "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root\8b727de3\bc3cd64\assembly\dl3\52c41fab\0079fa1e_3661d901" a runs it from there. That way the original bin folder can be cleared and rebuild. For some reason this isn't happening for these SNI dlls.
I came up with this workaround (needs to be run somewhere at start, before anything loads the SqlClient dlls):
[System.Diagnostics.Conditional("DEBUG")]
private static void FixSqlClientRebuild()
{
    var assembly = AppDomain.CurrentDomain.GetAssemblies().FirstOrDefault(x => x.GetName().Name == "Microsoft.Data.SqlClient");
    if (assembly is not null)
    {
        var folder = Path.GetDirectoryName(assembly.Location);
        var path = Path.Combine(folder, "Microsoft.Data.SqlClient.SNI.x64.dll");
        var dll = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "bin", "Microsoft.Data.SqlClient.SNI.x64.dll");
        File.Move(dll, path);
    }
}

Basically just moving the dll from the bin folder to the temp location where "Microsoft.Data.SqlClient.dll" is.

We've experienced the same problem after migrating to Microsoft.Data.SqlClient. When we launch the app it loads fine but IIS Express holds a lock on the Microsoft.Data.SqlClient.SNI.x64.dll. When recompiling our .Net Framework 4.6.2 WebForms app, due to the lock we get the error "Unable to delete file "bin\Microsoft.Data.SqlClient.SNI.x64.dll". Access to the path '..\bin\Microsoft.Data.SqlClient.SNI.x64.dll' is denied."
I tried @lscorcia's workaround but it didn't work for us. I tried @jaryn-kubik's workaround and it works!! We can now recompile our project in visual studio without the compilation error occurring.
As someone previously mentioned in this thread, this compilation error only occurs for WebForms projects and it works fine in .Net Core. I hope to remove this patch when we eventually upgrade to .Net Core.

To add our experience to this thread in case it helps anyone.
Like @EikeSchwass (comment), we were using a version of Microsoft.Data.SqlClient (1.1.X) that copied x86\SNI.dll and x64\SNI.dll assemblies into the bin folder, and caused IIS to lock them there.  In versions of Microsoft.Data.SqlClient prior to 2.0-preview4 (per @Kaur-Parminder 's comment) the SNI.dlls are loaded from the bin directory no matter what you do (owing to a hard coded path in the static constructor of SNINativeMethodWrapper.
So, in order to use @lscorcia 's workaround, we needed to update the version of Microsoft.Data.SqlClient we were using.  I tried to upgrade to 3.1.5 first, but when doing so, ended up with errors connecting to the database via EntityFramework ("error: 26 - Error Locating Server/Instance Specified").  So I updated to 4.1.5 which worked, but with the caveat that there is a breaking change; specifically, versions of Microsoft.Data.SqlClient > 4.0.0 assume that the connection will be encrypted, so if it is not, you either need to make it so, or add "Encrypt=false" to the end of your connection string.
Hope that helps someone else.  Not a fun issue to diagnose and fix...

With the release of 5.2 does any know if this issue was fixed?

@ProVega I'm using v5.2.0 and .NET Framework 4.8 and still experiencing it. Although one of our apps using 5.2.0 has not experienced it and one of them is, and I can't figure out why. They're running on different servers. Perhaps different IIS versions, not sure. Not sure what else would make the difference.

@ProVega  I'm using 5.2.0 on .net Framework 4.7.2 and it still happens. This whole thread is very frustrating. We are stuck on the full framework due to Microsoft's choices. I am trying to leverage new authentication modes to increase our application security which is only supported in Microsoft.Data.Sql, and now our development workflow is degraded.
And doing iisReset's fails half the time telling me I'm not an admin (which I am),

@ProVega still broken on 4.7.2 using 5.2.0 of Microsoft.Data.SqlClient.
Iscorcia's solution worked https://github.com/lscorcia/sqlclient.snishadowcopy. We are using OWIN so I tied into Owins Configuration class. Copied his one class into my project and it seems to be working!
Thank you @Iscorcia I owe you a beer!

We're closing the issue as there are no plans to address this in .NET Framework SNI DLLs.
There are solutions discussed in the thread that should help mitigate the issue.


orm_mode with PonyORM

Checks

[x] I added a descriptive title to this issue
[x] I have searched (google, github) for similar issues and couldn't find anything
[x] I have read and followed the docs and couldn't find an answer
[x] After submitting this, I commit to one of:

Look through open issues and helped at least one other person
Hit the "watch" button on this repo to receive notifications and I commit to help at least 2 people that ask questions in the future
Implement a Pull Request for a confirmed bug

Question
Output of python -c "import pydantic.utils; print(pydantic.utils.version_info())":
             pydantic version: 1.6.1
            pydantic compiled: False
                 install path: /home/christoph/.cache/pypoetry/virtualenvs/backend-WV529wjX-py3.8/lib/python3.8/site-packages/pydantic
               python version: 3.8.3 (default, May 13 2020, 19:59:26)  [GCC 9.2.0]
                     platform: Linux-5.4.67-x86_64-with-glibc2.2.5
     optional deps. installed: ['typing-extensions']

...

Unfortunately not self-contained because database setup required, but I hope my goal is obvious.
This should work as per Recursive ORM Models, but I am getting the following error:
pydantic.error_wrappers.ValidationError: 1 validation error for Organization
E           contents
E             value is not a valid list (type=type_error.list)

When querying ORMOrganization, ORMOrganization.contents is of type ORMOrganizationContentSet([ORMOrganizationContent[UUID('249941bf-fe64-430e-ae38-7731e60a9940')]]). Pony's content set doesn't seem to work for the recursive ORM mode? iter(contents) works, so I am not sure where to go from here.
Changing the type of Organization.contents to Set[OrganizationContent] does not change anything.
I searched the issues here for PonyORM and did not find anything. I would much appreciate any help regarding this!
import pydantic

# Database classes:

class ORMOrganization(database.Entity):
    id = PrimaryKey(UUID, default=uuid4, auto=True)
    contents = Set('ORMOrganizationContent', reverse="organization")

class ORMOrganizationContent(database.Entity):
    id = PrimaryKey(UUID, default=uuid4, auto=True)
    organization = Required("ORMOrganization")
    name = Required(str)

# Pydantic classes:
class OrganizationContent(pydantic.BaseModel):
    id: UUID
    name: str

    class Config:
        orm_mode = True

class Organization(pydantic.BaseModel):
    id: UUID
    contents: List[OrganizationContent]

    class Config:
        orm_mode = True

I assume contents is an iterable which is neither a list nor is it sequence-like in Pydantic terms.  I have no experience with Pony but the simplest thing to do here would be to use a validator.

Thanks for the validator hint!
Adding
    @validator("contents", pre=True, allow_reuse=True)
    def pony_set_to_list(cls, v):
        return list(v)

solves my issue.
Thank you and have a great rest of your week!


Issue starting after reboot

After installing the snap and using Wekan once, the services have not been able to restart after a reboot.
I'm running the snap locally on Debian bullseye:
sudo snap get wekan
Key       Value
port      8080
root-url  http://localhost:8080

I get the following output when wekan tries to start:
/snap/wekan/1998/programs/server/node_modules/fibers/future.js:313
						throw(ex);
						^

MongoServerSelectionError: connect ECONNREFUSED <IP_ADDRESS>:27019
    at Timeout._onTimeout (/snap/wekan/1998/programs/server/npm/node_modules/meteor/npm-mongo/node_modules/mongodb/lib/core/sdam/topology.js:439:30)
    at listOnTimeout (internal/timers.js:554:17)
    at processTimers (internal/timers.js:497:7) {
  reason: TopologyDescription {
    type: 'Single',
    setName: null,
    maxSetVersion: null,
    maxElectionId: null,
    servers: Map {
      '<IP_ADDRESS>:27019' => ServerDescription {
        address: '<IP_ADDRESS>:27019',
        error: Error: connect ECONNREFUSED <IP_ADDRESS>:27019
            at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1144:16) {
          name: 'MongoNetworkError'
        },
        roundTripTime: -1,
        lastUpdateTime: 213330,
        lastWriteDate: null,
        opTime: null,
        type: 'Unknown',
        topologyVersion: undefined,
        minWireVersion: 0,
        maxWireVersion: 0,
        hosts: [],
        passives: [],
        arbiters: [],
        tags: []
      }
    },
    stale: false,
    compatible: true,
    compatibilityError: null,
    logicalSessionTimeoutMinutes: null,
    heartbeatFrequencyMS: 10000,
    localThresholdMS: 15,
    commonWireVersion: null
  }
}

And when wekan.mongodb tries to start:
WAIT_SPINNER=Bounce (default value)
error: error running snapctl: get which option?
NODE_OPTIONS=--max_old_space_size=4096 (default value)
mongodb bind options:  --bind_ip <IP_ADDRESS> --port 27019
Sending mongodb logs to /dev/null
Error parsing command line: unrecognised option '--bind_ip'
try 'mongo --help' for more information

Any help would be very appreciated.

This issue is many years old, and does not happen anymore.


Address DayPickerNavigation rerender

Fix for the DayPickerNavigation rerender discussed in https://github.com/airbnb/react-dates/issues/1297
Pretty simple fix involving moving around some arguments.
to: @ljharb @lencioni @AntiFish03

Coverage increased (+0.03%) to 84.945% when pulling ba73610fa2e07543c3ab6857923c08d205193aea on maja-address-daypickernav-rerender into d857a247d0869e06a0f54b20b158d3f510970dd8 on master.

@ljharb I've split out the two cases that call the month transition into two functions. I think this approach makes more sense! Can you take another look?


remove work array fromFFT setup

HEFFTE removed the work variable from its FFT setup functions: HEFFTE commit  376fa0b
This small change fixes a build issue and allows Cajita to build with the most recent HEFFTE.

Codecov Report

Merging #30 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #30   +/-   ##
=======================================
  Coverage   84.32%   84.32%
=======================================
  Files          32       32
  Lines        5653     5653
=======================================
  Hits         4767     4767
  Misses        886      886

Flag
Coverage Δ

#mpicc
84.32% <ø> (ø)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7f3aafc...6fca73a. Read the comment docs.


InstantiationError when running from a fat jar

Code compiles and runs fine under sbt but i can't run it from a jar. Nothing changed in build.sbt, It always points the lines that contains "class .... extends LazyLogging". "object .... extends LazyLogging" seems fine , no problem with that.
Exception in thread "main" java.lang.InstantiationError: com.typesafe.scalalogging.Logger
at com.typesafe.scalalogging.Logger$.apply(Logger.scala:31)
at com.typesafe.scalalogging.LazyLogging$class.logger(Logging.scala:28)
at io.tazi.featureengineering.FeatureEngineering.logger$lzycompute(FeatureEngineering.scala:34)
at io.tazi.featureengineering.FeatureEngineering.logger(FeatureEngineering.scala:34)

Outside of this lib.


fix repeat delete service and pod

fix https://github.com/kubeflow/tf-operator/issues/997
/assign @gaocegege @richardsliu

This change is

Coverage remained the same at 76.744% when pulling c352766c42848640aeabd63c62e31a9ffb7643e5 on wackxu:fixdel into 7432acb6eacf1342d8c6a4fa28f290b9cc3d793c on kubeflow:master.

/lgtm


Implemented Dispatcher.Yield

What does the pull request do?
Implements Dispatcher.Yield according to #14199.
Checklist

[x] Added unit tests (if possible)?
[x] Added XML documentation to any related classes?
[ ] Consider submitting a PR to https://github.com/AvaloniaUI/avalonia-docs with user documentation

Fixed issues
Fixes #14199

This API behaves differently from from Microsoft's. In WPF you cannot use this method to switch execution to the dispatcher thread. It's static and always targets the current thread's dispatcher, throwing an exception if there isn't one installed. So it's only useful for the documented purpose:

Creates an awaitable object that asynchronously yields control back to the current dispatcher and provides an opportunity for the dispatcher to process other events.

I've seen awaiters used to resume execution on a specific thread before, but these are called something else. Unfortunately I forget the name, but it's definitely not a "yield".

Now that I start to think about it, creating an awaiter that resumes on an unrelated sync context is IMO an abuse of the async/await pattern. The design intent of async/await is to capture and later resume execution on the current context, but these "request foreground" designs do the diametric opposite: they switch execution it to an entirely different context, and provide no way to return to the current one. Perhaps this is why Microsoft locked Dispatcher.Yield to the calling thread's dispatcher.
I'm not in a position to block such things being added to Avalonia. But could I request that any method called "yield" throw an exception if called from off the dispatcher's thread, like WPF's yield method does?

We should follow the behavior of Task.Yield here in terms of dispatchers. So we always continue execution on current dispatcher's thread with given priority.

Having an instance of the dispatcher and checking it to be the current dispatcher doesn't sound for me. It's like you're my current, but not really.
My proposal on that topic is to have Dispatcher.Current which can be null. It should be stored by a static field while the dispatcher runs and changed to null when it isn't.

Nope, it's not a real async method, just a factory producing an awaitable. Even .NET itself has Task.Yield without the suffix.

Hi,
As mentioned by others, if we are to follow the WPF spec, Yield must check that it is called in the UI thread and raise an exception if not.
https://github.com/dotnet/wpf/blob/dfa261b64a52a1067a13ad8f8bec19bfbd919b57/src/Microsoft.DotNet.Wpf/src/WindowsBase/System/Windows/Threading/Dispatcher.cs#L353-L377

WPF doesn't check for an "UI thread", it checks if the current thread has an associated dispatcher.
At some point we want to have support for multiple dispatchers though.

WPF doesn't check for an "UI thread", it checks if the current thread has an associated dispatcher. At some point we want to have support for multiple dispatchers though.

Precisely because at the moment avalonia only supports the dispatcher, if it is not the dispatcher's thread it must raise an exception.

WPF doesn't check for an "UI thread", it checks if the current thread has an associated dispatcher. At some point we want to have support for multiple dispatchers though.

Precisely because at the moment avalonia only supports the dispatcher, if it is not the dispatcher's thread it must raise an exception.

This feature just needs to be implemented in a non static way

If the design is to yield to the "current dispatcher", then the method can be static, just like WPF's. The dispatcher is associated with the current thread so a static method can work out which one it should target. This avoids the user having to do that work themselves.

My proposal is to have Yield as static which will try to access the current dispatcher if it is (currently it's UIThread, but it can be captured in a thread local while executing), and in addition to it Resume:
public class Dispatcher
{
    public static DispatcherPriorityAwaiter Yield() =>
        Yield(DispatcherPriority.Background);

    public static DispatcherPriorityAwaiter Yield(DispatcherPriority priority)
    {
        UIThread.VerifyAccess();

        return UIThread.Resume(priority);
    }

    public DispatcherPriorityAwaiter Resume() =>
        Resume(DispatcherPriority.Background);

    public DispatcherPriorityAwaiter Resume(DispatcherPriority priority) =>
        new(priority);
}

The name of Resume can be better, I suppose, but then all parties should be happy. It's WPF compatible and allows continuation on a specific dispatcher using an instance method without any check.

Yield is supposed to change priority of execution under the current thread.

My proposal is to have Yield as static which will try to access the current dispatcher if it is (currently it's UIThread, but it can be captured in a thread local while executing), and in addition to it Resume:
public class Dispatcher
{
    public static DispatcherPriorityAwaiter Yield() =>
        Yield(DispatcherPriority.Background);

    public static DispatcherPriorityAwaiter Yield(DispatcherPriority priority)
    {
        UIThread.VerifyAccess();

        return UIThread.Resume(priority);
    }

    public DispatcherPriorityAwaiter Resume() =>
        Resume(DispatcherPriority.Background);

    public DispatcherPriorityAwaiter Resume(DispatcherPriority priority) =>
        new(priority);
}

The name of Resume can be better, I suppose, but then all parties should be happy. It's WPF compatible and allows continuation on a specific dispatcher using an instance method without any check.

My proposal is:

    /// <summary>
    ///     Returns the Dispatcher for the specified thread.
    /// </summary>
    /// <param name="thread">The thread you want would get Dispatcher</param>
    /// <remarks>
    ///     At this time return Dispatcher only thread is UI thread,
    ///     this method will return null.
    /// </remarks>
    public static Dispatcher? FromThread(Thread thread)
    {
        if (UIThread.CheckAccess())
        {
            return UIThread;
        }
        return null;
    }

    /// <summary>
    ///     Returns an awaitable object that can be used to queue
    ///     continuations at background priority.
    /// </summary>
    public static DispatcherPriorityAwaitable Yield()
    {
        return Yield(DispatcherPriority.Background);
    }

    /// <summary>
    ///     Returns an awaitable object that can be used to queue
    ///     continuations at the specified priority.
    /// </summary>
    public static DispatcherPriorityAwaitable Yield(DispatcherPriority priority)
    {
        Dispatcher currentDispatcher = FromThread(Thread.CurrentThread);

        if (currentDispatcher == null)
        {
            throw new InvalidOperationException("Dispatcher Yield is nto Available");
        }

        return new new(currentDispatcher, priority);
    }

Not different from mine except adding FromThread which might cause an issue later if there are multiple dispatchers allowed because someone should keep a map of thread-dispatcher relations. Having a thread static variable would be enough to get the current dispatcher.

Not different from mine except adding FromThread which might cause an issue later if there are multiple dispatchers allowed because someone should keep a map of thread-dispatcher relations. Having a thread static variable would be enough to get the current dispatcher.

Yes, FromThread is the idea that one day Avalonia will support multiple dispatchers. When it is supported just change FromThread

because I may need to perform an operation on a Dispatcher other than the current one

Yes, and you can get it while its creation, or retrieving it from an AvaloniaObject you have and/or might want to access. If there would be a real case for getting it from a Thread, then let's discuss it first, but at the moment I don't want to pollute Avalonia with a controversial API which then has to be removed. I know that the team is in favor of API stabilization because the customers are not happy when something breaks or requires code changes.

So, I made Yield static like in WPF which behaves exactly the same. It throws if invoked on non-dispatcher thread and yields in other cases. Since there's only one UIThread at the moment it uses that dispatcher.
No CurrentDispatcher is added at the moment because for WPF this property creates a new dispatcher if it doesn't exist. That's unsupported by Avalonia, and I'm not sure about making it nullable.
In addition to static Yield methods there are two Resume which are instance methods and close to what WinRT has.
Also I did a breaking change since I changed DispatcherPriorityAwaiter and DispatcherPriorityAwaitable types. AwaitWithPriority now return a task back.

Closing due to inactivity. Let me know, if this PR should be reopened.

@YohDeadfall,
Please read the following Contributor License Agreement (CLA). If you agree with the CLA, please reply with the following:
@cla-avalonia agree

Contributor License Agreement
Contribution License Agreement
This Contribution License Agreement ( “Agreement” ) is agreed to by the party signing below ( “You” ),
and conveys certain license rights to the AvaloniaUI OÜ ( “AvaloniaUI OÜ” ) for Your contributions to
AvaloniaUI OÜ open source projects. This Agreement is effective as of the latest signature date below.
1. Definitions.
“Code” means the computer software code, whether in human-readable or machine-executable form,
that is delivered by You to AvaloniaUI OÜ under this Agreement.
“Project” means any of the projects owned or managed by AvaloniaUI OÜ and offered under a license
approved by the Open Source Initiative (www.opensource.org).
“Submit” is the act of uploading, submitting, transmitting, or distributing code or other content to any
Project, including but not limited to communication on electronic mailing lists, source code control
systems, and issue tracking systems that are managed by, or on behalf of, the Project for the purpose of
discussing and improving that Project, but excluding communication that is conspicuously marked or
otherwise designated in writing by You as “Not a Submission.”
“Submission” means the Code and any other copyrightable material Submitted by You, including any
associated comments and documentation.
2. Your Submission. You must agree to the terms of this Agreement before making a Submission to any
Project. This Agreement covers any and all Submissions that You, now or in the future (except as
described in Section 4 below), Submit to any Project.
3. Originality of Work.  You represent that each of Your Submissions is entirely Your
original work. Should You wish to Submit materials that are not Your original work,
You may Submit them separately to the Project if You (a) retain all copyright and
license information that was in the materials as you received them, (b) in the
description accompanying your Submission, include the phrase "Submission
containing materials of a third party:" followed by the names of the third party and any
licenses or other restrictions of which You are aware, and (c) follow any other
instructions in the Project's written guidelines concerning Submissions.
4. Your Employer. References to “employer” in this Agreement include Your employer or anyone else
for whom You are acting in making Your Submission, e.g. as a contractor, vendor, or agent. If Your
Submission is made in the course of Your work for an employer or Your employer has intellectual
property rights in Your Submission by contract or applicable law, You must secure permission from Your
employer to make the Submission before signing this Agreement. In that case, the term “You” in this
Agreement will refer to You and the employer collectively. If You change employers in the future and
desire to Submit additional Submissions for the new employer, then You agree to sign a new Agreement
and secure permission from the new employer before Submitting those Submissions.
5. Licenses.
a. Copyright License. You grant AvaloniaUI OÜ, and those who receive the Submission directly
or indirectly from AvaloniaUI OÜ, a perpetual, worldwide, non-exclusive, royalty-free, irrevocable
license in the Submission to reproduce, prepare derivative works of, publicly display, publicly perform,
and distribute the Submission and such derivative works, and to sublicense any or all of the foregoing
rights to third parties.
b. Patent License. You grant AvaloniaUI OÜ, and those who receive the Submission directly or
indirectly from AvaloniaUI OÜ, a perpetual, worldwide, non-exclusive, royalty-free, irrevocable license
under Your patent claims that are necessarily infringed by the Submission or the combination of the
Submission with the Project to which it was Submitted to make, have made, use, offer to sell, sell and
import or otherwise dispose of the Submission alone or with the Project.
c. Other Rights Reserved. Each party reserves all rights not expressly granted in this Agreement.
No additional licenses or rights whatsoever (including, without limitation, any implied licenses) are
granted by implication, exhaustion, estoppel or otherwise.
6. Representations and Warranties. You represent that You are legally entitled to grant the above
licenses. You represent that each of Your Submissions is entirely Your original work (except as You may
have disclosed under Section 3 ). You represent that You have secured permission from Your employer to
make the Submission in cases where Your Submission is made in the course of Your work for Your
employer or Your employer has intellectual property rights in Your Submission by contract or applicable
law. If You are signing this Agreement on behalf of Your employer, You represent and warrant that You
have the necessary authority to bind the listed employer to the obligations contained in this Agreement.
You are not expected to provide support for Your Submission, unless You choose to do so. UNLESS
REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING, AND EXCEPT FOR THE WARRANTIES
EXPRESSLY STATED IN SECTIONS 3, 4, AND 6 , THE SUBMISSION PROVIDED UNDER THIS AGREEMENT IS
PROVIDED WITHOUT WARRANTY OF ANY KIND, INCLUDING, BUT NOT LIMITED TO, ANY WARRANTY OF
NONINFRINGEMENT, MERCHANTABILITY, OR FITNESS FOR A PARTICULAR PURPOSE.
7. Notice to AvaloniaUI OÜ. You agree to notify AvaloniaUI OÜ in writing of any facts or
circumstances of which You later become aware that would make Your representations in this
Agreement inaccurate in any respect.
8. Information about Submissions. You agree that contributions to Projects and information about
contributions may be maintained indefinitely and disclosed publicly, including Your name and other
information that You submit with Your Submission.
9. Governing Law/Jurisdiction. This Agreement is governed by the laws of the Republic of Estonia, and
the parties consent to exclusive jurisdiction and venue in the courts sitting in Talinn,
Estonia. The parties waive all defenses of lack of personal jurisdiction and forum non-conveniens.
10. Entire Agreement/Assignment. This Agreement is the entire agreement between the parties, and
supersedes any and all prior agreements, understandings or communications, written or oral, between
the parties relating to the subject matter hereof. This Agreement may be assigned by AvaloniaUI OÜ.
AvaloniaUI OÜ dedicates this Contribution License Agreement to the public domain according to the Creative Commons CC0 1.

1 out of 2 committers have signed the CLA.

[x] @maxkatz6
[ ] @YohDeadfall

@maxkatz6, it's active on my side. I commented 22 days ago and am waiting for answers from @kekekeks. As an example, see https://github.com/AvaloniaUI/Avalonia/pull/14212#discussion_r1725057465.

@cla-avalonia agree

@maxkatz6, it doesn't need any action on my side. Could you remove the tag, please?

@kekekeks


correcting UUID information

Description of the change:
Reason for the change:
Link to original source:

Closes #

Hello @ksigler7,Thanks again for the PR! We appreciate your contribution and look forward to                                              continued collaboration. Thanks!                                             Team SendGrid DX


[specifications/dsig] Which applications require a dsig table?

It's 2018 and I'm wondering which MS apps depend on this table?
There's no rationale in the test, just a very loose comment.
https://github.com/googlefonts/fontbakery/blob/master/Lib/fontbakery/specifications/dsig.py
I'd love for someone to confirm that MS Office 2013 depends on this table etc and then we can add this to the test rationale.
btw, Fontmake doesn't create a dsig table.
cc @khaledhosny

I can confirm that Word 2016 does not require a DSIG table in TTFs for the OT layout features to be recognized.

:champagne:

Is it possible to revisit this FAIL?  We are still failing default fontmake builds which means that a project must implement a post-compile workaround to pass fontbakery tests when fonts are compiled with fontmake.
I suggest that we either provide explicit rationale for this failure so that users can understand whether to exclude it themselves or (ideally) downgrade to a WARN in the universal profile.
Associated: https://github.com/googlefonts/fontmake/issues/431

I can confirm that, with Windows 10, Word 2013 does require DSIG in some contexts. For example, Stylistic Sets won't work in latin script fonts without DSIG.
(As mentioned above, this is no longer true for Word 2016)

Thanks @bobh0303!  That is helpful.

Office 2013 Extended Support end date is 4/1/2023:

Microsoft Fixed Life Cycle Policy

yea, we'll have to keep the check as-is. We should consider sending a PR to fontmake to ensure it generates fonts with dummy signatures.

Marc raised the issue in https://github.com/googlefonts/fontmake/issues/431 but there was not support for it.

I added all of this information to the rationale for the check in https://github.com/googlefonts/fontbakery/pull/2716

The MS team confirmed the findings by Jens and Bob here through the developer who changed the behavior in MS Word back in 2014. The absence of a DSIG table has not blocked the enumeration of OpenType features in MS Word since.


pyqt/5.x.nix: fix cross

Description of changes
I am able to build pkgsCross.aarch64-multiplatform.python3Packages.pyqt5 with this PR.
Includes:

https://github.com/NixOS/nixpkgs/pull/220518
https://github.com/NixOS/nixpkgs/pull/227900
https://github.com/NixOS/nixpkgs/pull/227901

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

I was able to get PyQt5 to cross compile with this commit.

Fixed merge conflict.


Unclear semantics  in simulator and PHP for equality

Originally reported on Google Code with ID 69

In PHP, the default equals method "==" is based on attribute equality not instance quality
(which is "===").
class X
{
name;
}
So when simulating the code above we would see "new X one" and "new X one" as the same
object. I think I want to keep this PHP convention in place (Umple needs to adapt to
its environment, not the inverse); so I think the way around this is to map objects
in the simulator against their "object_id", which in PHP is:
$obj = new X("one");
spl_object_hash($obj);

Reported by @umple on 2011-06-23 21:35:50

The simulator has not been maintained. Study all issues to do with the simulator if looking at this one.


autodiscovery: true opens connections to new nodes in other data centers

The documentation states that:

When nodes in the cluster are discovered, a Xandra pool of connections is started for each node that is in the same datacenter as one of the nodes in :nodes.

The above is true at startup but doesn't appear to be true later at runtime. When autodiscovery is set to true, Xandra opens connections to all nodes as soon as they become available even if the new node and the control connection are in different data centers.
Replication steps are given below.
Given the description above, I'd guess this is a bug. I think when Xandra receives a NEW_NODE event it should consult system tables to check the location of the new node before starting a connection pool.
I'm happy to look into fixing this if this idea sounds reasonable.
Replicating locally

Start east Cassandra data center, 2 nodes:

$ docker network create xandra-test-network
$ docker run -d --name cassandra-east-1 --network xandra-test-network -e CASSANDRA_DC=east -e CASSANDRA_ENDPOINT_SNITCH=GossipingPropertyFileSnitch -e MAX_HEAP_SIZE=1G -e HEAP_NEWSIZE=256M cassandra:4.0.1
$ docker run -d --name cassandra-east-2 --network xandra-test-network -e CASSANDRA_DC=east -e CASSANDRA_ENDPOINT_SNITCH=GossipingPropertyFileSnitch -e CASSANDRA_SEEDS=cassandra-east-1 -e MAX_HEAP_SIZE=1G -e HEAP_NEWSIZE=256M cassandra:4.0.1

Start west Cassandra data center, 2 nodes:

$ docker run -d --name cassandra-west-1 --network xandra-test-network -e CASSANDRA_DC=west -e CASSANDRA_ENDPOINT_SNITCH=GossipingPropertyFileSnitch -e CASSANDRA_SEEDS=cassandra-east-1 -e MAX_HEAP_SIZE=1G -e HEAP_NEWSIZE=256M cassandra:4.0.1
$ docker run -d --name cassandra-west-2 --network xandra-test-network -e CASSANDRA_DC=west -e CASSANDRA_ENDPOINT_SNITCH=GossipingPropertyFileSnitch -e CASSANDRA_SEEDS=cassandra-east-1 -e MAX_HEAP_SIZE=1G -e HEAP_NEWSIZE=256M cassandra:4.0.1

Check cluster state

$ docker exec -it cassandra-east-1 bash
root@099d258b5d2d:/# nodetool status
Datacenter: east
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens  Owns (effective)  Host ID                               Rack
UN  <IP_ADDRESS>  74.1 KiB   16      51.4%             81551143-3bf3-46ce-97db-c084094c7b20  rack1
UN  <IP_ADDRESS>  69.07 KiB  16      50.8%             9b430614-fdb8-45dc-8295-bf5bd4d3d2ec  rack1

Datacenter: west
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens  Owns (effective)  Host ID                               Rack
UN  <IP_ADDRESS>  69.06 KiB  16      49.1%             705c218d-09c8-4701-ac18-6a965955f132  rack1
UN  <IP_ADDRESS>  74.04 KiB  16      48.7%             48df89ca-cfee-4c95-833d-67ee1ca80510  rack1

Start an Elixir container in the same Docker network

$ docker run -it --rm --name elixir --network xandra-test-network elixir:1.13.2

Connect to the Cassandra cluster using a node from east data center

iex(1)> Mix.install([{:xandra, "~> 0.11"}])
iex(2)> {:ok, cluster} = Xandra.Cluster.start_link(nodes: ["cassandra-east-1"], pool_size: 5)
13:21:17.232 [debug] Control connection for <IP_ADDRESS>:9042 is up

13:21:17.235 [debug] Started connection to {172, 25, 0, 2}

13:21:17.235 [debug] Discovered peers: [{172, 25, 0, 3}]

13:21:17.236 [debug] Started connection to {172, 25, 0, 3}
iex(3)> :sys.get_state(cluster)
%Xandra.Cluster{
  autodiscovered_nodes_port: 9042,
  autodiscovery: true,
  load_balancing: :random,
  node_refs: [{#Reference<0.4050667325.154927106.225421>, {172, 25, 0, 2}}],
  options: [
    protocol_module: Xandra.Protocol.V3,
    idle_interval: 30000,
    protocol_version: :v3,
    pool_size: 5
  ],
  pool_supervisor: #PID<0.741.0>,
  pools: %{{172, 25, 0, 2} => #PID<0.744.0>, {172, 25, 0, 3} => #PID<0.751.0>}
}

Notice that the client started connections to both nodes in this data center. This is as expected.

Start another node in west data center

docker run -d --name cassandra-west-3 --network xandra-test-network -e CASSANDRA_DC=west -e CASSANDRA_ENDPOINT_SNITCH=GossipingPropertyFileSnitch -e CASSANDRA_SEEDS=cassandra-east-1 -e MAX_HEAP_SIZE=1G -e HEAP_NEWSIZE=256M cassandra:4.0.1

The new cluster status is
root@099d258b5d2d:/# nodetool status
Datacenter: east
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens  Owns (effective)  Host ID                               Rack
UN  <IP_ADDRESS>  74.1 KiB   16      43.7%             81551143-3bf3-46ce-97db-c084094c7b20  rack1
UN  <IP_ADDRESS>  69.07 KiB  16      45.7%             9b430614-fdb8-45dc-8295-bf5bd4d3d2ec  rack1

Datacenter: west
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens  Owns (effective)  Host ID                               Rack
UN  <IP_ADDRESS>  69.06 KiB  16      33.3%             705c218d-09c8-4701-ac18-6a965955f132  rack1
UN  <IP_ADDRESS>  93.45 KiB  16      42.1%             9663d344-485a-4023-907c-fb5a9d6717f9  rack1
UN  <IP_ADDRESS>  74.04 KiB  16      35.3%             48df89ca-cfee-4c95-833d-67ee1ca80510  rack1

And Xandra logs the following:
13:23:43.883 [debug] Received event: %Xandra.Cluster.TopologyChange{address: {172, 25, 0, 7}, effect: "NEW_NODE", port: 9042}

13:23:43.883 [debug] Received event: %Xandra.Cluster.StatusChange{address: {172, 25, 0, 7}, effect: "UP", port: 9042}

13:23:43.885 [debug] Started connection to {172, 25, 0, 7}

There is a new connection pool for the new node:
iex(4)> :sys.get_state(cluster)
%Xandra.Cluster{
  autodiscovered_nodes_port: 9042,
  autodiscovery: true,
  load_balancing: :random,
  node_refs: [{#Reference<0.4050667325.154927106.225421>, {172, 25, 0, 2}}],
  options: [
    protocol_module: Xandra.Protocol.V3,
    idle_interval: 30000,
    protocol_version: :v3,
    pool_size: 5
  ],
  pool_supervisor: #PID<0.741.0>,
  pools: %{
    {172, 25, 0, 2} => #PID<0.744.0>,
    {172, 25, 0, 3} => #PID<0.751.0>,
    {172, 25, 0, 7} => #PID<0.759.0>  # <--- New connection pool
  }
}

@hubertpompecki this is very interesting, thanks for the callout!
I'm trying to understand why this would be considered a bug. Is it standard C* client behavior to only autodiscover nodes in the same datacenter?
I'm wondering if instead we should control this behavior with an option, for example autodiscovery: true, autodiscover_only_in_same_datacenter: true or something along those lines.
Also, hey, thank you so much for offering help! I would definitely appreciate it once we reach a good way to approach this 💟  🙃

Thanks, @whatyouhide!
Perhaps a bug is too strong a word but I hope you'll agree that the behaviour here is somewhat inconsistent:

existing nodes in other data centres aren't auto-discovered at startup,
new nodes in other data centres are auto-discovered later at runtime as they become available.

The latter creates a problem because the only load balancing option that is available with autodiscovery: true is :random. This means that the client will start sending some queries to these auto-discovered nodes in distant data centres. This, in turn:

generates additional latency,
may make low-consistency queries less reliable (data replication to distant data centres may be slower although I'm far from being a Cassandra expert).

This is demonstrated below. Given the following cluster:
root@17c8750820f4:/# nodetool status
Datacenter: east
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens  Owns (effective)  Host ID                               Rack
UN  <IP_ADDRESS>  74.11 KiB  16      100.0%            92c20a05-8fd0-4334-a86d-c0f5c5f759e8  rack1

Datacenter: west
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens  Owns (effective)  Host ID                               Rack
UN  <IP_ADDRESS>  93.44 KiB  16      100.0%            d6c8b9cd-1aee-47d8-b908-746f017f9f7c  rack1

<IP_ADDRESS> was the seed node. <IP_ADDRESS> was later brought up at runtime and autodiscovered by Xandra.
iex(2)> {:ok, cluster} = Xandra.Cluster.start_link(nodes: ["cassandra-east-1"], pool_size: 5)
{:ok, #PID<0.740.0>}
iex(3)>
10:53:24.163 [debug] Control connection for <IP_ADDRESS>:9042 is up

10:53:24.166 [debug] Started connection to {172, 25, 0, 2}

10:53:24.166 [debug] Discovered peers: []

10:54:13.881 [debug] Received event: %Xandra.Cluster.TopologyChange{address: {172, 25, 0, 4}, effect: "NEW_NODE", port: 9042}

10:54:13.881 [debug] Received event: %Xandra.Cluster.StatusChange{address: {172, 25, 0, 4}, effect: "UP", port: 9042}

10:54:13.884 [debug] Started connection to {172, 25, 0, 4}
iex(3)> :sys.get_state(cluster)
%Xandra.Cluster{
  autodiscovered_nodes_port: 9042,
  autodiscovery: true,
  load_balancing: :random,
  node_refs: [{#Reference<0.2460134735.578027522.169328>, {172, 25, 0, 2}}],
  options: [
    protocol_module: Xandra.Protocol.V3,
    idle_interval: 30000,
    protocol_version: :v3,
    pool_size: 5
  ],
  pool_supervisor: #PID<0.741.0>,
  pools: %{{172, 25, 0, 2} => #PID<0.744.0>, {172, 25, 0, 4} => #PID<0.751.0>}
}

Queries are now send to the node in the west data centre as well even though the client was seeded using the node from east data centre:
iex(4)> Xandra.Cluster.run(cluster, [], fn conn -> Xandra.execute!(conn, "SELECT * FROM system.local;") end)
#Xandra.Page<[
  rows: [
    %{
      "broadcast_address" => {172, 25, 0, 4},
      "data_center" => "west",
      ...
    }
  ]
]>
iex(4)> Xandra.Cluster.run(cluster, [], fn conn -> Xandra.execute!(conn, "SELECT * FROM system.local;") end)
#Xandra.Page<[
  rows: [
    %{
      "broadcast_address" => {172, 25, 0, 2},
      "data_center" => "east",
      ...
    }
  ]
]>

Opening connections to distant nodes wouldn't be a problem if we had a DC-aware load balancing strategy that would only use nodes in other datacenters as a last resort. This appears to be way other clients work, e.g. Python.
The fact that nodes in other datacenters aren't auto-discovered at startup and that the only available load balancing option is :random suggests that we shouldn't open connections to nodes in distant data centres at all. However, perhaps the true problem here is the fact that we don't have a datacentre-aware load balancing policy that we could use with autodiscovery? All these connections to nodes in other data centres wouldn't matter then and could even serve as a fallback if local nodes can't be reached for some reason.
What do you think @whatyouhide?

Yes, this all makes sense. I would suggest to start by controlling this with an option, such as autodiscover_other_datacenters: true | false, and default that to false. This should solve your issue and provide a fallback for users that were relying on the current behaviour (provided there are any... 😉 ). Would you be willing to give it a shot and work on a PR?

Thanks @whatyouhide
I've been working on a change to introduce :dc_aware load balancing option in the meantime.  It largely overlaps with what autodiscover_other_datacenters would require. I've opened a draft PR with both.


Ошибка при отсутствии обложки

ХА выкидывает ошибку, если у композиции по какой то причине нет обложки.
Версия компонента - последняя.
Версия ХА - последняя.
текст ошибки
2022-05-30 14:40:06 ERROR (MainThread) [aiohttp.server] Error handling request
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/yarl/_url.py", line 170, in __new__
    port = val.port
  File "/usr/local/lib/python3.9/urllib/parse.py", line 178, in port
    raise ValueError(message) from None
ValueError: Port could not be cast to integer value as '8123https:'
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/aiohttp/client.py", line 422, in _request
    url = self._build_url(str_or_url)
  File "/usr/local/lib/python3.9/site-packages/aiohttp/client.py", line 356, in _build_url
    url = URL(str_or_url)
  File "/usr/local/lib/python3.9/site-packages/yarl/_url.py", line 172, in __new__
    raise ValueError(
ValueError: Invalid URL: port can't be converted to integer
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/aiohttp/web_protocol.py", line 435, in _handle_request
    resp = await request_handler(request)
  File "/usr/local/lib/python3.9/site-packages/aiohttp/web_app.py", line 504, in _handle
    resp = await handler(request)
  File "/usr/local/lib/python3.9/site-packages/aiohttp/web_middlewares.py", line 117, in impl
    return await handler(request)
  File "/usr/src/homeassistant/homeassistant/components/http/security_filter.py", line 60, in security_filter_middleware
    return await handler(request)
  File "/usr/src/homeassistant/homeassistant/components/http/forwarded.py", line 222, in forwarded_middleware
    return await handler(request)
  File "/usr/src/homeassistant/homeassistant/components/http/request_context.py", line 28, in request_context_middleware
    return await handler(request)
  File "/usr/src/homeassistant/homeassistant/components/http/auth.py", line 219, in auth_middleware
    return await handler(request)
  File "/usr/src/homeassistant/homeassistant/components/http/view.py", line 137, in handle
    result = await result
  File "/usr/src/homeassistant/homeassistant/components/media_player/__init__.py", line 1086, in get
    data, content_type = await player.async_get_media_image()
  File "/usr/src/homeassistant/homeassistant/components/media_player/__init__.py", line 530, in async_get_media_image
    return await self._async_fetch_image_from_cache(url)
  File "/usr/src/homeassistant/homeassistant/components/media_player/__init__.py", line 1009, in _async_fetch_image_from_cache
    (content, content_type) = await self._async_fetch_image(url)
  File "/usr/src/homeassistant/homeassistant/components/media_player/__init__.py", line 1020, in _async_fetch_image
    return await async_fetch_image(_LOGGER, self.hass, url)
  File "/usr/src/homeassistant/homeassistant/components/media_player/__init__.py", line 1217, in async_fetch_image
    response = await websession.get(url)
  File "/usr/local/lib/python3.9/site-packages/aiohttp/client.py", line 424, in _request
    raise InvalidURL(str_or_url) from e
aiohttp.client_exceptions.InvalidURL: http://<IP_ADDRESS>:8123https://

и вот что в сущности
source_list: Станция
volume_level: 0.5
is_volume_muted: false
media_content_type: music
media_duration: 147
media_position: 44
media_position_updated_at: 2022-05-30T11:32:09.550477+00:00
media_title: Ланфрен-ланфра
media_artist: Михаил Боярский
source: Станция
entity_picture_local: /api/media_player_proxy/media_player.yandex_v?token=21d63c5fc2022487e7679c3ad46192c3ea3458c55d9f617a3db5a112871aa9b3&cache=66dfeeedabf1f022
alice_state: IDLE
device_class: tv
entity_picture: https://
friendly_name: Yandex V
supported_features: 151487

Не смог повторить, чинил вслепую


Prevent crashing on clicking node with attached visual script (with empty function)

Fix https://github.com/godotengine/godot/issues/50337

Hmm and maybe it's broken because currently creating a new function in visual script is broken:

then if we fix this that would not be required


Output pytest results in junit format

One improvement we could make would be outputing the pytest results in junit format which would then allow us to add a test status report displayable in github so that interpreting test results is easier.

Hey team! Please add your planning poker estimate with ZenHub @eurolife @kdutia @opyate


bugfix: delete the JoinOptionPriority for connect panic

It seems a bug of libnetwork. When libnetwork restores the sandbox, it forgets to initialize the epPriority map. So the Join panic. To void the problem, we disable Priority join option. Indeed the moby does not use the Priority join option
Signed-off-by: Eric Li<EMAIL_ADDRESS>
Ⅰ. Describe what this PR did
It seems a bug of libnetwork. When libnetwork restores the sandbox, it forgets to initialize the epPriority map. So the Join panic. To void the problem, we disable Priority join option. Indeed the moby does not use the Priority join option
Ⅱ. Does this pull request fix one issue?

fixes #1550
Ⅲ. Describe how you did it
Ⅳ. Describe how to verify it
Ⅴ. Special notes for reviews

Codecov Report

Merging #1556 into master will decrease coverage by 1.13%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1556      +/-   ##
==========================================
- Coverage    41.1%   39.96%   -1.14%
==========================================
  Files         266      266
  Lines       17313    17915     +602
==========================================
+ Hits         7116     7160      +44
- Misses       9312     9864     +552
- Partials      885      891       +6

Impacted Files
Coverage Δ

daemon/mgr/network.go
68.87% <ø> (-0.08%)
:arrow_down:

daemon/mgr/container_types.go
55.85% <0%> (-20.27%)
:arrow_down:

daemon/mgr/container.go
34.89% <0%> (-14.37%)
:arrow_down:

daemon/mgr/container_utils.go
49.03% <0%> (-6.43%)
:arrow_down:

daemon/logger/jsonfile/utils.go
73.17% <0%> (+1.62%)
:arrow_up:

ctrd/client.go
54.93% <0%> (+10.49%)
:arrow_up:

ctrd/watch.go
75% <0%> (+10.93%)
:arrow_up:

apis/server/server.go
47.36% <0%> (+14.03%)
:arrow_up:

Do we need to add integration test to cover issue #1550 ? @shaloulcy

@allencloud I have added integration test. PTAL

LGTM


Refactor training models into FathomModels

Bob has refactored AlexNet. Other models should mimic its appearance.

Fixed with release 0.9-soft.


Monitoring block table should store changes not current status

Is your feature request related to a problem? Please describe.
The monitoring block table stores repeated entries for each block, one entry for every time block status is polled and reported. This is different to for example the task status table which only stores transitions between states.
This makes the block table very large and a bit awkward to query. In an environment with many blocks (eg 1200) then this starts becoming ridiculous: for example, per-poll monitoring messages are 256kb long.
Describe the solution you'd like
The task status poller should report only changes to block status to the monitoring system: in a large rectangular job, that would give around 3 rows * #total blocks in a run, rather than poll period * #total blocks rows.
Additional context
This comes from scaling up work with Quentin Le Boulc'h at in2p3 in their HTC environment, for LSST/DESC.

@kommav is working on this


Redo path specifications

Closes #93.

Codecov Report

Merging #98 (787e4d8) into master (0f13cf6) will decrease coverage by 27.45%.
The diff coverage is 22.03%.

@@             Coverage Diff             @@
##           master      #98       +/-   ##
===========================================
- Coverage   67.92%   40.47%   -27.46%
===========================================
  Files           9        8        -1
  Lines         820      850       +30
  Branches      121      127        +6
===========================================
- Hits          557      344      -213
- Misses        221      506      +285
+ Partials       42        0       -42

Impacted Files
Coverage Δ

src/tinuous/__main__.py
0.00% <0.00%> (-58.65%)
:arrow_down:

src/tinuous/appveyor.py
32.14% <0.00%> (-48.11%)
:arrow_down:

src/tinuous/base.py
61.60% <ø> (-26.40%)
:arrow_down:

src/tinuous/github.py
30.50% <0.00%> (-23.08%)
:arrow_down:

src/tinuous/travis.py
28.18% <0.00%> (-9.21%)
:arrow_down:

src/tinuous/config.py
74.73% <68.42%> (-16.41%)
:arrow_down:

... and 4 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0f13cf6...787e4d8. Read the comment docs.


Display prerequesites and language information on https://einander-helfen.org/

Reason (Why?)
With the change to the data model, information about language or other pre-requirements for a volunteering position are available. Those offer important information to the user and should be available.
Solution (What?)
When available, display the information from the 'prerequisites' and 'language_skills' on the website
Out of scope
None
Relation to other Issues
#225
Acceptance criteria
Prerequisites as well as language skills required for a volunteering position when available are displayed for entries on the website.

closed with merge of #250


ci(matrix): add windows-latest and macos-latest

Codecov Report

Merging #43 (2d8e727) into master (2f03f29) will not change coverage.
The diff coverage is 80.00%.

:exclamation: Current head 2d8e727 differs from pull request most recent head 0958864. Consider uploading reports for the commit 0958864 to get more accurate results

@@           Coverage Diff           @@
##           master      #43   +/-   ##
=======================================
  Coverage   90.29%   90.29%
=======================================
  Files          38       38
  Lines         948      948
  Branches      229      229
=======================================
  Hits          856      856
  Misses         88       88
  Partials        4        4

Impacted Files
Coverage Δ

packages/nugrpc-api/src/index.ts
0.00% <0.00%> (ø)

packages/nugrpc-codegen/src/index.ts
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2f03f29...0958864. Read the comment docs.


Remove SslKeyStoreConfigurator/SslTrustStoreConfigurator concept

FYI @tokle

controller-server fails:
[ERROR] /source/controller-server/src/main/java/com/yahoo/vespa/hosted/controller/athenz/filter/AthenzTrustStoreConfigurator.java:[5,32] cannot find symbol
[ERROR]   symbol:   class SslTrustStoreConfigurator

The build failure was caused by a class that I forgot to remove. Fixed in latest commit.


Update deps to new hapi scope

@devinivy I added the odd new lines in the testing file to deal with that test failing on node 10 (v.10.15.3) and 12 (v.12.2.0).
The test would complete, all assertions would pass, but would then error out in the onCleanup callback with an ECONNRESET error. As far as I can tell, this happens because the http2 client's response stream hasn't closed, so calling client.destroy() force-ends that stream, triggering an ECONNRESET. Note that calling client.close(), the "graceful/clean" version of that call, closes the stream without error (though takes some extra time to complete).
The current approach ensures the response closes by consuming it via the data handler, which seems to enable the stream to end (without the data handler, the Toys.event(request, 'end') never fulfills, causing the test to timeout. I think? God, I dunno, very quickly got out of my depth.
My bad if I just made a mess of things here :trollface:

Sounds reasonable to me!  Thanks.

Coverage remained the same at 100.0% when pulling 1e946cbb4d5d8c323ee1ffb605dcaed5b3ac0768 on zemccartney:scoping-update into 9afce793de78dad9b2e2269637bdcf9881a91f42 on hapipal:master.


⚠ Bofrost.lu has degraded performance

In 066d608, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1678 ms

Resolved: Bofrost.lu performance has improved in 615f1a1 after 1 hour, 6 minutes.


Login issue

On click of login button in webview not able to redirect to next page .Please reply it's urgent

Can you record a screen video?


Agencies table cleaning

Context
In our database, we have some agencies with metadata that makes no sense.
Requirements
Understand then fix these cases:

[x] municipalities listed, but no county

79 have localities but have a jurisdiction_type that is state or federal . So, the locality is present, but probably just because it's the location of the headquarters. I deleted the localities to reduce confusion.
It looks like many, many of these are specific divisons of agencies, which is a level of fidelity we don't need...I'm going to un-approve many of those.
many of these are independent cities, which give geocoders some trouble. manually done
many of these are out of scope (probation offices, etc)
For the rest, it's just missing. We should probably do a script to fix those in Airtable.

look up the municipality-state's county
look up the county's fips code
add the county_fips code

[x] municipality is a 5-digit number

can fix manually; these are just ZIP codes

fixed in airtable mostly with a script, somewhat manually


deploying

I have problems in uploading files to meteor.com.  so i will learn to deploy on our google cloud

Regarding deployment, I've heard of heroku. But I'm not sure how these things work. Is this related to #8 ?

I've set up heroku. Automatic deploys from master are enabled. Every push to master will deploy a new version of this app. Deploys happen automatically. Once we have #8 done, I'll change heroku to wait for CI to pass before deploy.


Configure gym leaders/E4 through app and store in json file

I would like to be able to right click on the gym leaders listbox to add and remove gym leaders and e4 members.  When a change is made, I would like to update to be stored in a file.

This should also allow the editing of stored info on the gym (editing the command, the open close message, etc...)


Overload operator<< to print position and velocity ned

Signed-off-by: Omar Shrit<EMAIL_ADDRESS>

You are welcome !


fix(html/parser): span

Description:
Fixes:

DUMMY_SP for auto generated elements when they dont exist - body/head/html/tbody/etc
fix span for tables

BREAKING CHANGE:
No
Related issue (if exists):
No

Rebased

Seems like CI is failing?

@kdy1 Fixed, forget to update some tests


Return Result instead of calling .expect() in conversions with chono::DateTime

Checklist

[X] I have searched the existing issues

Summary
The calls to .expect() in impl From<FileTime> for chrono::DateTime<chrono::Utc> makes me nervous, why not use TryFrom?
https://github.com/sorairolake/nt-time/blob/398fb74e7472f9f3f7f8d98532a8bdfca2746e18/src/file_time.rs#L1462-L1500
Additional context
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct

@rjzak Because this conversion is always expected to be successful. Panics should not occur unless there is a bug in the implementation. However, TimeDelta::try_seconds may be replaced by TimeDelta::seconds.

Ok, I feel better then. I'm trying to build a system for storing and analyzing malware, so I expect to encounter dates which may be nonsense.
Thank you!


Temporary disable direnv to avoid loading old nix channel before rebase/merge

Problem
When I want to checkout to old branch for works around merge or rebase, it loads old nix channel and takes long time, disk size.
How
https://github.com/direnv/direnv/issues/550

Upstream has PR, but not yet merged.
So I use direnv disallow for now.