5
ASP.NET Datei einkompilieren
Gepriesen sei das Rauhe Haus,
Ich bin zur Zeit dabei ein Webhandler in VB.NET zu schreiben. Ziel soll eine Webanwendung sein. Nun habe ich einige ASPX Files und eine MasterPage. Das ist alles für ein Admin Bereich. Nun würde ich diese gerne auch alle in einer DLL drinnen haben und nicht offen auf den Server. Jemand eine Idee wie dies zu Bewerkstelligen währe?
LG, J Herbrich
Ich bin zur Zeit dabei ein Webhandler in VB.NET zu schreiben. Ziel soll eine Webanwendung sein. Nun habe ich einige ASPX Files und eine MasterPage. Das ist alles für ein Admin Bereich. Nun würde ich diese gerne auch alle in einer DLL drinnen haben und nicht offen auf den Server. Jemand eine Idee wie dies zu Bewerkstelligen währe?
LG, J Herbrich
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 665603
Url: https://administrator.de/contentid/665603
Ausgedruckt am: 24.11.2024 um 14:11 Uhr
5 Kommentare
Neuester Kommentar
Bei VB.NET kann ich es dir nicht sagen, aber bei C# gibt es sogenannte Code-Behind-Dateien, in der man die Logik unterbringen kann, statt diese Inline in der aspx zu haben.
Aber diese Code-Behind-Datei liegt dennoch auf dem Server, auch wenn der Server diese nicht an den Client ausliefern muss.
Aber diese Code-Behind-Datei liegt dennoch auf dem Server, auch wenn der Server diese nicht an den Client ausliefern muss.
Gibts einen Grund warum du das alte ASP.NET nutzt und nicht ASP.NET Core? Da entsteht beim generieren automatisch eine DLL. Mittlerweile werden auch die Views in einer DLL untergebracht. Klingt als wie wenn du die Anwendung neu schreibst, da würde ich definitiv auf ASP.NET Core setzen. Ist auch nicht mehr plattformgebunden. Kannst du natürlich trotzdem auf Windows laufen lassen wenn du das willst oder musst, aber eine kleine Linux VM bzw. Container reicht.
Das gleiche gilt für VB.NET. Die Sprache wurde ja schon länger eher stiefmütterlich gepflegt. Seit letzten Jahr wird die Sprache offiziell nicht mehr weiterentwickelt. Wenn du nicht stark unter Zeitdruck stehst, würde ich zumindest bei neuen Projekten zu C# wechseln.
Als Disclaimer sei aber dazu gesagt, dass nur weil man die DLL vorher dekompilieren muss statt mit einem Texteditor rein gucken zu können, dies nicht effektiv vor sicherheitstechnischem Murks im Code schützt. Also beispielsweise private Schlüssel oder was anderes, dass niemand in die Finger bekommen soll. Nur als Hinweis, falls das der Grund ist, warum du das willst ^^
Das gleiche gilt für VB.NET. Die Sprache wurde ja schon länger eher stiefmütterlich gepflegt. Seit letzten Jahr wird die Sprache offiziell nicht mehr weiterentwickelt. Wenn du nicht stark unter Zeitdruck stehst, würde ich zumindest bei neuen Projekten zu C# wechseln.
Als Disclaimer sei aber dazu gesagt, dass nur weil man die DLL vorher dekompilieren muss statt mit einem Texteditor rein gucken zu können, dies nicht effektiv vor sicherheitstechnischem Murks im Code schützt. Also beispielsweise private Schlüssel oder was anderes, dass niemand in die Finger bekommen soll. Nur als Hinweis, falls das der Grund ist, warum du das willst ^^
Moin,
soweit ich weiß, kommst Du ohne die aspx-Dateien nicht aus. Allerdings müssen diese keinen Code enhalten - ich vermute mal, dass es darum geht. Wie @tikayevent bereits schrieb, kannst Du den Code aber auslagern. Beschrieben ist dies unter https://docs.microsoft.com/en-us/troubleshoot/aspnet/code-behind-class-f ...
VG
schleeke
soweit ich weiß, kommst Du ohne die aspx-Dateien nicht aus. Allerdings müssen diese keinen Code enhalten - ich vermute mal, dass es darum geht. Wie @tikayevent bereits schrieb, kannst Du den Code aber auslagern. Beschrieben ist dies unter https://docs.microsoft.com/en-us/troubleshoot/aspnet/code-behind-class-f ...
VG
schleeke
Das Code-Behind-Konzept von ASP.NET entspricht genau dem Ansatz, Anwendungslogik sauber von der Seitengestaltung zu trennen. Es sorgt außerdem für einen sauber pfleg- und debugbaren Text. Dabei kann hinsichtlich des Codes noch weiter differenziert werden. In der Code-Behind-Datei ist die gesamte auf die jeweilige ASPX-/ASCX-Datei bezogene Logik enthalten. Genereller Code wie beispielsweise die Funktionen für den Datenbankzugriff oder das Fehlerreporting werden in Namespaces / Classes "ausgelagert" und als kompilierte DLL im bin-Verzeichnis abgelegt. Im Prinzip ist es eine konsequente Modularisierung gemäß der generellen Objektorientierung von ASP.NET.
Das gilt sowohl für VB.NET als auch C#. Setzt man das konsequent um, hat man einen auch später noch relativ leicht (er)lesbaren und pflegbaren Code.
Hier besteht jedenfalls seit mehr als zehn Jahre eine datenbankgestützte Webanwendung, die genau so auf ASP.NET beruht. Daher weiß ich wovon ich spreche.
In der ASPX-Datei lautet die Direktive für Code-Behind mit VB.NET wie folgt:
<%@ Page Language="VB" Debug="true" AutoEventWireup="true" ClassName ="CMyClass" CodeFile="MyWebsite.aspx.vb" Inherits="CMyClass" %>
PS:
Will man an ASP.NET festhalten oder gar vom IIS auf eine Linux-VM wechseln, scheint ASP.NET Core ernsthaft überlegenswert. Hier ist jedenfalls demnächst das nächste Projekt.
Das gilt sowohl für VB.NET als auch C#. Setzt man das konsequent um, hat man einen auch später noch relativ leicht (er)lesbaren und pflegbaren Code.
Hier besteht jedenfalls seit mehr als zehn Jahre eine datenbankgestützte Webanwendung, die genau so auf ASP.NET beruht. Daher weiß ich wovon ich spreche.
In der ASPX-Datei lautet die Direktive für Code-Behind mit VB.NET wie folgt:
<%@ Page Language="VB" Debug="true" AutoEventWireup="true" ClassName ="CMyClass" CodeFile="MyWebsite.aspx.vb" Inherits="CMyClass" %>
PS:
Will man an ASP.NET festhalten oder gar vom IIS auf eine Linux-VM wechseln, scheint ASP.NET Core ernsthaft überlegenswert. Hier ist jedenfalls demnächst das nächste Projekt.
Gepriesen sei das Rauhe Haus,
Es geht darum ein HTTP Modul zu entwickeln was zwei Dinge erledigen soll. Erstens ein Backend bereit stellen und zweitens Templating aus einer Vorlage zu machen.
Ich habe inzwischen ein VirtualPathProvider (System.Web.Hosting) erstellt. Damit soll es möglich sein ASPX Files aus einer Eingebetteten Resource zu laden.
Meine Idee ist die Page Klassen (also den Code mit der ganzen Logik) einfach als Reguläre Klasse zu kompilieren, das ist ja an sich auch kein Problem weil es so gang und gebe ist. Lediglich die ASPX Files aus den Eingebetteten Resourcen zu laden und dann auszuführen ist Schwer. Der IIS schafft es nicht eine Objekt Instanz der Page Klasse zu machen.
In übrigen wird ein ähnliches Konstrukt mit den VirtualPathProvider auch in SharePoint Server eingesetzt wo die ASPX Files in einer MSSQL Datenbank liegen.
LG, J Herbrich
Es geht darum ein HTTP Modul zu entwickeln was zwei Dinge erledigen soll. Erstens ein Backend bereit stellen und zweitens Templating aus einer Vorlage zu machen.
Ich habe inzwischen ein VirtualPathProvider (System.Web.Hosting) erstellt. Damit soll es möglich sein ASPX Files aus einer Eingebetteten Resource zu laden.
Meine Idee ist die Page Klassen (also den Code mit der ganzen Logik) einfach als Reguläre Klasse zu kompilieren, das ist ja an sich auch kein Problem weil es so gang und gebe ist. Lediglich die ASPX Files aus den Eingebetteten Resourcen zu laden und dann auszuführen ist Schwer. Der IIS schafft es nicht eine Objekt Instanz der Page Klasse zu machen.
In übrigen wird ein ähnliches Konstrukt mit den VirtualPathProvider auch in SharePoint Server eingesetzt wo die ASPX Files in einer MSSQL Datenbank liegen.
LG, J Herbrich
