Configuring Azure Services and emulators using Visual Studio
Angelos Petropoulos
Starting with Visual Studio 16.6 Preview 2 the Connected Services tab offers a new experience called Service Dependencies. You can use it to connect your app to Azure services such as Azure SQL, Storage, Key Vault and many others. Wherever possible local emulation options are also available and more are planned for the future.
Add a new Service Dependency
You can easily and quickly get the right NuGet packages, start-up code and configuration added to your project for every supported Azure service. You simply click add, pick the service from the list and follow the 2-3 steps in the wizard. Here is an example of adding Azure Cosmos DB
Provision a new instance of an Azure service without leaving the IDE
In the above example we re-used an existing instance of Azure Cosmos DB, but you can also create new instances of all the supported Azure services without leaving the IDE. Here is Azure Cosmos DB again as an example of provisioning Azure resources from within Visual Studio
Configure service dependencies for remote environments
Using Visual Studio to publish your app to Azure App Service gives you the opportunity to configure these dependencies for the remote environment you are publishing to. Right click > Publish on your project in Solution Explorer and go through the wizard to create a new publish profile for Azure App Service. At the end you will see a Service Dependencies list already containing all of your application’s dependencies ready to be configured for this remote environment
How it works under the covers
To support all of this Visual Studio creates two new files visible in Solution Explorer under Properties called serviceDependencies.json and serviceDependencies.local.json. Both of these files are safe to check in as they do not contain any secrets.
Visual Studio also creates a file called serviceDependencies.local.json.user which is not visible in Solution Explorer by default. This file contains information that could be considered a secret (e.g. resource IDs in Azure) and we do not recommend you check it in.
Service References
While working on the Connected Services tab we took the opportunity to consolidate our UX and make it the new home for the existing OpenAPI & gRPC Service References table. With everything being in one place now we have routed the Right Click > Add > Service Reference… context menu item in Solution Explorer to the consolidated Connected Services tab.
Feedback
Please give all of the above a try and let us know what you think. Do you wish we supported a feature or Azure service that we don’t already? Please let us know! You can submit a new feature suggestion, leave us comments on this post and report any issues you may encounter using the built-in tools.
Light
Dark
5 comments
Hey guys,
looks cool – but to make it a real benefit. I think it should generate TerraForm / Arm Templates for CI/CD proposes. Because I think that a developer shouldn’t configure a production, or uat environment from his local machine these days.
See my comment here:
https://developercommunity.visualstudio.com/idea/1022758/service-dependencies-should-generate-armtemplates.html
This looks like a great feature, but I am curious to know how well it works with teams. If my project is dependant on Azure resources and the serviceDependencies.local.json file is not included in my git push what will the experience of others working on the project be?
Will there be an automatic fixing up of the services and their credentials? – This seems unlikely as they will not have the Resource Ids. Will VS ask for each service to be resolved by taking the user through some sort of wizard to select each resource for the service reference?
Hello Jason and thank you for taking the time to post your thoughts and questions. The short answer is yes! The scenario you are describing is at the top of our minds. We have spent considerable time thinking about it and it has heavily influenced our design. Having said that we’d love to get feedback from users like yourself about what we can do even better! Our philosophy is to put you, the user, in control and stay out of your way until you need us.
If you don’t include the serviceDependencies.local.json file in your git push we will respect your choice. Your teammates will not experience any disruption as Visual Studio will continue to work like it did before and the project will continue to build and run. You and your teammates can continue working this way without any disruption should you choose to do so. If you check in the file later things will simply light up.
Otherwise, if at any point in time you or your teammates want to recreate the serviceDependencies.local.json file you can easily do so by clicking “Configure” against each dependency and following the wizard which let’s you pick the Azure resource you want to use. Just like you guessed towards the end of your post.
Does this answer your questions and do you have any other thoughts? We would love it if you played around with the feature and gave us some more feedback!
I tried this for a Blazor project I’m working on, hoping to get a shortcut into using Azure SQL and KeyVault in the project, but it isn’t working for me. It seems that even when I try in a fresh project, the DefaultAzureCredential is not returning anything so opening the KeyVault fails. All of the steps of connecting to Azure and the database and making a new KeyVault work fine, I just can’t open them after. Happy to provide details if it will assist.
Hello Dan, we definitely want to get to the bottom of your issue. If that’s OK with you, please email me at angelpe@microsoft.com and I will loop in the rest of the team. If you could also include the sample fresh project you talked about that would be ideal. Thank you!