Archiviazione tabella di Azure: impossibile stabilire una connessione perché la macchina di destinazione lo ha rifiutato attivamente 127.0.0.1:10002

Question

Sto sviluppando un sito Web ASPA MVC che utilizza l'archiviazione della tabella in Visual Studio 2015 su Windows 8. È stato lavorando bene nell'ambiente di sviluppo (quando ho impostato UseDevelopmentStorage=true nel mio web.config). Sto cercando di colpire "http://localhost:80" Devo usare questo e non posso usare un'altra porta, ho un altro programma che sto postando al mio sito con e pubblicherà solo in quella posizione.

Ho recentemente eseguire il sito e ottenere il seguente errore quando il mio codice ottiene la seguente riga di codice: tavolo CloudTable = cloudTableClient.GetTableReference (tableName);

Errore:

No connection could be made because the target machine actively refused it 127.0.0.1:10002

Ho provato la seguente:

1) Uninstall-Package WindowsAzure.Storage -Version 6.1.0 e reinstallato da NuGet

2) riavviato Windows

3) Browsed qui C:\Program Files\Microsoft SDKs\Azure\.NET SDK\v2.7\bin e ran cspack.ext (non sono riuscito a vedere nient'altro che sembra riguardare lo spazio di archiviazione)

Non funziona ancora. Qualche idea su cosa potrei provare?

Aggiornamento:

Dopo avere ottenuto l'errore di cui sopra ho aperto la finestra Nuvola Explorer e potuto vedere le tabelle che avevo creato localmente in dev con il mio codice (assumere questo significa il mio emulatore storage locale è in esecuzione) ma ho ancora ottenuto l'errore. Ho quindi chiuso la finestra e l'ho riaperta. Si è allargato un po 'espandendo gli "Account di archiviazione (classico)" ma alla fine ha mostrato le tabelle che avevo creato.

Ciò che è strano è che l'unico nodo nella finestra "Cloud Explorer" è "Account di archiviazione (classico)", sono sicuro che prima c'era un elenco di altri nodi (ad esempio WebApps ecc.). Se qualcuno può aiutarti, puoi postare le istruzioni passo passo su cosa fare (non qualcosa come "l'emulatore non è in esecuzione"). Nuovo per questo, in cerca di istruzioni semplici che la mia gran vorrebbe capire.

Molto apprezzato.

Answer 1

È necessario avviare l'emulatore di archiviazione. Si trova in %programfiles(x86)%\Microsoft SDKs\Azure\Storage Emulator\AzureStorageEmulator.exe.

Come bonus, ecco uno script batch per ripulire l'emulatore, nonché avviarlo.

SET emu="%programfiles(x86)%\Microsoft SDKs\Azure\Storage Emulator\AzureStorageEmulator.exe" 
%emu% stop 
%emu% clear all 
%emu% start 

UPDATE

La differenza tra "nuovi" conti di storage classico e può essere trovato here.

Classic storage accounts are created using existing Service Management API's (the REST API stack that's been available for the past several years). The newer storage accounts are created with the new Azure Resource Manager (ARM) API's (which are also wrapped in PowerShell and CLI now). Ultimately they provide the same resources to your apps, but they're created/managed differently, and there are a few nuanced differences (such as the ability to tag resources that are created via ARM scripts).

You can't convert a classic storage account (or any classic resource) to a newer type. You don't really need to anyway, unless you're trying to mix resources from classic and new, such as adding ARM-based virtual machines to a classic-based virtual network, or spin up an ARM-based VM from a vhd image sitting in a classic storage account (and for that example, you could always just copy the vhd to a new storage account). Note that, for general storage usage (blobs/tables/queues), you just need the URI and the primary (or secondary) key. With those, you can access your storage resources from anywhere, from any VM/website/etc, regardless if you're accessing storage from classic or new virtual machines, for example.

TL; DR: La differenza è l'API utilizzata per gestire l'account di archiviazione. Le API e gli SDK esistenti per scaricare/caricare i dati sui contenitori funzionano con entrambi.