none
Problem beim Versuch eine eigene DLL für CLR zu registrieren ... RRS feed

  • 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 ?

    Sonntag, 25. Januar 2015 06:45

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

    Montag, 26. Januar 2015 12:03
    Moderator
  • 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]

    Montag, 26. Januar 2015 17:22

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]

    Sonntag, 25. Januar 2015 07:44
  • 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.

    Montag, 26. Januar 2015 11:45
  • 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

    Montag, 26. Januar 2015 12:03
    Moderator
  • 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]

    Montag, 26. Januar 2015 17:22