(0) exportieren Drucken
Alle erweitern
Erweitern Minimieren

Intelligenteres Herunterladen von ASP.NET-Dateien in Webanwendungen integrieren

Veröffentlicht: 02. Okt 2006
Von Joe Stagner

Benutzer müssen wahrscheinlich Dateien von der Website Ihrer Organisation herunterladen. Und für die Bereitstellung eines Downloads einfach nur eine Verknüpfung bereitgestellt werden muss, ein Artikel über den Prozess unnötig erscheinen. Aufgrund der zahlreichen Fortschritte im Web gibt es allerdings viele Gründe, aus denen das Verfahren möglicherweise nicht ganz so einfach ist. So soll vielleicht die herunterzuladende Datei wirklich als eine Datei heruntergeladen und nicht als Inhalt im Browser angezeigt werden. Vielleicht ist der Pfad zu den Dateien noch nicht bekannt (oder die Dateien befinden sich überhaupt nicht auf einer Festplatte), und es können daher nicht einfach HTML-Verknüpfungen bereitgestellt werden. Vielleicht stellt auch die Möglichkeit, dass die Netzwerkverbindung während des Herunterladens großer Dateien unterbrochen wird, ein Problem dar.

Der Code kann hier heruntergeladen werden: Downloading2006_09.exe (174 KB)

Dieser Artikel enthält einige Lösungen für diese Probleme, damit der Download schneller und fehlerfrei erfolgen kann. Der Artikel befasst sich auch mit dynamisch erstellten Verknüpfungen und den Möglichkeiten, Standarddateiverhalten zu umgehen. Anhand von Beispielen werden fortsetzbare ASP.NET-gesteuerte Downloads mithilfe von HTTP 1.1-Funktionen veranschaulicht.

Auf dieser Seite

 Die Standard-Downloadverknüpfung
 Erzwingen von Downloads für alle Dateitypen
 Herunterladen sehr großer Dateien in kleinen Teilen
 Eine bessere Lösung
 Fortsetzen fehlgeschlagener Downloads
 Der Autor

Die Standard-Downloadverknüpfung

Eine fehlende Verknüpfung stellt das erste Problem dar. Wenn der Pfad zu einer Datei noch nicht bekannt ist, könnte die Liste der Verknüpfungen einfach zu einem späteren Zeitpunkt einer Datenbank entnommen werden. Sie könnten die Liste der Verknüpfungen sogar dynamisch erstellen, indem Sie die zur Laufzeit in einem Verzeichnis befindlichen Dateien auflisten. In diesem Artikel wird die zweite Angehensweise erläutert.

Stellen Sie sich vor, dass Sie in Visual Basic® 2005 ein DataGrid erstellen und mit den Verknüpfungen zu allen Dateien im Downloadverzeichnis füllen, wie in Abbildung 1 dargestellt. Dabei kann anhand von Server.MapPath auf der Seite der vollständige Pfad zum Downloadverzeichnis (in diesem Fall ./downloadfiles/) abgerufen werden, wobei eine Liste aller Dateien in diesem Verzeichnis unter Verwendung von DirectoryInfo.GetFiles abgerufen und dann mit dem sich daraus ergebenden Array von FileInfo-Objekten eine DataTable mit Spalten für jede der relevanten Eigenschaften erstellt wird. Diese DataTable kann an ein Datenraster auf der Seite gebunden werden, mit dem mit einer HyperLinkColumn-Definition wie folgt Verknüpfungen erstellt werden können:

<asp:HyperLinkColumn DataNavigateUrlField="Name"  
    DataNavigateUrlFormatString="downloadfiles/{0}" 
    DataTextField="Name" 
    HeaderText="File Name:" 
    SortExpression="Name" />

Wenn Sie auf die Verknüpfungen klicken, sehen Sie, dass der Browser jeden Dateityp unterschiedlich behandelt, je nachdem, welche Hilfsanwendungen für das Öffnen jedes Dateityps registriert sind. Wenn Sie auf die .asp-Seite, die .html-Seite, .jpg, .gif oder .txt klicken, wird der Browser selbst geöffnet und kein Dialogfeld „Speichern unter“ angezeigt. Dies liegt daran, dass es sich bei diesen Dateierweiterungen um bekannte MIME-Typen handelt. Also weiß entweder der Browser selbst, wie die Datei darzustellen ist, oder das Betriebssystem verfügt über eine Hilfsanwendung, die der Browser verwendet. Webcasts (.wmv, .avi und so weiter), PodCasts (.mp3 oder .wma), PowerPoint®-Dateien und alle Microsoft® Office-Dokumente sind bekannte MIME-Typen, die ein Problem darstellen, wenn sie nicht standardmäßig inline geöffnet werden sollen.

Abbildung 1: Einfache HTML-Verknüpfungen in einem Datenraster
Abbildung 1:   Einfache HTML-Verknüpfungen in einem Datenraster

Außerdem haben Sie nur einen sehr allgemeinen Zugriffskontrollmechanismus zur Verfügung, wenn Sie ein Herunterladen auf diese Weise zulassen. Sie können den Downloadzugriff von Verzeichnis zu Verzeichnis steuern, aber die Steuerung des Zugriffs auf einzelne Dateien oder Dateitypen würde eine detaillierte Zugriffskontrolle erfordern, was für Webmaster und Systemadministratoren ein sehr arbeitsaufwändiger Prozess ist. Glücklicherweise bieten ASP.NET und .NET Framework eine Reihe von Lösungen, wie z. B.:

  • Verwenden der Methode Response.WriteFile

  • Streaming der Datei mit der Methode Response.BinaryWrite

  • Verwenden der Methode Response.TransferFile in ASP.NET 2.0

  • Verwenden eines ISAPI-Filters

  • Schreiben in ein benutzerdefiniertes Browser-Steuerelement

Erzwingen von Downloads für alle Dateitypen

Die am einfachsten zu verwendende Methode aus der Liste oben ist die Methode Response.WriteFile. Die grundlegende Syntax ist sehr einfach. Diese komplette ASPX-Seite sucht nach einem als Abfragezeichenfolge-Parameter angegebenen Dateipfad und stellt diese Datei dem Client bereit:

<%@ Page language="VB" AutoEventWireup="false" %>
<html>
   <body>
        <%
            If Request.QueryString("FileName") Then
                Response.Clear()
                Response.WriteFile(Request.QueryString("FileName"))
                Response.End()
            End If
        %>
   </body>
</html>

Wenn Ihr Code, der in einem IIS-Workerprozess (aspnet_wp.exe unter IIS 5.0 oder w3wp.exe unter IIS 6.0) ausgeführt wird, Response.Write aufruft, beginnt der ASP.NET-Workerprozess, Daten an den IIS-Prozess zu senden (inetinfo.exe oder dllhost.exe). Die Daten werden während der Übertragung vom Workerprozess zum IIS-Prozess im Speicher gepuffert. In vielen Fällen ist dies kein Anlass zur Sorge. Es ist aber keine ideale Lösung für sehr große Dateien.

Es gibt jedoch auch einen positiven Aspekt. Da die HTTP-Antwort, welche die Datei sendet, im ASP.NET-Code erstellt wurde, haben Sie vollen Zugriff auf alle ASP.NET-Authentifizierungs- und -Autorisierungsmechanismen und können daher Entscheidungen auf der Grundlage des Authentifizierungsstatus, des Vorhandenseins von Identitäts- und Prinzipalobjekten zur Laufzeit oder beliebigen anderen, Ihnen als geeignet erscheinenden Mechanismen treffen.

Sie können daher also bereits vorhandene Sicherheitsmechanismen wie die in ASP.NET enthaltenen Benutzer- und Gruppenmechanismen, Microsoft Server-Add-Ins wie z. B. Autorisierungs-Manager und definierte Rollengruppen, den Active Directory®-Anwendungsmodus (ADAM) oder sogar Active Directory integrieren, um eine feiner abgestufte Kontrolle über Downloadberechtigungen zu erhalten.

Sie können das Standardverhalten bekannter MIME-Typen auch durch Initiieren des Download aus Ihrem Anwendungscode heraus umgehen. Hierfür müssen Sie die angezeigte Verknüpfung ändern. Nachstehend finden Sie den Code zum Erstellen eines Hyperlink, der Daten an die ASPX-Seite zurückgibt:

<!-- in the DataGrid definition in FileFetch.aspx -- >
<asp:HyperLinkColumn DataNavigateUrlField="Name"          
    DataNavigateUrlFormatString="FileFetch.aspx?FileName={0}" 
    DataTextField="Name" 
    HeaderText="File Name:" 
    SortExpression="Name" />

Als Nächstes müssen Sie bei Anforderung der Seite die Abfragezeichenfolge daraufhin überprüfen, ob es sich bei der Anforderung um eine Datenrückgabe handelt, die ein Dateinamenargument enthält, das an den Client-Browser gesendet wird (siehe Abbildung 2). Dank des Content-Disposition-Antwortheaders wird nun ungeachtet des MIME-Typs ein Dialogfeld „Speichern“ angezeigt, wenn Sie auf eine der Verknüpfungen im Raster klicken (siehe Abbildung 3). Beachten Sie auch, dass in dem Beispiel eingeschränkt wurde, welche Dateien heruntergeladen werden; die Einschränkung basiert auf dem Ergebnis des Aufrufens einer Methode mit dem Namen „IsSafeFileName“. Weitere Informationen zu den Gründen für diese Vorgehensweise und dazu, was mit dieser Methode erreicht werden kann, finden Sie in der Randleiste zu unbeabsichtigtem Dateizugriff (möglicherweise in englischer Sprache).

Abbildung 3: Erzwingen eines Dialogfelds zum Dateidownload
Abbildung 3:   Erzwingen eines Dialogfelds zum Dateidownload

Eine wichtige Maßeinheit, die Sie bei der Verwendung dieser Technik in Erwägung ziehen sollten, ist die Größe des Dateidownloads. Sie müssen die Dateigröße beschränken, sonst gehen Sie das Risiko ein, Ihre Site Denial-of-Service-Angriffen auszusetzen. Bei Versuchen, Dateien herunterzuladen, die die Ressourcenkapazität übersteigen, wird ein Laufzeitfehler mit der Meldung ausgelöst, dass die Seite nicht angezeigt werden kann. Möglicherweise wird auch ein Fehler wie im nachfolgenden Beispiel angezeigt:

Server Application UnavailableThe Web application you are attempting to access on this Web server is currently unavailable. Please hit the "Refresh" button in your Web browser to retry your request.Administrator Note: An error message detailing the cause of this specific request failure can be found in the system event log of the Web server. Please review this log entry to discover what caused this error to occur.

Die maximale Größe einer downloadbaren Datei ist ein Faktor der Hardwarekonfiguration und des Laufzeitstatus des Servers. Informationen zu diesem Problem finden Sie im Knowledge Base-Artikel zu der Problemlösung für das Herunterladen großer Dateien, das einen umfangreichen Speicherverlust verursacht und zur Wiederverwendung des Aspnet_wp.exe-Prozesses führt (möglicherweise in englischer Sprache) unter support.microsoft.com/kb/823409.

Diese Methode ist vielleicht charakteristisch für das Herunterladen großer Dateien wie z. B. Videos, besonders auf Webservern, auf denen Windows 2000 und IIS 5.0 (oder Windows Server™ 2003 mit IIS 6.0 im Kompatibilitätsmodus) ausgeführt wird. Das Problem wird bei Webservern mit minimal konfiguriertem Speicher noch verstärkt, da die Datei in den Serverspeicher geladen werden muss, bevor Sie zum Client heruntergeladen werden kann.

Gemäß Erfahrungen mit einem Testcomputer zeigt ein Server, auf dem IIS 5.0 mit 2 GB RAM ausgeführt wird, einen Downloadfehler an, sobald sich die Größe der Dateien 200 MB nähert. Je mehr Benutzerdownloads in einer Produktionsumgebung gleichzeitig ausgeführt werden, desto häufiger führen Einschränkungen im Serverspeicher zu Fehlern beim Download. Die Lösung für dieses Problem erfordert einige weitere einfache Codezeilen.

Herunterladen sehr großer Dateien in kleinen Teilen

Das Problem mit der Dateigröße beim vorherigen Codebeispiel lag daran, dass nur ein einziger Aufruf an Response.WriteFile erfolgte, bei dem die gesamte Quelldatei im Speicher gepuffert wurde. Eine bessere Vorgehensweise für eine große Datei ist es, die Datei in kleineren, „handlicheren“ Teilen zu lesen und an den Client zu senden. Ein Beispiel dafür sehen Sie in Abbildung 4. Diese Version des Page_Load-Ereignishandlers liest mithilfe einer while-Schleife jeweils 10.000 Bytes der Datei und sendet dann diese Dateisegmente an den Browser. Daher ist zur Laufzeit kein signifikanter Teil der Datei im Speicher enthalten. Die Dateisegmentgröße ist derzeit als eine Konstante festgelegt, kann aber auch programmtechnisch geändert oder sogar in eine Konfigurationsdatei verschoben werden, damit sie je nach Servereinschränkungen und Leistungsanforderung geändert werden kann. Ich habe diesen Code mit Dateien mit einer Größe von bis zu 1,6 GB getestet, und die Downloads erfolgten schnell und haben nicht zu einer signifikanten Auslastung des Serverspeichers geführt.

IIS selbst unterstützt das Herunterladen von Dateien mit einer Größe von mehr als 2 GB nicht. Für den Download größerer Dateien müssen Sie FTP, ein Steuerelement eines Drittanbieters, den intelligenten Hintergrundübertragungsdienst (BITS) von Microsoft oder eine benutzerdefinierte Lösung wie das Streaming der Daten durch Sockets an ein von einem Browser gehostetes benutzerdefiniertes Steuerelement verwenden.

Eine bessere Lösung

Aufgrund der allgemeinen Verbreitung von Dateidownloadanforderungen und der ständig wachsenden Größe von Dateien im Allgemeinen hat das ASP.NET-Entwicklungsteam ASP.NET eine spezifische Methode zum Herunterladen von Dateien hinzugefügt, bei der die jeweilige Datei nicht im Speicher gepuffert werden muss, bevor sie an den Browser gesendet wird. Dies ist die Methode Response.TransmitFile, die in ASP.NET 2.0 zur Verfügung steht.

TransmitFileWriteFile verwendet werden, bietet aber in der Regel bessere Leistungsmerkmale. TransmitFile enthält auch zusätzliche Funktionen. Schauen Sie sich den Code in Abbildung 5 an, bei dem mithilfe einiger der zusätzlichen Funktionen des neu hinzugefügten TransmitFile die oben aufgeführten Speicherauslastungsprobleme vermieden werden.

Mit nur einigen Zeile Code konnte ich mehr Sicherheit und Fehlertoleranz hinzufügen. Ich habe hierzu zunächst mithilfe der Dateierweiterung der angeforderten Datei zum Festlegen des MIME-Typs etwas Sicherheit und Logikeinschränkung hinzugefügt. Der angeforderte MIME-Typ wurde in einem HTTP-Header durch Einstellen der Eigenschaft „ContentType“ des Antwortobjekts angegeben:

Response.ContentType = "application/x-zip-compressed"

Damit konnten Downloads nur auf bestimmte Inhaltstypen beschränkt und unterschiedliche Dateierweiterungen einem einzigen Inhaltstyp zugeordnet werden. Beachten Sie auch die Anweisung, mit der ein Content-Disposition-Header hinzugefügt wird. Mit dieser Anweisung kann der Name für die herunterzuladende Datei separat vom ursprünglichen Dateinamen auf der Festplatte des Servers angegeben werden.

In diesem Code wurde durch Hinzufügen eines Präfixes zum Originalnamen ein neuer Dateiname erstellt. Obwohl das Präfix hier statisch ist, könnte ein Präfix auch dynamisch erstellt werden, sodass der heruntergeladene Dateiname niemals mit einem auf der Festplatte des Benutzers bereits vorhandenen Dateinamen in Konflikt tritt.

Was ist aber zu tun, wenn der Download einer großen Datei unterbrochen wird? Der bisherige Code unterscheidet sich bereits erheblich von einer einfachen Downloadverknüpfung, aber unterbrochene Downloads stellen immer noch ein Problem dar, da der Download einer Datei, die bereits teilweise vom Server zum Client verschoben wurde, nicht einfach fortgesetzt werden kann. Alle bisher in diesem Artikel untersuchten Lösungen erfordern, dass der Benutzer bei einem Fehler den Download von Anfang an erneut durchführt.

Fortsetzen fehlgeschlagener Downloads

Für die Frage, wie ein fehlgeschlagener Download fortgesetzt werden kann, sehen Sie sich noch einmal die manuelle Aufteilung einer Datei in einzelne Segmente für die Übertragung an. Obwohl diese Vorgehensweise nicht so einfach ist wie der Code, der die Methode TransmitFile verwendet, hat das manuelle Schreiben eines Codes zum Lesen und Senden einer Datei in einzelnen Segmenten auch seine Vorteile. Zu jedem Zeitpunkt enthält der Laufzeitstatus die Anzahl der Bytes, die bereits an den Client gesendet wurden, und durch das Subtrahieren dieser Anzahl von der Dateigesamtgröße erhalten Sie die Anzahl der Bytes, die noch übertragen werden müssen, damit die Datei vollständig ist.

Wenn Sie sich den Code erneut ansehen, werden Sie feststellen, dass die Lese-/Sende-Schleife als eine Schleifenbedingung das Ergebnis von Response.IsClientConnected überprüft. Mit dieser Prüfung wird sichergestellt, dass die Übertragung unterbrochen wird, wenn keine Verbindung mehr zum Client besteht. Bei der ersten Schleifeniteration, in der die Prüfung fehlschlägt (es besteht keine Verbindung mehr mit dem Webbrowser, der den Dateidownload initiiert hat), bricht der Server die Übertragung von Daten ab, und die Anzahl der zum Fertigstellen der Datei erforderlichen verbleibenden Bytes können aufgezeichnet werden. Zudem kann die vom Client empfangene Teildatei für den Fall gespeichert werden, dass der Benutzer versucht, den fehlgeschlagenen Download abzuschließen.

Für den Rest der Lösung für fortsetzbare Downloads können Sie einige recht unbekannte Funktionen des HTTP 1.1-Protokolls nutzen. Normalerweise wird die statusfreie Eigenschaft von HTTP von Webentwicklern nicht sehr geschätzt, aber in diesem Fall ist die HTTP-Spezifikation eine große Hilfe. Insbesondere stehen zwei HTTP 1.1-Header-Elemente für die anstehende Aufgabe zur Verfügung: Accept-Ranges und Etag.

Das Header-Element Accept-Ranges gibt dem Client (in diesem Fall dem Webbrowser) ganz einfach an, dass dieser Prozess fortsetzbare Downloads unterstützt. Das Entitätstag bzw. das Element Etag gibt einen eindeutigen Bezeichner für die Sitzung an. So könnten also die HTTP-Header, die die ASP.NET-Anwendung für den Beginn eines fortsetzbaren Downloads an den Browser sendet, wie folgt aussehen:

HTTP/1.1 200 OK
Connection: close
Date: Mon, 22 May 2006 11:09:13 GMT
Accept-Ranges: bytes
Last-Modified: Mon, 22 May 2006 08:09:13 GMT
ETag: "58afcc3dae87d52:3173"
Cache-Control: private
Content-Type: application/x-zip-compressed
Content-Length: 39551221

Aufgrund der Header ETag und Accept Header weiß der Browser, dass der Webserver fortsetzbare Downloads unterstützt.

Wenn der Download fehlschlägt, sendet Internet Explorer bei erneuter Anforderung der Datei das ETag, den Dateinamen und den Wertebereich, womit angegeben wird, wie viel der gesamten Datei vor der Unterbrechung bereits heruntergeladen wurde, damit der Webserver (IIS) versuchen kann, den Download fortzusetzen. Diese zweite Anforderung könnte etwa wie folgt aussehen.

GET http://192.168.0.1/download.zip HTTP/1.0
Range: bytes=933714-
Unless-Modified-Since: Sun, 26 Sep 2004 15:52:45 GMT
If-Range: "58afcc3dae87d52:3173"

Beachten Sie, dass das Element If-Range den ursprünglichen ETag-Wert enthält, mit dem der Server die neu gesendete Datei erkennen kann. Zudem wird hier aufgezeigt, dass das Element Unless-Modified-Since das Datum und die Uhrzeit des Beginns des ursprünglichen Downloads enthält. Der Server ermittelt anhand dieses Elements, ob die Datei seit Beginn des ursprünglichen Downloads geändert wurde. Wenn dies der Fall ist, startet der Server den Download von Anfang an.

Das Element Range, das sich ebenfalls im Header befindet, gibt dem Server an, wie viele Bytes dafür erforderlich sind, die Datei fertig zu stellen, und der Server legt mit diesen Informationen fest, an welcher Stelle der Download der Datei fortgesetzt werden soll.

Verschiedene Browser verwenden diese Header auf leicht unterschiedliche Weise. Weitere HTTP-Header, die ein Client senden kann, um die Datei eindeutig zu identifizieren, sind z. B. folgende: If-Match, If-Unmodified-Since und Unless-Modified-Since. Beachten Sie, dass HTTP 1.1 nicht genau vorgibt, welche Header ein Client unterstützen muss. Es ist daher möglich, dass einige Webbrowser keinen dieser HTTP-Header unterstützen und andere Browser einen anderen als die von Internet Explorer® erwarteten Header verwendet.

Standardmäßig schließt IIS einen Header-Satz wie den folgenden ein:

HTTP/1.1 206 Partial Content
Content-Range: bytes 933714-39551221/39551222
Accept-Ranges: bytes
Last-Modified: Sun, 26 Sep 2004 15:52:45 GMT
ETag: "58afcc3dae87d52:3173"
Cache-Control: private
Content-Type: application/x-zip-compressed
Content-Length: 2021408

Dieser Header-Satz umfasst einen anderen Antwortcode als den der ursprünglichen Anforderung. Die ursprüngliche Antwort enthielt einen Code von 200, während diese Anforderung einen Antwortcode von 206, Resume Download, verwendet, der dem Client mitteilt, dass die nachfolgenden Daten keine vollständige Datei darstellen, sondern eine Fortsetzung eines zu einem früheren Zeitpunkt initiierten Downloads sind, dessen Name durch das ETag angegeben ist.

Einige Webbrowser verlassen sich auf den Dateinamen selbst, aber Internet Explorer erfordert ganz spezifisch den ETag-Header. Wenn der ETag-Header nicht in der ersten Downloadantwort oder der Fortsetzung des Downloads enthalten ist, versucht Internet Explorer nicht, den Download fortzusetzen, sondern beginnt stattdessen einen neuen Download.

Damit die ASP.NET-Downloadanwendung eine Funktion für die Fortsetzung von Downloads implementieren kann, muss es möglich sein, die Anforderung (für die Fortsetzung des Downloads) vom Browser abzufangen und mithilfe der HTTP-Header in der Anforderung eine geeignete Antwort im ASP.NET-Code zu erstellen. Dazu ist es erforderlich, die Anforderung an einer früheren Stelle der normalen Verarbeitungssequenz abzufangen.

Und bei dieser Aufgabe hilft .NET Framework. Dies ist ein gutes Beispiel einer grundlegenden Prämisse im Design von .NET: die Bereitstellung einer gut ausgestatteten Objektbibliothek mit Funktionen zur Erledigung eines großen Teils der Standardaufgaben, denen sich Entwickler jeden Tag gegenüber sehen.

In diesem Fall können Sie die Vorteile der IHttpHandler-Schnittstelle nutzen, die vom Namespace System.Web in .NET Framework zum Erstellen Ihres eigenen benutzerdefinierten HTTP-Handlers bereitgestellt wird. Durch Erstellen einer eigenen Klasse, die den IHttpHandler implementiert, können Sie Webanforderungen für einen bestimmten Dateityp abfangen und in Ihrem eigenen Code auf diese Anforderungen antworten, anstatt einfach zuzulassen, dass IIS gemäß seiner Standardverhaltensweisen antwortet.

Der herunterladbare Code für diesen Artikel enthält eine funktionstüchtige Implementierung eines HTTP-Handlers, der fortsetzbare Downloads unterstützt. Obwohl für diese Funktion eine recht große Menge Code erforderlich ist und ihre Implementierung einiges Wissen über HTTP-Abläufe erfordert, macht .NET Framework dies dennoch zu einer relativ einfachen Implementierung. Diese Lösung bietet Funktionen zum Herunterladen sehr großer Dateien, und Sie können weiterhin das Internet durchsuchen, nachdem der Download initiiert wurde. Es gibt allerdings einige Überlegungen zur Infrastruktur, die sich Ihrer Kontrolle entziehen.

So haben zum Beispiel viele Firmen und Internetdienstanbieter ihre eigenen Zwischenspeicherungsmechanismen. Fehlerhafte oder falsch konfigurierte Webcacheserver können durch Beschädigung von Dateien oder vorzeitiges Beenden von Sitzungen Fehler beim Herunterladen großer Dateien verursachen, besonders wenn die Größe der Dateien 255 MB übersteigt.

Wenn Sie Dateien mit einer Größe von mehr als 255 MB herunterladen müssen oder andere benutzerdefinierte Funktionen benötigen, sollten Sie möglicherweise benutzerdefinierte Download-Manager oder solche von Fremdherstellern in Erwägung ziehen. Sie können zum Beispiel ein benutzerdefiniertes Browser-Steuerelement oder eine Browser-Hilfsfunktion erstellen, um Downloads zu verwalten und sie an BITS zu übergeben, oder Sie können die Dateianforderung sogar im benutzerdefinierten Code an einen FTP-Client übergeben. Die Optionen sind endlos und sollten auf Ihre speziellen Bedürfnisse abgestimmt werden.

Von Downloads großer Dateien in zwei Zeilen Code bis hin zu segmentierten, fortsetzbaren Downloads mit benutzerdefinierter Sicherheit: .NET Framework und ASP.NET bieten eine umfassende Palette von Optionen für das Erstellen der für die Endbenutzer der Website am besten geeigneten Download-Methode.

Der Autor

Joe Stagner kam 2001 als ein Technical Evangelist zu Microsoft und ist heute Programm-Manager für die Entwicklergemeinschaft der Gruppe Tools and Platform Products. Seine dreißigjährige Erfahrung auf dem Gebiet der Entwicklung haben ihm die Gelegenheit gegeben, kommerzielle Softwareanwendungen über eine große Vielfalt technischer Plattformen zu erstellen.

Aus der Ausgabe vom September 2006 des MSDN-Magazins.

© 2006 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.


Anzeigen:
© 2014 Microsoft