问题
I'm developing an ASP.Net MVC & WebApi site that uses table storage in Visual Studio 2015 on Windows 8. It was working fine in the development environment (when I set UseDevelopmentStorage=true in my web.config). I'm trying to hit "http://localhost:80" I have to use this and cannot use another port, have another program I am posting to my site with and it will only post to that location.
I've recently run the site and get the following error when my code gets to the following line of code: CloudTable table = cloudTableClient.GetTableReference(tableName);
Error:
No connection could be made because the target machine actively refused it 127.0.0.1:10002
I've tried the following:
1) Uninstall-Package WindowsAzure.Storage -Version 6.1.0 and reinstalled it from NuGet
2) Restarted Windows
3) Browsed here C:\Program Files\Microsoft SDKs\Azure\.NET SDK\v2.7\bin and ran cspack.ext (I could not see anything else that seems to relate to storage)
It's still not running. Any ideas as to what I could try?
Update:
After getting the error above I opened up the Cloud Explorer window and could see the tables I'd created locally in dev with my code (assume this means my local storage emulator is running) but I still got the error. I then closed the window and opened it again. It spun a bit while expanding the "Storage Accounts (Classic)" but eventually showed the tables I'd created.
What is strange is that the only node in the "Cloud Explorer" window is "Storage Accounts (Classic)", I'm sure there was a list of other nodes before (i.e. WebApps etc). If anyone can help with this please can you post step by step instructions on what to do (not something like "the emulator is not running"). New to this so looking for simple instructions my gran would understand.
Much appreciated.
回答1:
You have to start the storage emulator. It is located in %programfiles(x86)%\Microsoft SDKs\Azure\Storage Emulator\AzureStorageEmulator.exe.
As a bonus, here's a batch script for cleaning up the emulator, as well as starting it.
SET emu="%programfiles(x86)%\Microsoft SDKs\Azure\Storage Emulator\AzureStorageEmulator.exe"
%emu% stop
%emu% clear all
%emu% start
UPDATE
The difference between classic and "new" storage accounts can be found 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: The difference is what API's are being used to manage the storage account. Existing API's and SDK's for downloading/uploading data to containers work with both.
来源：https://stackoverflow.com/questions/33765141/azure-table-storage-no-connection-could-be-made-because-the-target-machine-act