Azure Table Storage – No connection could be made because the target machine actively refused it 127.0.0.1:10002

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 FilesMicrosoft SDKsAzure.NET SDKv2.7bin 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.

Answers:

Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.

Method 1

You have to start the storage emulator. It is located in %programfiles(x86)%Microsoft SDKsAzureStorage EmulatorAzureStorageEmulator.exe.

As a bonus, here’s a batch script for cleaning up the emulator, as well as starting it.

SET emu="%programfiles(x86)%Microsoft SDKsAzureStorage EmulatorAzureStorageEmulator.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.

Method 2

I ran into this exact error when I am debugging my Durable function. The accepted answer helped me. Just want to point out that I was not able to start the emulator by clicking on the file. Instead, I started it by (from the link posted another user above)

  • Select the Start button or press the Windows key.
  • Begin typing Azure Storage Emulator.
  • Select the emulator from the list of displayed applications.

After the emulator is started, the error goes away and I was able to start my durable function.

Method 3

I believe the simplest solution here is to install the official Azurite extension for VS/VSCode. Then you can run the storage emulator using Azurite: Start Table Service (VSCode) or the relevant command from your Windows shell (VS). See here for details.


All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0

0 0 votes
Article Rating
Subscribe
Notify of
guest

0 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
0
Would love your thoughts, please comment.x
()
x