Benutzer mit den meisten Antworten
Problem beim Versuch eine eigene DLL für CLR zu registrieren ...

Frage
-
Ich versuche folgende Befehle aufzurufen:
CREATE ASSEMBLY [System.DirectoryServices] AUTHOrIZATION dbo FROM 'C:\Windows\microsoft.net\framework\v4.0.30319\System.DirectoryServices.dll' WITH PERMISSION_SET = UNSAFE GO create assembly ManagedCodeAndSQLServer AUTHORIZATION dbo FROM '\\GALILEO2010\GUTACHTEN\UTILITIES\ExchPublicFolders.dll' WITH PERMISSION_SET=UNSAFE
erhalte aber folgende Fehlermeldung(en):
Warnung: Die Microsoft .NET Framework-Assembly 'system.directoryservices, version=4.0.0.0, culture=neutral, publickeytoken=b03f5f7f11d50a3a, processorarchitecture=msil.', die Sie registrieren, wurde nicht vollständig in einer Umgebung mit SQL Server als Host getestet und wird nicht unterstützt. Wenn Sie diese Assembly oder .NET Framework in Zukunft aktualisieren oder warten, ist die CLR-Integrationsroutine möglicherweise nicht mehr funktionsfähig. Ausführliche Informationen finden Sie in der SQL Server-Onlinedokumentation. Meldung 10327, Ebene 14, Status 1, Zeile 4 Fehler bei CREATE ASSEMBLY für die System.DirectoryServices-Assembly, weil die System.DirectoryServices-Assembly für PERMISSION_SET = UNSAFE nicht autorisiert ist. Die Assembly ist autorisiert, wenn eine der folgenden Bedingungen zutrifft: Der Datenbankbesitzer (DBO) hat die UNSAFE ASSEMBLY-Berechtigung, und für die Datenbank ist die TRUSTWORTHY-Datenbankeigenschaft aktiviert; oder die Assembly ist mit einem Zertifikat oder einem asymmetrischen Schlüssel signiert, das bzw. der einen entsprechenden Anmeldenamen mit der UNSAFE ASSEMBLY-Berechtigung aufweist . Meldung 10301, Ebene 16, Status 1, Zeile 2 Die ExchPublicFolders-Assembly verweist auf die system.directoryservices, version=2.0.0.0, culture=neutral, publickeytoken=b03f5f7f11d50a3a.-Assembly, die in der aktuellen Datenbank nicht vorhanden ist. SQL Server hat versucht, die Assembly, auf die verwiesen wird, am gleichen Pfad wie die verweisende Assembly zu suchen und automatisch zu laden. Dieser Vorgang ist jedoch fehlgeschlagen (Ursache: 2(Das System kann die angegebene Datei nicht finden.)). Laden Sie die Assembly, auf die verwiesen wird, in die aktuelle Datenbank, und wiederholen Sie die Anforderung.
Die zweite Meldung stammt von meiner eigenen DLL.
Dort war bei den Verweisen diese ominöse system.directoryservices aufgeführt, konnte dann aber über "nichtverwendete Verweise" entfernt werden.
Trotzdem gelingt mir die Regiatrierung nicht.
Kann mir jemand genau sagen was ich machen muss ?
Antworten
-
Hallo Nico,
Du solltest alles vermeiden, was UNSAFE ist. Das wird eh nur dann funktionieren, wenn Du diesen Server administrierst. Ich wage zu bezweifeln, dass ein Admin eines fremden SQL Servers diese Einstellungen zulässt.
Was genau soll deine Assembly eigentlich machen? Ich dachte, Du willst "nur" eine Datei löschen. Was willst Du dann mit DirectoryServices, System.Web, ...?
Wenn überhaupt, solltest Du lediglich einen Aufruf einer externen Anwendung durchführen. Diese wiederum kann dann deine Befehle ausführen. Dort hast Du dann auch sämtliche Freiheiten, die Du brauchst.
Ob das, was Du da versuchst, überhaupt erfolgreich sein kann, weiß ich mangels näherer Infos zu deinem Vorhaben nicht, es klingt mir aber nicht unbedingt danach.
Gruß, Stefan
Microsoft MVP - Visual Developer ASP/ASP.NET
http://www.asp-solutions.de/ - Consulting, Development
http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community- Als Antwort vorgeschlagen Andreas.WolterMicrosoft employee Dienstag, 27. Januar 2015 12:56
- Als Antwort markiert Dimitar DenkovMicrosoft contingent staff, Administrator Mittwoch, 4. Februar 2015 07:55
-
Hallo Nico,
da stimme ich Stefan zu, man sollte besser nicht den SQL Server als Applikationsserver missbrauchen, das führt nur zu weiteren Problemen und womöglich zu Instabilitäten des SQL Servers.
Falls Du hier versuchst Dein "Von-Hinten-Durch-Die-Brust-Ins-Auge" Problem aus dem Thread ExecuteReader & timeout - verursacht durch Transaktion ? zu lösen, mit einer CLR verlagest Du das Problem nur, Lösen kannst Du es nur mit einem sinnvollerem Konzept.
Olaf Helper
[ Blog] [ Xing] [ MVP]- Als Antwort vorgeschlagen Andreas.WolterMicrosoft employee Dienstag, 27. Januar 2015 12:56
- Als Antwort markiert Dimitar DenkovMicrosoft contingent staff, Administrator Mittwoch, 4. Februar 2015 07:54
Alle Antworten
-
Hallo Nico,
siehe MSDN Supported .NET Framework Libraries; system.directoryservices gehört nicht dazu und zufällig steht in dem Artikel unter "Unsupported Libraries" genau das Assembly als Beispiel, wie man weiter vorgehen kann.
Olaf Helper
[ Blog] [ Xing] [ MVP] -
So, ein (kleiner) Teilerfog:
Die system.directoryservices konnte ich registrieren, indem ich mich expllizit mit dem Account des dbo angelemdet habe.
Ausßerdem wurde die Datei im Pfad ....\2.0.x\ nicht akzeptiert, wohl aber ....\4.0.x
Möglicherweise war auch wichtig noch den asymetrischen Schlüssel zu generieren.
Wie zu erwarten war, geht es aber mit Fehlermeldungen weiter: Diesmal betrifft es die system.web.
Wenn ich diese aber analog zum obigen Verfahren registrieren will, dann wird noch was anderes bemängelt.
Dem muss ich erstmal auf den Grund gehen.
-
Hallo Nico,
Du solltest alles vermeiden, was UNSAFE ist. Das wird eh nur dann funktionieren, wenn Du diesen Server administrierst. Ich wage zu bezweifeln, dass ein Admin eines fremden SQL Servers diese Einstellungen zulässt.
Was genau soll deine Assembly eigentlich machen? Ich dachte, Du willst "nur" eine Datei löschen. Was willst Du dann mit DirectoryServices, System.Web, ...?
Wenn überhaupt, solltest Du lediglich einen Aufruf einer externen Anwendung durchführen. Diese wiederum kann dann deine Befehle ausführen. Dort hast Du dann auch sämtliche Freiheiten, die Du brauchst.
Ob das, was Du da versuchst, überhaupt erfolgreich sein kann, weiß ich mangels näherer Infos zu deinem Vorhaben nicht, es klingt mir aber nicht unbedingt danach.
Gruß, Stefan
Microsoft MVP - Visual Developer ASP/ASP.NET
http://www.asp-solutions.de/ - Consulting, Development
http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community- Als Antwort vorgeschlagen Andreas.WolterMicrosoft employee Dienstag, 27. Januar 2015 12:56
- Als Antwort markiert Dimitar DenkovMicrosoft contingent staff, Administrator Mittwoch, 4. Februar 2015 07:55
-
Hallo Nico,
da stimme ich Stefan zu, man sollte besser nicht den SQL Server als Applikationsserver missbrauchen, das führt nur zu weiteren Problemen und womöglich zu Instabilitäten des SQL Servers.
Falls Du hier versuchst Dein "Von-Hinten-Durch-Die-Brust-Ins-Auge" Problem aus dem Thread ExecuteReader & timeout - verursacht durch Transaktion ? zu lösen, mit einer CLR verlagest Du das Problem nur, Lösen kannst Du es nur mit einem sinnvollerem Konzept.
Olaf Helper
[ Blog] [ Xing] [ MVP]- Als Antwort vorgeschlagen Andreas.WolterMicrosoft employee Dienstag, 27. Januar 2015 12:56
- Als Antwort markiert Dimitar DenkovMicrosoft contingent staff, Administrator Mittwoch, 4. Februar 2015 07:54