À part le redémarrage de SQL Server, existe-t-il un moyen de forcer la réinitialisation de l'AppDomain SQLCLR?

Je souhaite forcer la réinitialisation de l'AppDomain utilisé par SQLCLR. Comment puis-je faire cela en plus de redémarrer l'instance SQL Server?

Je sais que c'est un peu brutal, mais qu'en est-il de désactiver le CLR et de le réactiver?

sp_configure 'show advanced options', 1;
GO
RECONFIGURE;
GO
sp_configure 'clr enabled', 0;
GO
RECONFIGURE;
GO
sp_configure 'clr enabled', 1;
GO
RECONFIGURE;
GO

Il existe une solution plus élégante qui n'affectera pas tous les autres assemblys: modifiez simplement le PERMISSION_SET de l'un des assemblys du domaine d'application (les domaines d'application sont par utilisateur).

ALTER ASSEMBLY [AssemblyName] WITH PERMISSION_SET = {1 of the 2 levels that 
                                                      this assembly is not current at}

N'oubliez pas que vous devrez remettre le PERMISSION_SET sur ce qu'il était. De plus, vous devez accéder à une méthode dans l'assembly avant de modifier le PERMISSION_SET pour le décharger; la modification d'un assembly qui n'est pas actuellement chargé dans un domaine d'application actif, mais avec un autre assembly, n'a aucun effet sur le domaine d'application (les domaines d'application sont par base de données, par utilisateur et non par assemblage).

MISE À JOUR
La méthode décrite ci-dessus est l'approche la plus fine où elle ne déchargera qu'un seul domaine d'application. Mais, cela nécessite que l'ensemble puisse être défini sur l'un des deux autres niveaux. Pour les assemblages marqués comme SAFEcela ne sera possible que si

• la base de données est définie sur TRUSTWORTHY ON, ou
• l'assembly est signé et une connexion, basée sur une clé asymétrique qui est elle-même basée sur la même signature que l'assembly, existe et a reçu la EXTERNAL ACCESS ASSEMBLYou la UNSAFE ASSEMBLYpermission

Dans ce cas, vous pouvez simplement modifier le TRUSTWORTHYparamètre ON, puis immédiatement à OFFnouveau et cela déchargera tous les domaines d'application dans cette base de données particulière:

ALTER DATABASE CURRENT SET TRUSTWORTHY ON;
ALTER DATABASE CURRENT SET TRUSTWORTHY OFF;

Si vous n'avez de toute façon qu'un seul domaine d'application (et je soupçonne que c'est le cas à 95% ou plus du temps), les deux méthodes décrites ici ont le même effet net. Et dans cette situation, la ALTER DATABASEméthode semble plus simple car elle ne nécessite pas de spécifier un nom d'objet particulier ni de savoir ce qu'était l'original PERMISSION_SET.

AUSSI, si vous ne disposez que d'un seul domaine d'application, la ALTER DATABASEméthode est plus simple, même dans le cas où la base de données est déjà définie sur TRUSTWORTHY ONou que vous avez configuré la connexion à la base de clés avec l'autorisation appropriée. Si vous utilisez un login par clé vous pouvez définir TRUSTWORTHYà ONpuis à OFFnouveau comme mentionné ci - dessus. Mais si vous l'avez déjà TRUSTWORTHYdéfini ON, inversez-le et définissez-le OFF, puis revenez immédiatement à ON:

ALTER DATABASE CURRENT SET TRUSTWORTHY OFF;
ALTER DATABASE CURRENT SET TRUSTWORTHY ON;