Tag: Azure Storage

Azure FunctionsVisual Studio

Azurite emulator cannot be started

on January 24, 2022

After installing Visual Studio 2022 and working with Azure Functions I noticed that a new storage emulator is being used called Azurite.

Azurite is an open source Azure Storage API compatible server (emulator). Based on Node.js, Azurite provides cross platform experiences for customers wanting to try Azure Storage easily in a local environment. Azurite simulates most of the commands supported by Azure Storage with minimal dependencies.

https://github.com/Azure/Azurite

This seemed to replace the old Azure Storage Emulator you would run previously when doing local development. I quickly came across an issue where the Azurite emulator cannot be started because port 10000 is already in use. This is also applied to ports 10001 and 10002 which it uses. Here are the contents of the Service Dependencies from the Visual Studio 2022 Output pane:

Ensuring Azure Functions Core Tools are up to date. This may take a few minutes...
Azure Functions Core Tools are up to date.
DotNetCore31-FunctionApp: Azurite emulator cannot be started because port 10000 is already in use. Another instance of the Azurite emulator or Azure Storage emulator might be already running on your machine.
DotNetCore31-FunctionApp: We detected that Azure Storage emulator is running on your machine. The Azure Storage emulator is now deprecated. Microsoft recommends that you use the Azurite emulator for local development with Azure Storage. Follow the directions in the link 'https://go.microsoft.com/fwlink/?LinkID=2167087' to install and run Azurite emulator.
Unable to start dependency 'functions.storage1'.
Ensuring Azure Functions Core Tools are up to date. This may take a few minutes...
Azure Functions Core Tools are up to date.
Ensuring Azure Functions Core Tools are up to date. This may take a few minutes...
Azure Functions Core Tools are up to date.
DotNetCore31-FunctionApp: Azurite emulator cannot be started because port 10000 is already in use. Another instance of the Azurite emulator or Azure Storage emulator might be already running on your machine.
DotNetCore31-FunctionApp: We detected that Azure Storage emulator is running on your machine. The Azure Storage emulator is now deprecated. Microsoft recommends that you use the Azurite emulator for local development with Azure Storage. Follow the directions in the link 'https://go.microsoft.com/fwlink/?LinkID=2167087' to install and run Azurite emulator.
Unable to start dependency 'storage1'.
DotNetCore31-FunctionApp: Azurite emulator cannot be started because port 10000 is already in use. Another instance of the Azurite emulator or Azure Storage emulator might be already running on your machine.
DotNetCore31-FunctionApp: We detected that Azure Storage emulator is running on your machine. The Azure Storage emulator is now deprecated. Microsoft recommends that you use the Azurite emulator for local development with Azure Storage. Follow the directions in the link 'https://go.microsoft.com/fwlink/?LinkID=2167087' to install and run Azurite emulator.
Unable to start dependency 'storage1'.

Let’s drop into Windows Terminal and take a look at what process is using that port:

Get-Process -Id (Get-NetTCPConnection -LocalPort 10002).OwningProcess

After stopping the Node process and re-running Azurite (I restarted Visual Studio) we can see everything starts up as expected:

Ensuring Azure Functions Core Tools are up to date. This may take a few minutes...
Azure Functions Core Tools are up to date.
DotNetCore31-FunctionApp: azurite.cmd --location "C:\Users\ccampbell\AppData\Local\Temp\Azurite" --debug "C:\Users\ccampbell\AppData\Local\Temp\Azurite\debug.log"
DotNetCore31-FunctionApp: Azurite Blob service is starting at http://127.0.0.1:10000
DotNetCore31-FunctionApp: Azurite Blob service is successfully listening at http://127.0.0.1:10000
DotNetCore31-FunctionApp: Azurite Queue service is starting at http://127.0.0.1:10001
DotNetCore31-FunctionApp: Azurite Queue service is successfully listening at http://127.0.0.1:10001
DotNetCore31-FunctionApp: Azurite Table service is starting at http://127.0.0.1:10002
DotNetCore31-FunctionApp: Azurite Table service is successfully listening at http://127.0.0.1:10002

This was not a great experience on the first day I started to use Visual Studio 2022 with Azure Functions as I had to go off and figure out why the Azure emulator could not be started instead of just working on my application. You can go and change the default ports ft you like which is mentioned in the documentation. For more information on Azurite check out the docs on their GitHub repository.

I hope this helps with anyone new to the Azurite emulator in Visual Studio 2022.

Enjoy!

References

https://docs.microsoft.com/en-us/azure/storage/common/storage-use-azurite?tabs=visual-studio

https://github.com/Azure/Azurite

AzureCloudCloud NativeDeveloper

AzUrlShortener: An open source, budget-friendly URL shortener | Azure Friday

on May 15, 2020

In this episode of Azure Friday, Frank Boucher joins Scott Hanselman to talk about AzUrlShortener – an open source, budget-friendly URL shortener you can deploy directly from GitHub with one click into your Azure subscription. Frank explains how to get it, why it’s inexpensive, and explores the source code.

[0:01:34] – Demo

Source: Channel 9

Resources

Azure

Azure Storage Explorer Reaches 1.0

on April 18, 2018

image

Microsoft Azure Storage Explorer is a cross platform client tool built on Electron that allows you to easily work with Azure Storage data on Windows, macOS and Linux. This tool also provides preview support for Azure Cosmos DB and Azure Data Lake Store.

I find this is a great tool to use when working with Azure Functions locally and you want to work with Azure Storage Accounts, both locally or in Azure.

Microsoft Azure Storage Explorer was updated on April 16 2018 to version 1.0 and is a big update with log of new features, bug fixes, and some breaking changes, so be sure to checkout the release notes on what is new and fixed.

image

Breaking Changes

It’s worth pointing out the following breaking changes:

  • Storage Explorer has switched to a new authentication library. As part of the switch to the library, you will need to re-login to your accounts and re-set your filtered subscriptions
  • The method used to encrypt sensitive data has changed. This may result in some of your Quick Access items needing to be re-added and/or some of you attached resources needing to be reattached.

Download Details

Enjoy!

References

Azure Storage Explorer release notes

Feedback can be submitted to the Azure Storage Explorer issues page on GitHub

Azure

Introduction to Azure File Sync

on September 27, 2017

azure-file-sync

Azure File Sync is meant to provide customers a secure and centralized file share management in the cloud. Once installed you will be able to store less frequently accessed files on the cloud and then keep more frequently accessed files on your local file shares, all while delivering a consistent file share performance with no configuration or code changes required. Azure File Sync could also lower IT support requirements for remote or branch locations.

Azure File Sync was released as a preview on September 25, 2017. Currently the public preview availability is limited to the US regions and works with Windows Server.

For more details on Azure File Sync checkout the announcement blog post and the following is a quick overview video…

image 

Enjoy!

References

Announcing the public preview for Azure File Sync

Azure File Sync Overview

Azure Storage

Docs – Introduction to Azure Files

DevelopmentDevOps

Visual Studio Team Services Build to the Rescue

on June 28, 2017

So this week Visual Studio Team Services build and release saved me and my team.

At our company we have configured an on premise continuous integration server along with build agents using TeamCity which is a product from JetBrains. TeamCity Professional is actually a free application that allows you to run 3 build agents. The only cost is the associated hardware and Windows licensing. I fell in love with TeamCity years ago when I set it up at our company and it’s been a very stable and a versatile CI server since. However this week I ran into some issues with our TeamCity server and the fact that it was on premise only added to the problem. Let me explain.

Our build server physical infrastructure is actually located offsite from our office (along with other dev/qa servers), so when I say on premise I really means its dedicated hardware that we own and not up in the cloud. The situation we ran into is that our TeamCity server didn’t restart properly and was unavailable by remote access by the ITOPS team, this meant someone had to go to the offsite location and reboot the server. Now you might be wondering, why don’t you have a backup…a good question and something I’ll be looking into.

What made matters worse is that we we’re nearing the end of a regression cycle and we wanted to deploy later this week. So having our build server drop off the grid was just bad timing and it meant DEV and QA were in a holding pattern while we waited for our build server to be brought back up and hopefully it was ok and not corrupted or worse.

While we waited for our build server to be restarted I started thinking about worse case scenarios like what if our build server is dead and we need to rebuild or restore from a backup (and what do you know it was out of date). None of these options can be done quickly and they require unplanned resources from the ITOPS team and myself.

Having already explored Visual Studio Team Services (VSTS) build and release services for my personal development and that of our Live .NET logging tool ReflectInsight, I knew I could easily and quickly get one of our applications setup in that continuous integration pipeline. You will actually be shocked at how quickly I got things going.

Our current build process typically builds the solution, runs unit tests, creates a nuget package and then finally publishes the nuget package to an internal nuget repository that is part of TeamCity. We then have an automated deployment service called Octopus Deploy that picks up this package and can then deploy to any of our QA and/or production systems. Since our TeamCity server is offline, I would need to publish the nuget package to another destination for the time being. I decided to create an Azure Storage account and then copy the nuget package there. I could then pull the nuget package down and manually upload to our Octopus Deploy server.

To get started I headed over to my Visual Studio Team Services account I had setup with my MSDN subscription and I then created a new project to contain my builds. I then clicked on the Build & Release tab and then clicked on the New button to create a new build definition:

image

I then clicked on the ASP.NET (PREVIEW) featured template:

image

I then configured the Get sources task to point to our GitHub repository and then I added in the last two steps for generating a NuGet package and to copy the generated NuGet package to an Azure Storage account:

image

I wont go into detail for each of these build tasks as their pretty straight forward, but after I had everything setup and tested, I looked at the clock and it was under 15 min from start to finish. That is something I could never have done in our existing on premise build infrastructure and it now looks like I have my backup solution.

One of the nice things about using the hosted agent in VSTS is that it’s located in Azure and its a service that is managed by the Azure team. This means I spend more time focusing on developing my applications and less time worrying about managing the associated build infrastructure and what happens if a server goes down, performing backups, restores and that all hands on deck feeling when your infrastructure goes down at the worse possible time.

Enjoy!

References

TeamCity

Visual Studio Team Services

Azure Storage Explorer

Octopus Deploy