>> [MUSIC].
>> Hi everyone. My name is Angelos and I'm a PM for.Net.
Today we're going to look at how Visual Studio helps
me integrate my application with Azure services.
We're going to look at how to get our Kobe's configured correctly.
We're going to look at how to emulate Azure services locally,
during local debugging,
we're going to look at how to publish our application to Azure.
Finally how to deal with the situation
of maybe I want to connect my application
to different instances of services for
different environments. Let's jump right in.
Here I am in the connected services tab,
and I can get back here by just double-clicking on
the Connected Services note in Solution Explorer at anytime.
This tab is split into two parts.
The bottom part is called Service References,
and that helps me connect my application to OpenAPI,
gRPC and WCF endpoints.
We're not going to spend time on that today.
We are going to focus on the top part,
which is service dependencies.
That helps me connect to Azure services and SQL Server.
Right now, my application is not connected to
anything and it says so right here,
and I'm going to click "Azure Service Dependency" to get started.
Let's take a look at some of my options here.
The first two items from the list
are referring to Application Insights.
The first option is a local only option that is only
available during F5 when I'm debugging my application.
The second option is letting me connect to
an actual live instance of Application Insights.
Now the reason why on this screen,
I'm getting some local options is that
because when I'm configuring things to connected services.
I'm configuring how my application is going to behave during F5.
Though, some of these options are not going to make
a lot of sense doing published,
but they are not going to be there.
Following on, on the list and
next few options are about Azure Storage.
The first two are two local on the emulator options.
One of them is going to run the Azurite emulator,
as it's called in a container,
the other one is going to run the Azurite emulator
just straight up on the machine.
Finally, the third option is to not let you
connect to Azure Storage, real life instance.
Then moving down the list,
we have Azure Signal R Service,
which is again connected to a real life service in Azure,
we have a local option for dealing with applications secrets.
You can use the secrets translation file,
which is the default way of keeping
application secrets outside of your source repo.
Then we have the ability to use Azure Key Vault and
actually Visual Studio is smart enough to
let you use Secrets Rotation locally,
and when the time comes to publish,
to switch that out for using key vault,
we'll see how to do that later.
Then we have the ability to connect to Azure app configuration,
which is just another way of centralizing
all your application configuration and
even integrate with keyboard. That's pretty cool.
Then we have three options for SQL Server.
SQL Server Express LocalDB,
that's a local only option,
it's very popular for doing local development with SQL Server.
Then we have Azure SQL database,
which is connected to a live instance of Azure,
Azure SQL database online.
We also have the ability to connect
your application to SQL Server database on-prem,
maybe you have an instance on your local machine on the network.
Then we have two options for Redit cache.
One is a local emulation option again.
It's going to run in a container.
The other one is going to connect to a live instance of Azure.
Finally we have Azure, CosmosDB,
and much of identity platform that lets
you achieve authentication through Azure Active Directory.
I'm going to keep things simple here.
I'm going to configure
my application to connect to SQL Server Express LocalDB.
I click "Next" and I get to give a name to my connection string.
I'm going to say my connection to SQL.
Here Visual Studio is helping me manage
that application secret the connection string value.
Ideally, I don't want it in my code base.
I can either by default would've been the user secrets file,
or it can even integrate with Key Vault.
This is basically the equivalent of me adding
independency to Key Vault and then putting the value in there.
I just don't have to do that manually, VS can do that for me.
I'm going to keep things simple and use
my local user secrets file locally.
Now we get a little summary page that is going to
tell me what is VS doing on my behalf.
It's telling me it's going to get the right
makeup packet is spin up,
put the value in the right Secret Store.
Because it's SQL Server,
it doesn't need to be paid a code-based anyway so that's nice.
I can just click "Finish".
It will give me a little summary of everything that it did.
Now it's telling me that my application is configured
correctly to talk to SQL Server LocalDB.
Let's do that one more time, and now
let's add a connection to storage.
Now I could connect to live Azure Storage instance,
but locally I want to emulate things
so I'm going to pick the storage Azure emulator.
I'm going to click "Next" I'm going to give
my connection string and much low my connected to storage.
Same options with the application secret, I click "Next".
In the summary page it's telling me
that it's going to do the same things as before.
This now an extra step to also prepare
my codebase to be ready to consume The Azure Service.
Didn't need a physical server, but I do need it for storage.
It's really nice that Visual Studio
will just take care of all of that for me.
Just click "Finish" here,
get my little summary of exactly what's going on.
Now my application is configured with
very few clicks to consume Azure Storage and SQL Server,
and I'm ready to write my business logic.
Now at this point, I can go to "Publish".
I can create a new Published Profile.
Pick Azure and offset this Linux as my deployment target.
Here, Visual Studio is letting me
manage all of my Azure resources without leaving the ID.
If I have multiple accounts that I'm logging with,
I can switch over to the different accounts.
If I'm logged in with multiple subscriptions,
I can change the subscription.
I can search for instances that already exist and pick them.
I can group things by resource group,
which is very helpful for people
who are going to keep everything in
the same resource group when it
comes to a flat list by resource name.
Of course, I can always
provision new resources without leaving the ID.
Now I don't want to do that in this case,
I already have an instance created,
so I'm just going to pick it from the list and click "Finish".
Visual Studio now has
a published profile that is ready for me to use immediately.
If I want to, I can just click
"Publish" and visuals are just going to be the right thing.
It's going to build the app
and publish it to App Service successfully.
That's why the status is ready to publish.
But I've already told Visual Studio,
that I am connected to SQL Server and storage.
It's smart enough to know that locally,
I'm connected to basically emulation options,
the storage emulator and the SQL Server LocalDB.
It knows that's not going to work,
that's not going to be successful when
I'm deploying an application to Azure.
Because even though publishes successful and the application
will be there when it starts to run
and tries to access the resources,
it's not going to be able to, so at
the bottom of the page here we have our service dependencies list.
Again, the same list as we've had
before in Connected Services tab,
we now have it in this Published Profile.
VS is telling me that this is
good to go as soon as I configure it.
I just need to hook it up to
an instance that is available in that environment.
I just click "Configure".
It knows that Azure SQL database
is probably what I want to do so it
has filtered the list and just slap on
pre-selected for me, I can click "Next".
Now I'm immediately in select an existing instance to connect to.
It's the most common scenario.
That's why we default into it.
But like I said, you can always provision
new Azure instances without leaving the ID.
Here I'm just going to pick an instance
that I already have and connected to it.
I'm going to keep my connection string the same.
I'm just going to provide the username and
password that I know I can use to connect to this instance.
When I click "Next",
it's going to give me a summary of what it's
about to do and I'm going to click "Finish".
It's giving me a running summary of what it's doing right now.
Now this connection has been configured correctly.
All I have to do, is go to
the next one and do the same thing for storage.
Again, I can provision the new instance,
but I don't have to, I can just pick an existing one right now.
I'm going keep the same connection string name.
Of course, the appropriate connections
in value is automatically figured out by VS.
I don't even have to worry about it.
I can just click "Next". Little something that's going to happen?
Click "Finish". Now my application
is all set up and correctly configured around this environment.
Now when I do publish,
application is going to end up in App Service successfully.
Once you start running, is going to access
the appropriate connection strings with the configuration.
My application will be able to run successfully.
Well, that was fun. I hope you guys had
fun with me as well and learn something new.
We're constantly adding more support for more integrations.
We are adding support for more Azure services
and we're dying to hear your feedback.
Let us know what you think, Tweet at us.
Let us know through developer community.
Just know that we're always listening.
Thank you very much. Take care.