none
Auslesen CODE von CLR_SCALAR_FUNCTION? RRS feed

  • Frage

  • Hallo,

    habe erfolgreich SP's geschrieben zum auslesen und Kopieren über alle DB's innerhalb einer Instanz. Nun möchte ich das auch für UDF's machen, aber wie ich sehe komme ich unter sys.objects nur an die SQL_SCALAR_FUNCTION dran. Ich würde aber auch die CLR_SCALAR_FUNCTION benötigen, denn wir haben so einige Assemblies eingehängt.


    Gruß Hipp

    Montag, 8. August 2016 14:04

Antworten

  • Hallo Hipp,

    bitte die Artikel in den Links aufmerksam lesen, sonst schreiben wir aneinander vorbei.

    Im SQL Server sind nur T-SQL Objekte abgelegt, wie herkömmliche gespeicherte Prozeduren, Funktionen. Wie bereits geschrieben findet sich bei CLR Methoden nur noch der Verweis auf die Assembly bzw. der Bytecode.

    Es gibt keinen Quellcode mehr, dazu benötigt man das Visual Studio CLR Projekt, um an den C# bzw. VB.NET Code zu kommen. Theoretisch kannst Du bestenfalls die Assembly, wenn sie auf Platte gespeichert ist, in einem Programm wie dem .NET Reflector, IL Spy oder DotPeek uam. anschauen. Nur werden dabei der MSIL Zwischencode disassembliert und Variablen uam. stimmen nicht mehr mit dem Original überein. Sollte es sich um eine externe/gekaufte Assembly handeln, so kann sogar ein Obfuscator eingesetzt worden sein und man (ein Experte) kann nur mit Mühe erkennen wie der Quellcode aufgebaut ist.

    Gruß Elmar

    Montag, 8. August 2016 15:43
    Beantworter
  • Hallo Hipp,

    und warum dann nicht die Funktion-Deklaration? Das einfachste wäre von vorne herein ein Deploy Skript zu erstellen, anstatt Reverse Engineering zu betreiben.

    Sei es drum: Die Informationen muss man sich aus sys.assembly_modules (Name der Methode sowie sys.parameters für Parameter zusammenbauen. Dazu kommen je nach wie bei "normalen" Funktionen und Prozeduren, das extrahieren von Datentypen usw.

    Dazu muss man das CREATE ASSEMBLY erzeugen über sys.assemblies, sys.assembly_files etc.

    Selbst gestrickt habe ich das noch nicht, weil ich das wie im ersten Absatz halte ;) Einige Ansätze findet man u. a. in SQL Server: How to list all CLR functions/procedures/objects for assembly.

    Gruß Elmar

    Dienstag, 9. August 2016 08:48
    Beantworter

Alle Antworten

  • Hallo,

    wenn ich es richtig verstanden habe, geht es darum die T-SQL Definition der ganzen Objekte auszulesen.

    Nun, CLR Assemblies sind Binaries, da gibt es nichts in Klartext auszulesen. Du kannst sie höchstens aus sys.assembly_files eben als Binary exportieren, um sie auf anderen Systemen wieder zu importieren.


    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    Montag, 8. August 2016 14:30
  • Hallo Hipp,

    den Code kannst Du da nicht auslesen, denn dabei handelt es sich um den übersetzten Code in MSIL. Die Definition der CLR Funktion besteht nur einer Signatur die auf die entsprechende Assembly verweist und deren Einsprungpunkt.

    Welche Bibliotheken gespeichert sind, findet sich in sys.assemblies und deren Inhalte können entweder als externe Datei bzw. als Byte-Code hinterlegt werden und stehen in sys.assembly_files. Einen Einstieg bietet dazu: Abrufen von Informationen zu Assemblys

    Um solche Funktionen zu übertragen braucht man zum einen diese Inhalte, und ggf. auch weitere abhängige Assemblies (ausgenommen der .NET / System-Assemblies). Siehe dazu: Creating an Assembly. Auf der Basis kann man dann die CLR Objekte erstellen, sei es Funktionen, Prozeduren usw., siehe Bereitstellen von CLR-Datenbankobjekten.

    Gruß Elmar

    Montag, 8. August 2016 14:37
    Beantworter
  • Hallo,

    vielen Dank. Aber ich möchte nicht die Assembly als solches, denn da habe ich schon eine SP zum REFRESHEN, sondern ich möchte den Code der Funktion irgenwo her haben.

    Z.B.:

    USE [db]
    SET ANSI_NULLS OFF
    GO
    SET QUOTED_IDENTIFIER OFF
    GO
    ALTER FUNCTION [dbo].[fn_generateLicenseKey]()
    RETURNS [nvarchar](4000) WITH EXECUTE AS CALLER
    AS 
    EXTERNAL NAME [FSSLGenerateLicenseKey].[Function].[GenerateLicenseKey]


    Dieser Code muss ja auch irgendwo in der DB abgelegt sein. Den Code der einfachen UDFs (grün) habe ich schon gefunden, aber diesen nicht.

    SELECT name, type, type_desc, definition, o.object_id
    FROM sys.sql_modules m
    RIGHT JOIN sys.all_objects o ON o.object_id = m.object_id
    WHERE type in ('FN','FS') AND name like 'fn_%' AND schema_id = 1
    ORDER BY name

    Gruß Hipp

    • Bearbeitet Hipp1010 Montag, 8. August 2016 15:13
    Montag, 8. August 2016 14:53
  • Hallo Hipp,

    bitte die Artikel in den Links aufmerksam lesen, sonst schreiben wir aneinander vorbei.

    Im SQL Server sind nur T-SQL Objekte abgelegt, wie herkömmliche gespeicherte Prozeduren, Funktionen. Wie bereits geschrieben findet sich bei CLR Methoden nur noch der Verweis auf die Assembly bzw. der Bytecode.

    Es gibt keinen Quellcode mehr, dazu benötigt man das Visual Studio CLR Projekt, um an den C# bzw. VB.NET Code zu kommen. Theoretisch kannst Du bestenfalls die Assembly, wenn sie auf Platte gespeichert ist, in einem Programm wie dem .NET Reflector, IL Spy oder DotPeek uam. anschauen. Nur werden dabei der MSIL Zwischencode disassembliert und Variablen uam. stimmen nicht mehr mit dem Original überein. Sollte es sich um eine externe/gekaufte Assembly handeln, so kann sogar ein Obfuscator eingesetzt worden sein und man (ein Experte) kann nur mit Mühe erkennen wie der Quellcode aufgebaut ist.

    Gruß Elmar

    Montag, 8. August 2016 15:43
    Beantworter
  • Hallo Elmar,

    sorry, aber wir reden scheinbar doch aneinander vorbei. Den C#-Source habe ich , alles kein Problem. Aber ich möchte die Definition der Function haben:

    ALTER FUNCTION [dbo].[fn_generateLicenseKey]()
    RETURNS [nvarchar](4000) WITH EXECUTE AS CALLER
    AS 
    EXTERNAL NAME [FSSLGenerateLicenseKey].[Function].[GenerateLicenseKey]
    

    Genau diese paar Zeilen möchte ich haben. So wie den Code beim "CREATE PROCEDURE <name>..., den aich ja auch aus diversen System-Tabellen auslesen kann, weil er dort Zeile für Zeile abgespeichert ist. Dass die Assembly als Object ins System integriert wird ist mir klar und deswegen nicht Code-mäßig gelesen werden kann. Es geht mir rein um die 4 Zeilen CODE wie oben stehend.


    Gruß Hipp

    Dienstag, 9. August 2016 08:15
  • Hallo Hipp,

    und warum dann nicht die Funktion-Deklaration? Das einfachste wäre von vorne herein ein Deploy Skript zu erstellen, anstatt Reverse Engineering zu betreiben.

    Sei es drum: Die Informationen muss man sich aus sys.assembly_modules (Name der Methode sowie sys.parameters für Parameter zusammenbauen. Dazu kommen je nach wie bei "normalen" Funktionen und Prozeduren, das extrahieren von Datentypen usw.

    Dazu muss man das CREATE ASSEMBLY erzeugen über sys.assemblies, sys.assembly_files etc.

    Selbst gestrickt habe ich das noch nicht, weil ich das wie im ersten Absatz halte ;) Einige Ansätze findet man u. a. in SQL Server: How to list all CLR functions/procedures/objects for assembly.

    Gruß Elmar

    Dienstag, 9. August 2016 08:48
    Beantworter
  • Hallo Hipp,

    Ich gehe davon aus, dass Elmars Antworten Dir weitergeholfen haben. Solltest Du noch Rückfragen dazu haben, gib bitte Bescheid.

    Gruß,
    Dimitar


    Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „IT-Pros helfen IT-Pros“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.

    Freitag, 26. August 2016 10:52
    Moderator