Forums Neueste Beiträge
 

Unsafe Assembly für CLR-Integration und Schlüssel-Signierung

23/04/2009 - 15:26 von Georg Gungl | Report spam
Hallo NG,

entsprechend der Anleitung
<http://msdn.microsoft.com/de-de/library/ms160866(SQL.90).aspx>
habe ich Schlüsseldateien erzeugt und meine DLLs damit signiert.

Der SQL Server behauptet bei der Installation jedoch:
"Fehler bei CREATE ASSEMBLY fr die 'ConversionFunction'-Assembly, weil die
'ConversionFunction'-Assembly fr 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 fr die Datenbank ist die TRUSTWORTHY-Datenbankeigenschaft aktiviert;
oder die Assembly ist mit einem Zertifikat oder einem asymmetrischen
Schlssel signiert, das bzw. der einen entsprechenden Anmeldenamen mit der
UNSAFE ASSEMBLY-Berechtigung hat. Wenn Sie diese Datenbank wiederhergestellt
oder angefgt haben, vergewissern Sie sich, dass der Datenbankbesitzer dem
richtigen Anmeldenamen auf diesem Server zugeordnet ist. Wenn dies nicht der
Fall ist, beheben Sie das Problem mit sp_changedbowner."

Meine Überlegung: Muss ich meine SelfMade-Keys am SQL Server nicht "bekannt
machen" damit die DLLS als gültig anerkannt werden?! Sonst könnte ja Jeder
kommen... =:-O


BTW allgemeine Fragen zu CLR-Integration:
1) Wie sind Eure Erfahrungen bzgl. Setup-Integration der CLR-Integration?
Integration^2 :)
2) Wie sind Eure Erfahrungen bzgl. Geschwindigkeitsvorteile durch
CLR-Integration? Sprich: Anwendung führt komplexe Datenoperationen nicht
mehr selbst aus sondern startet SP, wo wiederum für die komplexe Operationen
die eigene CLRs verwendet werden. Kommunikation zw. Anwendung und Server
geht schon mal gegen Null, was bei >1Mill. Datensàtze auch viel ausmacht.
Aber wie gut ist SQL Server Inter die Verwendung meiner C#-Methoden gelöst?
Darf man da doch kein Wunder erwarten?

Ciao:
GG ;-)
 

Lesen sie die antworten

#1 Günter Prossliner
23/04/2009 - 16:30 | Warnen spam
Hallo Georg!

entsprechend der Anleitung
<http://msdn.microsoft.com/de-de/library/ms160866(SQL.90).aspx>
habe ich Schlüsseldateien erzeugt und meine DLLs damit signiert.



Ok.

> Der SQL Server behauptet bei der Installation jedoch:
"Fehler bei CREATE ASSEMBLY fr die 'ConversionFunction'-Assembly,
weil die 'ConversionFunction'-Assembly fr 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 fr die Datenbank ist die
TRUSTWORTHY-Datenbankeigenschaft aktiviert; oder die Assembly ist mit
einem Zertifikat oder einem asymmetrischen Schlssel signiert, das
bzw. der einen entsprechenden Anmeldenamen mit der UNSAFE
ASSEMBLY-Berechtigung hat.



Im Endeffekt steht alles da.

Die Signatur ist in diesem Fall NICHT der Strong-Name, sondern eine
"richtige" Signatur.

Wenn Du den Server kontrollierst - und Deinem Assembly vertraust - es ist
wesendlich einfacher die Datenbank welche das Assembly beinhaltet als
"TRUSTWORTHY" zu markieren:

ALTER DATABASE MyDatabase SET TRUSTWORTHY ON


Meine Überlegung: Muss ich meine SelfMade-Keys am SQL Server nicht
"bekannt machen" damit die DLLS als gültig anerkannt werden?! Sonst
könnte ja Jeder kommen... =:-O



Im Endeffekt wird das über Zertifikate (als Login-Objekte) gesteuert. Aber
wie gesagt: Verwende am einfachsten TRUSTWORTHY. Mit Strong-Names hat das
aber alles nichts zu tun.

1) Wie sind Eure Erfahrungen bzgl. Setup-Integration der
CLR-Integration?



Ich weiss nicht wie die Frage genau gemeint ist. Wie leicht sich Assembly in
der DB ausliefern lassen?

Im Endeffekt ist es einfach: Der SQL-Server hàlt die Assemblies intern in
seinen Metadaten. Die Datei ansich wird nicht benötigt. Man kann sogar das
Assembly ohne Datei installieren (als BLOB). Du kannst Dir das auch skripten
lassen: Einfach mittels Kontextmenü "Script Assembly as -> CREATE To ->
...".

Für die einzelnen Objekte musst Du das auch noch machen (CREATE PROC xxx
WITH AS EXTERNAL NAME ). Das kann man auch alles scripten.

Solltest Du die DB mittels VS - Deploy erstellt haben, werden noch extended
properties (z.b. "AutoDeployed" gesetzt (mit SP sys.sp_addextendedproperty).
Diese werden für das Debugging / Deployment benötigt bzw. verwendet. In
einer produktiven Installation sind diese i.d.R. nicht notwendig. Auch die
ganzen "ALTER ASSEMBLY ADD FILE FROM 0x AS 'xxxxx.cs' sind für die
Ausführung nicht notwendig.

2) Wie sind Eure Erfahrungen bzgl. Geschwindigkeitsvorteile durch
CLR-Integration? Sprich: Anwendung führt komplexe Datenoperationen
nicht mehr selbst aus sondern startet SP, wo wiederum für die
komplexe Operationen die eigene CLRs verwendet werden. Kommunikation
zw. Anwendung und Server geht schon mal gegen Null, was bei >1Mill.
Datensàtze auch viel ausmacht.



Generell gesagt profitiert man klarerweise durch die Lokalitàt der Daten
(wie immer). Managed Code hat gegenüber von T-SQL (in welchem Du ja eine SP
auch direkt am Server ausführen musst) - neben dem reicheren Befehlssatz /
Bibliotheken - den Vorteil dass dieser nicht interpretiert sonderen (durch
den JIT-Kompiler) kompiliert wird.

Bei vielen Schleifen, Berechnungen, ... ist dieser Effekt durchaus messbar.

Aber: Grundlegene SQL-Statements (also alles was dann der DB-Engine macht),
sind nachwievor reiner SQL-Code (im managed Code ja einfach SqlCommands).
Und die größten Performanceverbesserungen erreicht man in aller Regel durch
das Tuning dieser Commands bzw. durch entsprechendes DB und Index Design.

Wenn Du also von 1 Mio. Datensàtzen sprichst (was ja noch nicht so viel ist
;-)), dann bringt es tausendmal mehr diese z.b. anstelle eines Cursors mit
einem einzelnen Statements abzufragen bzw. zu aktualisieren (Stichwort Set
basierte Ausführung). Aber jetzt schweife ich ein wenig aus ...

Aber wie gut ist SQL Server Inter die
Verwendung meiner C#-Methoden gelöst? Darf man da doch kein Wunder
erwarten?



Diese Frage verstehe ich leider nicht. Deine C# Methoden werden (wie in
einer Windows-Anwendung) vom JIT-Kompiler kompilert und unter der Kontrolle
des SQL-Servers (welcher einen speziellen CRL Host implementiert)
ausgeführt. So landen div. low-level Routinen (z.b. Exception Policies, Type
und Assembly-Loading, Threading & Synchronization, ...) im SQL-Server Code
welcher das - ggf. bzw. meist anders wie der Standard CLR Host - behandlet.
Das CLR Team hat in der 2.0 er CLR eine Ganze Menge in flexibles CLR Hosting
investiert (sonst hàtte es das SQL-Team warscheinlich niemals genommen ;-)).

OK?
mfg Günter Prossliner

Ähnliche fragen