Azure desktop memory - the connection could not be completed because the target machine actively refused it 127.0.0.1:10002

Question

I am developing an ASP.Net MVC and WebApi site that uses table storage in Visual Studio 2015 on Windows 8. It worked fine in the development environment (when I set UseDevelopmentStorage=true to my web.config). I am trying to click " http: // localhost: 80 " I have to use this and cannot use a different port, have a different program that I send to my site, and it will only publish in this place.

I recently launched a site and received the following error when my code falls into the following line of code: Table CloudTable = cloudTableClient.GetTableReference (table name);

Error:

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

I tried the following:

1) Uninstall-Package WindowsAzure.Storage -Version 6.1.0 and reinstall it from NuGet

2) Reboot Windows

3) Viewed here C:\Program Files\Microsoft SDKs\Azure\.NET SDK\v2.7\bin and ran cspack.ext (I could not see anything else that apparently relates to the repository)

It still does not work. Any ideas on what I could try?

Update:

After receiving the error above, I opened the Cloud Explorer window and saw the tables that I created locally in dev with my code (suppose this means that my local storage emulator is running), but I still got the error. Then I closed the window and opened it again. It turned around a little while expanding the "Storage Accounts (Classic)", but ended up showing the tables that I created.

It is strange that the only node in the "Cloud Explorer" window is "Storage Accounts (Classic)", I'm sure there used to be a list of other nodes (i.e. WebApps, etc.). If someone can help with this, you can send step-by-step instructions on what to do (not something like "emulator is not working"). New to this, so you are looking for simple instructions that my hornbeam will understand.

Great importance.

Answer 1

You need to run the storage emulator. It is located in %programfiles(x86)%\Microsoft SDKs\Azure\Storage Emulator\AzureStorageEmulator.exe .

As a bonus, here is a script package for cleaning the emulator, as well as its launch.

 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" accounts can be found here .

Classic vault accounts are created using existing API service management (the REST API stack, available for the last few years). New storage accounts are created using the new Azure Resource Manager (ARM) API (which is also wrapped in PowerShell and CLI). In the end, they provide the same resources to your applications, but they are created / managed differently, and there are several nuances of difference (for example, the ability to tag resources created through ARM).

You cannot convert a classic vault account (or any classic resource) to a newer type. You still don't need to if you are not trying to mix resources from classic and new, such as adding ARM-based virtual machines to a classic virtual network or an ARM-based VM from a VHD image sitting in a classic storage account (and for this example you can always just copy vhd to a new warehouse account). Note that for general storage use (blobs / tables / queues), you just need a URI and a primary (or secondary). With their help, you can access your resources anywhere, from any VM / website / etc., regardless of, for example, storage from classic or new virtual machines.

TL DR: The difference is that the API is used to manage the storage account. Existing APIs and SDKs for loading / unloading data into containers work with both.