Verwenden Sie den Azure-Speicheremulator für Entwicklung und Tests (veraltet)

Der Microsoft Azure-Speicheremulator ist ein Tool zum Emulieren der Azure Blob-, -Warteschlangen- und -Tabellendienste für die lokale Entwicklung. Sie können die Anwendung mit den Speicherdiensten lokal testen, ohne ein Azure-Abonnement zu erstellen oder Kosten zu verursachen. Wenn Ihre Anwendung im Emulator erwartungsgemäß funktioniert, können Sie ein Azure-Speicherkonto in der Cloud verwenden.

Abrufen des Speicheremulators

Der Speicheremulator ist als Teil des Microsoft Azure-SDK verfügbar. Sie können den Speicheremulator auch mithilfe des eigenständigen Installationsprogramms installieren (direkter Download). Zum Installieren des Speicheremulators benötigen Sie Administratorrechte auf Ihrem Computer.

Der Speicheremulator wird derzeit nur unter Windows ausgeführt. Verwenden Sie für die Emulation unter Linux den Azurite-Emulator.

Wie der Speicheremulator funktioniert

Der Speicheremulator verwendet zum Emulieren von Azure Storage-Diensten eine lokale Microsoft SQL Server 2012 Express LocalDB-Instanz. Sie können den Speicheremulator für den Zugriff auf eine lokale Instanz von SQL Server statt für den Zugriff auf die LocalDB-Instanz konfigurieren. Weitere Informationen finden Sie weiter unten in diesem Artikel im Abschnitt Starten und Initialisieren des Speicheremulators.

Der Storage Emulator verbindet sich mit SQL Server oder LocalDB über Windows-Authentifizierung.

Es bestehen einige Unterschiede in der Funktionsweise zwischen dem Speicheremulator und den Azure Storage-Diensten. Weitere Informationen zu diesen Unterschieden finden Sie im Abschnitt Unterschiede zwischen dem Speicheremulator und Azure Storage weiter unten in diesem Artikel.

Starten und Initialisieren des Speicheremulators

So starten Sie den Azure-Speicheremulator

1. Wählen Sie die Schaltfläche Start aus, oder drücken Sie die Windows-Taste.
2. Beginnen Sie mit der Eingabe von Azure Storage Emulator.
3. Wählen Sie den Emulator in der Liste der angezeigten Anwendungen aus.

Wenn der Speicheremulator startet, erscheint ein Kommandozeilenfenster. Verwenden Sie dieses Konsolenfenster, um den Speicheremulator zu starten und zu stoppen. Darüber hinaus können Sie über die Eingabeaufforderung Daten löschen, den Status abrufen und den Emulator initialisieren. Weitere Informationen finden Sie im Abschnitt Referenz zum Speicheremulator-Befehlszeilentool weiter unten in diesem Artikel.

Wenn der Emulator läuft, sieht man ein Symbol im Benachrichtigungsbereich der Windows-Taskleiste.

Wenn du das Fenster Storage Emulator Command Prompt schließt, läuft der Storage Emulator weiter. Um das Konsolenfenster des Storage Emulators erneut anzuzeigen, führen Sie die vorherigen Schritte aus, als ob Sie den Storage Emulator starten würden.

Beim ersten Start des Storage Emulators initialisiert er die lokale Speicherumgebung. Durch die Initialisierung wird in LocalDB eine Datenbank erstellt, und es werden für jeden lokalen Speicherdienst HTTP-Ports reserviert.

Der Standardinstallationspfad für den Storage Emulator ist C:\Program Files (x86)\Microsoft SDKs\Azure\Storage Emulator.

Initialisieren Sie den Storage Emulator, um eine andere SQL-Datenbank zu verwenden.

Verwenden Sie das Storage Emulator-Kommandozeilen-Tool, um den Storage Emulator so zu initialisieren, dass er auf eine SQL-Datenbankinstanz verweist, die nicht die Standard-LocalDB-Instanz ist:

1. Öffnen Sie das Konsolenfenster des Speicheremulators gemäß der Beschreibung im Abschnitt Starten und Initialisieren des Speicheremulators.

2. Geben Sie im Konsolenfenster den folgenden Befehl ein, wobei <SQLServerInstance> der Name der SQL Server-Instanz ist. Geben Sie (localdb)\MSSQLLocalDb als SQL Server-Instanz ein, um LocalDB zu verwenden.

   AzureStorageEmulator.exe init /server <SQLServerInstance>

   Mit dem folgenden Befehl können Sie den Emulator anweisen, die SQL Server-Standardinstanz zu verwenden:

   AzureStorageEmulator.exe init /server .

   Sie können auch den folgenden Befehl verwenden, mit dem die Datenbank als Standardinstanz von LocalDB initialisiert wird:

   AzureStorageEmulator.exe init /forceCreate

Weitere Informationen zu diesen Befehlen finden Sie unter Referenz zum Speicheremulator-Befehlszeilentool.

Authentifizieren von Anforderungen an den Speicheremulator

Nachdem du den Storage Emulator installiert und gestartet hast, kannst du deinen Code daran testen. Jede an den Speicheremulator gerichtete Anforderung muss autorisiert werden (es sei denn, es handelt sich um eine anonyme Anforderung). Autorisieren Sie Anfragen gegen den Storage Emulator mittels Shared-Key-Authentifizierung oder mit einer Shared-Access-Signatur (SAS).

Autorisieren mit Benutzeranmeldeinformationen eines gemeinsam verwendeten Schlüssels

Der Emulator unterstützt nur ein einziges festgelegtes Konto und einen bekannten Authentifizierungsschlüssel für die Authentifizierung mit einem gemeinsam verwendeten Schlüssel. Dieses Konto und dieser Schlüssel sind die einzigen gemeinsam verwendeten Anmeldeinformationen, die für den Emulator verwendet werden dürfen. Sie lauten wie folgt:

Account name: devstoreaccount1
Account key: Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw==

Herstellen einer Verbindung mit dem Emulatorkonto über die Verknüpfung

Am einfachsten können Sie über Ihre Anwendung eine Verbindung mit dem Emulator herstellen, indem Sie eine Verbindungszeichenfolge in der Konfigurationsdatei Ihrer Anwendung konfigurieren, die auf die Verknüpfung UseDevelopmentStorage=true verweist. Die Verknüpfung entspricht der vollständigen Verbindungszeichenfolge für den Emulator, die den Kontonamen, den Kontoschlüssel und die Emulatorendpunkte für die einzelnen Azure Storage-Dienste angibt:

DefaultEndpointsProtocol=http;AccountName=devstoreaccount1;
AccountKey=Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw==;
BlobEndpoint=http://127.0.0.1:10000/devstoreaccount1;
QueueEndpoint=http://127.0.0.1:10001/devstoreaccount1;
TableEndpoint=http://127.0.0.1:10002/devstoreaccount1;

Der folgende .NET-Codeausschnitt zeigt, wie Sie die Abkürzung in einer Methode verwenden können, die eine Verbindungszeichenfolge als Parameter entgegennimmt. Der Konstruktor BlobContainerClient(String, String) nimmt zum Beispiel eine Verbindungszeichenfolge an.

BlobContainerClient blobContainerClient = new BlobContainerClient("UseDevelopmentStorage=true", "sample-container");
blobContainerClient.CreateIfNotExists();

Stellen Sie sicher, dass der Emulator ausgeführt wird, bevor Sie den Code im Codeausschnitt aufrufen.

Weitere Informationen zu Verbindungszeichenfolgen finden Sie unter Konfigurieren von Azure Storage-Verbindungszeichenfolgen.

Autorisieren mit einer SAS (Shared Access Signature)

Sie können ein SAS-Token erstellen, indem Sie den Storage-Explorer oder eine andere Anwendung verwenden, die die Shared Key-Authentifizierung unterstützt.

Sie können ein SAS-Token auch mithilfe von Azure PowerShell generieren. Im folgenden Beispiel wird ein SAS-Token mit vollen Berechtigungen für einen Blobcontainer generiert:

1. Installieren Sie Azure PowerShell, sofern noch nicht geschehen (die Verwendung der neuesten Version der Azure PowerShell-Cmdlets wird empfohlen). Installationsanweisungen finden Sie unter Installieren und Konfigurieren von Azure PowerShell.
2. Öffnen Sie Azure PowerShell, und führen Sie die folgenden Befehle aus. Ersetzen Sie hierbei CONTAINER_NAME durch einen Namen Ihrer Wahl:

$context = New-AzStorageContext -Local

New-AzStorageContainer CONTAINER_NAME -Permission Off -Context $context

$now = Get-Date

New-AzStorageContainerSASToken -Name CONTAINER_NAME -Permission rwdl -ExpiryTime $now.AddDays(1.0) -Context $context -FullUri

Die resultierende URI mit Shared Access Signature für den neuen Container sollte in etwa wie folgt aussehen:

http://127.0.0.1:10000/devstoreaccount1/sascontainer?sv=2012-02-12&se=2015-07-08T00%3A12%3A08Z&sr=c&sp=rwdl&sig=t%2BbzU9%2B7ry4okULN9S0wst/8MCUhTjrHyV9rDNLSe8g%3D

Die mit diesem Beispiel erstellte Signatur für den gemeinsamen Zugriff ist einen Tag lang gültig. Die Signatur gewährt uneingeschränkten Zugriff (Lesen, Schreiben, Löschen und Auflisten) auf die Blobs im Container.

Weitere Informationen zu SAS (Shared Access Signatures) finden Sie unter Gewähren von eingeschränktem Zugriff auf Azure Storage-Ressourcen mithilfe von SAS (Shared Access Signature).

Adressieren von Ressourcen im Speicheremulator

Die Dienstendpunkte für den Speicheremulator unterscheiden sich von den Endpunkten für ein Azure-Speicherkonto. Der lokale Computer übernimmt keine Domain-Name-Resolution, daher sind die Storage Emulator-Endpunkte lokale Adressen.

Verwenden Sie das folgende Schema, wenn Sie eine Ressource in einem Azure Storage-Konto adressieren. Hierbei ist der Kontoname Teil des URI-Hostnamens, und die adressierte Ressource ist Teil des URI-Pfads:

<http|https>://<account-name>.<service-name>.core.windows.net/<resource-path>

Der folgende URI ist z. B. eine gültige Adresse für ein Blob in einem Azure-Speicherkonto:

https://myaccount.blob.core.windows.net/mycontainer/myblob.txt

Da der lokale Computer keine Domänennamenauflösung durchführt, ist der Kontoname Teil des URI-Pfads und nicht des Hostnamens. Verwenden Sie das folgende URI-Format für eine Ressource im Speicheremulator:

http://<local-machine-address>:<port>/<account-name>/<resource-path>

Beispielsweise kann für den Zugriff auf ein Blob im Speicheremulator die folgende Adresse verwendet werden:

http://127.0.0.1:10000/myaccount/mycontainer/myblob.txt

Die Dienstendpunkte für den Speicheremulator sind:

• Blob-Dienst: http://127.0.0.1:10000/<account-name>/<resource-path>
• Warteschlangendienst: http://127.0.0.1:10001/<account-name>/<resource-path>
• Tabellendienst: http://127.0.0.1:10002/<account-name>/<resource-path>

Adressieren des sekundären Kontos mit RA-GRS

Ab Version 3.1 unterstützt der Storage Emulator den georedundanten Speicher mit Lesezugriff (RA-GRS). Du kannst auf den sekundären Standort zugreifen, indem du -secondary an den Kontonamen anhängst. Verwenden Sie beispielsweise folgende Adresse, um über die schreibgeschützte Sekundärfunktion im Storage Emulator auf einen Blob zuzugreifen:

http://127.0.0.1:10000/myaccount-secondary/mycontainer/myblob.txt

Referenz zum Speicheremulator-Befehlszeilentool

Ab Version 3.0 erscheint beim Start des Storage Emulators ein Konsolenfenster. Verwenden Sie die Befehlszeile im Konsolenfenster, um den Emulator zu starten und zu beenden. Du kannst auch nach dem Status fragen und andere Operationen über die Kommandozeile ausführen.

Befehlszeilensyntax

AzureStorageEmulator.exe [start] [stop] [status] [clear] [init] [help]

Optionen

Geben Sie zum Anzeigen der Liste der Optionen an der Eingabeaufforderung /help ein.

Unterschiede zwischen dem Speicheremulator und Azure Storage

Da der Speicheremulator eine lokale emulierte Umgebung ist, gibt es Unterschiede zwischen der Verwendung des Emulators und der Verwendung eines Azure-Speicherkontos in der Cloud:

• Der Speicheremulator unterstützt nur ein einziges festgelegtes Konto und einen bekannten Authentifizierungsschlüssel.
• Der Speicheremulator ist kein skalierbarer Speicherdienst und unterstützt keine große Anzahl gleichzeitiger Clients.
• Wie in Adressieren von Ressourcen im Speicheremulatorbeschrieben, werden Ressourcen im Speicheremulator im Vergleich zu einem Azure-Speicherkonto anders adressiert. Der Unterschied besteht darin, dass Domain-Auflösung in der Cloud verfügbar ist, aber nicht auf dem lokalen Computer.
• Ab Version 3.1 unterstützt das Storage Emulator-Konto einen georedundanten Speicher mit Lesezugriff (RA-GRS). Im Emulator ist für alle Konten RA-GRS aktiviert, und es entsteht niemals eine Verzögerung zwischen den primären und sekundären Replikaten. Die Operationen Get Blob Service Stats, Get Queue Service Stats und Get Table Service Stats werden auf dem Konto sekundär unterstützt und geben immer den Wert des Antwortelements LastSyncTime als aktuelle Zeit gemäß der zugrunde liegenden SQL-Datenbank zurück.
• Die Endpunkte für Dateidienst und SMB-Protokolldienst werden im Speicheremulator zurzeit nicht unterstützt.
• Wenn du eine Version der Speicherdienste verwendest, die der Emulator nicht unterstützt, liefert der Emulator einen Fehler VersionNotSupportedByEmulator zurück (HTTP-Statuscode 400 – Bad Request).

Unterschiede für Blob-Speicher

Die folgenden Unterschiede gelten für Blob-Speicher im Emulator:

• Der Speicheremulator unterstützt nur Blob-Größen bis 2 GB.
• Die maximale Länge eines Blobnamens im Speicheremulator ist 256 Zeichen, während sie in Azure Storage 1024 Zeichen beträgt.
• Bei inkrementellen Kopien können Momentaufnahmen von überschriebenen Blobs kopiert werden, wodurch ein Fehler für den Dienst zurückgegeben wird.
• „Get Page Ranges Diff“ funktioniert nicht zwischen Momentaufnahmen, die per inkrementeller Blobkopie kopiert wurden.
• Ein Vorgang vom Typ „Put Blob“ kann ggf. bei einem Blob, das im Speicheremulator vorhanden ist und über eine aktive Lease verfügt, erfolgreich ausgeführt werden, auch wenn die Lease-ID in der Anforderung nicht angegeben wurde.
• Vorgänge für Anfügeblobs werden vom Emulator nicht unterstützt. Beim Versuch, einen Vorgang auf einen Anfügeblob anzuwenden, wird der Fehler „FeatureNotSupportedByEmulator“ (HTTP-Statuscode 400 – Ungültige Anforderung) zurückgegeben.

Unterschiede beim Tabellenspeicher

Die folgenden Unterschiede gelten für Tabellenspeicher im Emulator:

• Datumseigenschaften im Tabellenspeicherdienst im Speicheremulator unterstützen nur den von SQL Server 2005 unterstützten Bereich. (Sie müssen nach dem 1. Januar 1753 liegen.) Alle Datumsangaben vor dem 1. Januar 1753 werden in diesen Wert geändert. Die Genauigkeit der Daten ist begrenzt auf die Genauigkeit von SQL Server 2005, d. h., Datumsangaben sind auf 1/300 Sekunde genau.
• Der Speicheremulator unterstützt Eigenschaftenwerte für Partitions- und Zeilenschlüssel von jeweils weniger als 512 Byte. Die Gesamtgröße des Kontonamens, des Tabellennamens und der Namen der Schlüsseleigenschaften darf zusammen 900 Bytes nicht überschreiten.
• Die Gesamtgröße einer Zeile in einer Tabelle im Speicheremulator ist auf weniger als 1 MB beschränkt.
• Im Speicheremulator unterstützen Eigenschaften des Datentyps Edm.Guid oder Edm.Binary in Filterzeichenfolgen für Abfragen nur die Vergleichsoperatoren Equal (eq) und NotEqual (ne).

Unterschiede beim Warteschlangenspeicher

Es gibt im Emulator keine spezifischen Unterschiede bei Queue Storage.

Speicheremulator – Versionshinweise

Version 5.10

• Der Speicheremulator lehnt Version 2019-07-07 der Speicherdienste an Blob-, Queue- und Table-Dienstendpunkten nicht ab.

Version 5.9

• Der Storage Emulator lehnt die Version 2019-02-02 der Storage Services auf Blob-, Queue- und Table-Service-Endpunkten nicht ab.

Version 5.8

• Der Storage Emulator lehnt die Version 2018-11-09 der Storage Services auf Blob-, Queue- und Table-Service-Endpunkten nicht ab.

Version 5.7

• Einen Fehler behoben, der einen Absturz verursacht, wenn das Logging aktiviert ist.

Version 5.6

• Der Storage Emulator unterstützt bei den Speicherdiensten für Blob-, Queue- und Table-Dienstendpunkte die Version 2018-03-28.

Version 5.5

• Der Storage Emulator unterstützt Version 2017-11-09 der Speicherdienste für Blob-, Queue- und Table-Dienstendpunkte.
• Unterstützung für die Eigenschaft Blob Created hinzugefügt, die die Erstellungszeit des Blobs zurückgibt.

Version 5.4

• Zur Verbesserung der Stabilität der Installation versucht der Emulator nicht mehr, Ports während der Installationszeit zu reservieren. Wenn du Portreservierungen möchtest, nutze die -reserveports Option des Init-Befehls , um sie anzugeben.

Version 5.3

• Der Storage Emulator unterstützt auf den Blob-, Queue- und Table-Dienstendpunkten die Version 2017-07-29 der Speicherdienste.

Version 5.2

• Der Speicheremulator unterstützt nun die Version vom 17.04.2017 der Speicherdienste für Blob-, Warteschlangen- und Tabellenspeicherdienst-Endpunkte.
• Es wurde ein Fehler behoben, aufgrund dessen Tabelleneigenschaftswerte nicht ordnungsgemäß codiert wurden.

Version 5.1

• Es wurde ein Fehler behoben, bei dem der Speicheremulator in einigen Antworten den Header DataServiceVersion zurückgegeben hat, während der Dienst dies nicht getan hat.

Version 5.0

• Das Installationsprogramm des Speicheremulators führt keine Überprüfungen auf vorhandene MSSQL- und .NET Framework-Installationen mehr durch.
• Das Installationsprogramm des Speicheremulators erstellt die Datenbank nicht mehr als Teil der Installation. Das Installationsprogramm erstellt die Datenbank bei Bedarf weiterhin beim Start.
• Die Datenbankerstellung erfordert keine Rechteerweiterungen mehr.
• Portreservierungen werden für den Start nicht mehr benötigt.
• Die folgenden Optionen wurden zu init hinzugefügt: -reserveports (erfordert Rechteerweiterungen), -unreserveports (erfordert Rechteerweiterungen), -skipcreate.
• Über die Speicheremulator-Benutzeroberflächenoption des Taskleistensymbols wird nun die Befehlszeilenschnittstelle gestartet. Die alte GUI ist nicht mehr verfügbar.
• Einige DLLs wurden entfernt oder umbenannt.

Version 4.6

• Der Speicheremulator unterstützt nun die Version vom 31.05.2016 der Speicherdienste für Blob-, Warteschlangen- und Tabellenspeicherdienst-Endpunkte.

Version 4.5

• Ein Fehler wurde behoben, durch den die Installation und Initialisierung fehlschlugen, wenn die zugrunde liegende Datenbank umbenannt wurde.

Version 4.4

• Der Speicheremulator unterstützt jetzt Version 2015-12-11 der Speicherdienste an den Blob-, Queue- und Table-Dienstendpunkten.
• Der Speicheremulator verfügt nun über eine effizientere Garbage Collection für die Verarbeitung zahlreicher Blobs.
• Ein Fehler wurde behoben, durch den die Validierung des Container-ACL-XML-Codes nicht exakt der Validierung durch den Speicherdienst entsprach.
• Ein Fehler, aufgrund dessen die Mindest- und Höchstwerte für „DateTime“ manchmal in der falschen Zeitzone gemeldet wurden, wurde behoben.

Version 4.3

• Der Speicheremulator unterstützt nun die Version vom 08.07.2015 der Speicherdienste für Blob-, Warteschlangen- und Tabellenspeicherdienst-Endpunkte.

Version 4.2

• Der Speicheremulator unterstützt nun die Version vom 05.04.2015 der Speicherdienste für Blob-, Warteschlangen- und Tabellenspeicherdienst-Endpunkte.

Version 4.1

• Der Speicheremulator unterstützt nun die Version vom 21.02.2015 der Speicherdienste für Blob-, Warteschlangen- und Tabellenspeicherdienst-Endpunkte. Es unterstützt die neuen Funktionen für Append Blobs nicht.
• Der Emulator gibt nun eine sinnvolle Fehlermeldung für nicht unterstützte Versionen von Speicherdiensten zurück. Verwende die neueste Version des Emulators. Wenn Sie den Fehler „VersionNotSupportedByEmulator“ (HTTP-Statuscode 400: ungültige Anforderung) erhalten, laden Sie die neueste Version des Emulators herunter.
• Einen Fehler behoben, bei dem eine Rennbedingung dazu führte, dass Tabellenentity-Daten während gleichzeitiger Merge-Operationen falsch waren.

Version 4.0

• Die ausführbare Datei des Speicheremulators wurde in AzureStorageEmulator.exeumbenannt.

Version 3.2

• Der Speicheremulator unterstützt nun die Version vom 14.02.2014 der Speicherdienste für Blob-, Warteschlangen- und Tabellenspeicherdienst-Endpunkte. Endpunkte für den Dateidienst werden im Speicheremulator derzeit nicht unterstützt. Weitere Informationen zu Version 2014-02-14 finden Sie unter Versionsverwaltung für die Azure-Speicherdienste.

Version 3.1

• Der Storage Emulator unterstützt nun Lesezugriff auf georedundante Speichersysteme (RA-GRS). Es unterstützt die Get Blob Service Stats, Get Queue Service Stats, und Get Table Service Stats APIs für das sekundäre Konto und gibt stets den Wert des Antwortelements LastSyncTime als aktuelle Zeit gemäß der zugrunde liegenden SQL-Datenbank zurück. Für programmgesteuerten Zugriff auf den sekundären Speicherort mit dem Speicheremulator verwenden Sie die Speicherclientbibliothek für .NET, Version 3.2 oder höher. Weitere Informationen finden Sie in den Azure Storage-Client-Bibliotheken für .NET.

Version 3.0

• Der Azure Storage Emulator ist nicht mehr im selben Paket wie der Compute-Emulator enthalten.
• Die grafische Benutzeroberfläche des Speicheremulators ist veraltet. Microsoft ersetzte sie durch eine skriptbare Kommandozeilenoberfläche. Details zur Kommandozeilen-Schnittstelle finden Sie unter Storage Emulator Command-Line Tool Reference. Die grafische Oberfläche ist weiterhin in Version 3.0, aber man kann darauf nur zugreifen, wenn der Compute Emulator installiert ist. Um darauf zuzugreifen, klicke mit der rechten Maustaste auf das Systemleisten-Symbol und wähle die Benutzeroberfläche des Speicher-Emulators anzeigen.
• Der Storage Emulator unterstützt nun vollständige Versionen 2013-08-15 der Azure-Speicherdienste. (Zuvor wurde diese Version nur von Storage Emulator Version 2.2.1 Preview unterstützt.)

Nächste Schritte

• Testen Sie den plattformübergreifenden, von der Community gepflegten Open-Source-Storage-Emulator Azurite.
• Azure Storage-Beispiele mit .NET enthält Links zu mehreren Codebeispielen, die Sie bei der Anwendungsentwicklung verwenden können.
• Verwenden Sie den Microsoft Azure Storage-Explorer, um mit Ressourcen in Ihrem Cloud-Speicherkonto und im Storage Emulator zu arbeiten.

Siehe auch

• Lokale Azure Storage-Entwicklung mit Azurite, Azure SDKs und Azure Storage-Explorer