Connect your application to Azure using Visual Studio 2022

>> [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.