Hallo liebe Community.

Ich sitze gerade an einem Projekt, in das ich eine DLL (von mir) importiert habe.
Nunja, beim Realese ist die DLL ja im Ordner und kann deswegen auch importiert werden. Also von allen anderen genutzt werden.
Dies möchte ich aber nicht. Kann man das irgendwie verhindern?
Ich könnte theoretisch die ganzen Klassen zum Projekt hinzufügen, nur das wäre dann relativ viel Arbeit.

Ist es anders möglich?

Danke schonmal für eure Antworten

Ist doch egal, ich kann sie so oder so auslesen, das macht keinen Unterschied.

Dass du (und wahrscheinlich viele Andere hier) das kannst ist mir bewusst.
Nur sollte halt die Leute abhalten die das einfach probieren/nicht so erfahren sind.

Gruß

Wenn du 0815 Benutzer abhalten willst die keinen Decompiler haben, könntest du ein Passwort benutzen, welches die Funktionen der Lib erst unlocked.

Und, wenn Du Deine ganzen Klassen in die .exe steckst, importiere ich die .exe. Assembly ist Assembly.

ThuCommix schrieb:

Wenn du 0815 Benutzer abhalten willst die keinen Decompiler haben, könntest du ein Passwort benutzen, welches die Funktionen der Lib erst unlocked.

Dieses Passwort müsste dann aber in der Lib stehen, nicht?

SpaceyX schrieb:

Und, wenn Du Deine ganzen Klassen in die .exe steckst, importiere ich die .exe. Assembly ist Assembly.

Ich dachte eher daran das ganze (die Assembly) nicht importfähig zu machen.
Also mann sie einfach nicht importieren kann (beim Realese).

Das ist unmöglich. Hier gilt auch wieder, solange der Computer (in dem Fall die CLR) noch dran kommt, kommt jeder dran.

ich denke aber, dass es möglich ist die lib zu schützen oder?
z.B die ganze Controll anbieter wie devexpress lassen die dll doch auch nicht einfach so einbinden?

Okay, danke.
Werde evtl. ThuCommix Idee mit dem Passwort verwirklicken, aber das wäre dann im Code, nicht?
Würde es etwas bringen, wenn ich sie Md5 hashe und die dann vergleiche?

@windowsfan

Ja, muss doch irgendwie möglich sein.
Vielleicht kommuniziert z.B devexpress aber auch mit deren Server.

also mit md5 wirste nicht weit kommen, da halt dann der hash in der dll steht

Ja, ist mir bekannt.
Aber besser als es im Klartext zu speichern? Eigentlich nicht.

Mmh..werde das wohl sein lassen.

windowsfan schrieb:

ich denke aber, dass es möglich ist die lib zu schützen oder?
z.B die ganze Controll anbieter wie devexpress lassen die dll doch auch nicht einfach so einbinden?

ich denke doch.
Kaufe ich die Lib, kann ich sie einbinden ohne weiteres.

Denk ich jdfs. - Erfahrung habich nicht damit

ja aber holste dir nur die testversion, hast du zugang zu allen funktionen bzw. controls aber nach gewisser zeit nichtmehr

Sicherlich wäre es möglich die DLL zu verschlüsseln, in die Resourcen packen, sie beim Programmstart aus den Resourcen entschlüsseln ins Temp Verzeichnis und sie dann einzubinden. Aber wer das weiß könnte sie natürlich aus dem Temp Ordner kopieren. Also 100% sichere gibts nicht, nur eben so etwas erschweren. Frage ist nur ob sich das lohnt.

ThomasProj schrieb:

Kann man das irgendwie verhindern?

Gib die DLL nicht weiter.

Ich sehe das so wie @Dodo:
Habe ich eine supertolle einzigartige Idee, dann sollte ich diese auch vermarkten/rechtlich schützen lassen, da sie einen bestimmten Wert hat.
Ist mein Nutzen allerdings sehr gering, so muss ich die Klasse/das Programm whatever auch nicht "schützen", da es eh niemanden interessiert.
(Höchstens für persönliche Projekte oder sowas in der Art, aber da ist ja auch egal)

(Für die SoWi-Freunde unter uns, wenn mein Gewinn/Nutzen-Verhältnis über der Geraden steht lohnt es sich (auch da nur am einem bestimmten "Wert") )

RodFromGermany schrieb:

ThomasProj schrieb:

Kann man das irgendwie verhindern?

Gib die DLL nicht weiter.

Sie liegt ja dem Programm bei, oder meinst du das anders?

LaMiy schrieb:

Ich sehe das so wie @Dodo:
Habe ich eine supertolle einzigartige Idee, dann sollte ich diese auch vermarkten/rechtlich schützen lassen, da sie einen bestimmten Wert hat.
Ist mein Nutzen allerdings sehr gering, so muss ich die Klasse/das Programm whatever auch nicht "schützen", da es eh niemanden interessiert.
(Höchstens für persönliche Projekte oder sowas in der Art, aber da ist ja auch egal)

(Für die SoWi-Freunde unter uns, wenn mein Gewinn/Nutzen-Verhältnis über der Geraden steht lohnt es sich (auch da nur am einem bestimmten "Wert") )

So gesehen hast du Recht, ja.
Ich denke nicht, dass sie irgendjemandem etwas nützt, ist eher für mich.
Danke dir, habe darüber noch nicht nachgedacht.

ist es möglich, bei einem aufruf einer funktion den caller festzustellen?
ich hab sowas ähnliches mal gemacht, in dem ich selbst nen perfiden (also nix mit hohen kenntnissen) plugin-loader gebastelt hab.
mit irgendeiner funktion konnte ich danna uch den aufrufer einer funktion eines plugins ermitteln. weiß aber nich mehr wie...

wenn das also geht, und es von den anderen auch evtl empfohlen wird, dann...
versuch doch in den funktionen (oder nur in den "sub new()") den caller ausfindig zu machen. wenn der dann == deine exe ist, is alles ok

ThomasProj schrieb:

Sie liegt ja dem Programm bei

Ich gehe mal davon aus, dass das eine .NET-DLL ist, die sich in Deiner Projektmappe befindet.
Probier folgendes:
Erstell ein CLI-DLL-Projekt (managed C++) mit allen Klassen und Eintrittspunkten, die die DLL braucht, auch Control-relevante Sachen.
Erstell ein C++-DLL-Projekt (nativ C++) mit allem, was Du schützen willst und füge die LIB dieser DLL dem CLI-DLL-Projekt als Verweis hinzu.
Du musst unbedingt ein separates unmanaged-C++-Projekt erstellen, denn wenn Du unmanaged C++-Klasse einem CLI-Projekt direkt hinzufügst, sind diese direkt auslesbar.

So wie ich das verstanden habe, dürfte diese Lösung das richtige für dich sein:

Definiere alle Klassen und Schnittstellen in der DLL als "Friend" (VB) bzw. "internal" (C#) (bis auf die, die explizit an "Fremdanwendungen" übergeben werden sollen, falls du sowas da drin hast). Das macht es fremden Anwendungen/Assemblys nicht möglich, auf die Klassen und/oder Schnittstellen nach einem Verweis zuzugreifen.

Nun, sagst du vermutlich, das ist ja gut und schön, aber dann kann ja deine eigene Anwendung ebenfalls nicht darauf zugreifen? Richtig... aber...

Es gibt da einen kleinen Trick. Und zwar baust du in den Code deiner DLL folgende Zeile ein:


Wobei du das "XXX" durch den Namen der Assembly deiner Anwendung ersetzt. Und schon wird deine Anwendung wie ein "Friend" deiner DLL behandelt und somit stehen alle Klassen und Schnittstellen wieder zur Verfügung.

Der beste Ort für diese Zeile ist die AssemblyInfo.vb im Projektordner der DLL, aber es geht auch jede andere zum Projekt gehörende Code-Datei außerhalb einer Klassen-Definition (selbst ausprobiert, da ich zunächst nicht geschnallt hatte, wo die Zeile "eigentlich" hingehört).