DevMavens Feed

Using Sql Server on Windows ARM

Rick Strahl — Fri, 25 Oct 2024 01:59:54 GMT

I recently picked up a Windows ARM device in the form of a Samsung Galaxy Book 4 with a SnapDragon X Elite chip. Best Buy had a sale going for $799 at the time, and so I 'snapped' one up.

I've been wanting to get my hands on an ARM machine to check how some of my Windows applications run on an ARM device and how well these machines work as mainline Windows machine. While I didn't intend this to be my main machine, from testing and using it as a portable machine away from my big laptop, the verdict is in: Most things work very well without any changes.

Everything works - except SQL Server!

When I picked this machine up and started installing my typical developer and productivity workload on it, I was expecting a lot of stuff to not work or work badly through emulation. I've been pleasantly surprised in that just about everything works - either via many native ARM applications that are now becoming available, or via the built in and 'not bad' x86 emulation. I even was able to run some old legacy Visual Basic and FoxPro applications without any hiccups.

The one let down is that performance is not quite as impressive as advertised. It feels like there's a lot of lag, especially loading applications intially. Performance overall feels at best like a mid-level laptop, certainly not something that would replace a higher end I7/I9 laptop.

.NET Applications - Just Run Natively!

What is quite impressive though is that all of my .NET apps including a several complex Windows Desktop applications ran without even recompiling, running natively under ARM64. Markdown Monster and West Wind WebSurge both run without any changes and I have yet to find any problems. All of my Web apps also 'just run' under ARM64 and I have yet to see any errors or differences. That's impressive - especially for the desktop apps which use a ton of P/Invoke and native code in addition to raw .NET code. And it... just... works!

Full Versions of SQL Server won't install on ARM

But... one thing did not work without quite a headache: Getting SQL Server to run locally on the machine. And yes I want to run locally because I want to take this machine with me to beach where I have no connectivity 😄

SQL Server it turns out, can't install a full version on an ARM device. The installer refuses to go forward past the initial install screens if you try to install Express, Developer, Standard or Enterprise on the ARM device.

Argh!

Docker - no luck for me

I also didn't have much luck with running a local Docker image of SQL Server for Linux. The Docker images Microsoft provides are for AMD64 architecture (ie. x64 based) and Docker would not start those images on this ARM device. Apparently this works on Macs, but not on Windows (go figure).

Microsoft has an Azure SQL Edge image that uses the same version Microsoft is running on Azure which is a subset of the full SQL Server engine. While that version starts, I couldn't get this image to open TCP/IP ports correctly to connect to it - it always failed with various errors related to the -p 1433:1433.

For me this did not work - I didn't get a running instance from this Docker image setup:

docker run --cap-add SYS_PTRACE -e 'ACCEPT_EULA=1' -e 'MSSQL_SA_PASSWORD=superseekrit1' -p 1433:1433 --name azuresqledge -d mcr.microsoft.com/azure-sql-edge

It looks like there are port mapping failures for -p 1433:1433 in the image that causes it to fail. No idea how to debug that, so I gave up. (if you have any ideas leave comment, please)

What works: LocalDb - v16 (or latest version!)

After a lot of digging and some help from an X discussion I managed to get LocalDb to work locally.

@peymen34's suggestions are what got me over the hump by suggesting to ensure the latest version of LocalDb was installed.

Did you try LocalDB 2022? v15.0 is 2019 right?
— Peyman (@peymanr34) October 24, 2024

The process to get here is by no means easy. Microsoft has no no direct documentation of this process, and a lot of information that is in Blogs and SO posts is outdated.

Setting up LocalDb

So here's what you need to do to make LocalDb work on an ARM machine:

Get the latest version of LocalDb
(v16 for Sql2022 requires download, v15 installs with Visual Studio)
Start LocalDb Engine
Figure out your Connection Info
- Connect with Named Pipes
- Connect to an .mdf file

Install latest LocalDb

If you installed Visual Studio, you'll have LocalDb v15 installed which supports SQL Server 2019 or older. If your database file is newer (SQL2022 as I do) then you need to install an updated version of LocalDb from here:

Sql Server Express LocalDb

Yeah, the naming is confusing as it looks like you're installing SQL Server Express. And yes, this is the SQL Server Express installer, but that installer also includes the LocalDb installer and so you go through most of the SQL Express setup - but without actually installing Express.

What you want to do here is:

Download the installer
Start the installer
Choose Custom
Go through all the options as if installing SQL Server Express
On the final Feature Selection Page
- Uncheck all SQL Express Options
- Check only LocalDb Option

This ends up installing only LocalDb which is a relatively small installed compared to SQL Express.

Start LocalDb Engine from Terminal

LocalDb is a manually started executable so you have to run it to start it up and capture the Named Pipe Address to connect to it.

On ARM it looks like TCP/IP connections for SQL are not working and you have to use Named Pipes. You can capture the Named Pipe Address the server uses once the server has been started.

First check to see what instances are available:

# Show instances
SqlLocalDb info

# Display Info including version about specific instance
SqlLocalDb info "MsSqlLocalDb"

Make sure the version is what you want. v15 is SQL2019, v16 is SQL2022 and so on (if you're reading this a few years from now).

If for some reason after installing you don't have an instance with the latest version, you can add a new instance with a specific version number like this:

# Create instance with specific version
SqlLocalDb create "MsSqlLocalDb2022" 16.0.1000.6

# Display info
SqlLocalDb info "MsSqlLocalDb2022"

Delete Instances to Reset LocalDb Version

Since I mucked around with these instances so much, I ended up resetting by deleting all the LocalDb instances including the default instance, and then rebooted. After the reboot a default instance (MsSqlLocalDb) showed up with the last installed version (ie. v16) and so that's what I use now.

Assuming you have the right instance and version you can then start it with:

SqlLocalDb start "MsSqlLocalDb"

Finally you need to capture the Named Pipe Address displayed by the output from running the info command on the instance:

SqlLocalDb info "MsSqlLocalDb"

This time around the Instance Pipe Name will display and you can copy this value to your clipboard.

Here's what all of this looks like when executing in the Terminal:

Ok, the server's running.

Connecting to a Database

To connect to a database you'll need two things:

The Named Pipe Server Connection address
The file path to the .mdf file you want to open.

To test, I recommend you first connect in a Data Tool like Azure Data Studio, SSMS or DataGrip. I'm going to use Azure Data Studio here.

Start by pasting the Named Pipe Connection into the Server text box:

Also make sure you set the encrypt option to optional (encrypt=false on a connection string) since the latest SQL drivers default to true and will fail if the server is not using encryption.

Next, click on Advanced and add the file path in Attach DB Filename:

LocalDb Connection String

If you want to do connect to the database in code you can do that with a connection string that looks like this:


var connStr = @"server=np:\\.\pipe\LOCALDB#270C6261\\tsql\query;" +
@"AttachDbFilename=c:\SqlServerDataFolder\WestwindWebStore.mdf;" +
"integrated security=true;encrypt=false";

var sql = new SqlDataAccess(connStr);
sql.OpenConnection().Dump();
sql.ErrorMessage.Dump();

var custs = sql.QueryList<Customer>("select LastName, Company from customers where entered > @0", DateTime.Now.AddDays(-14));
custs.Count.Dump();

And that works! Yay!

Note: If you manually start the server each time the Named Pipe connection string will change each time, so you will have to adjust your connection string each time.

Summary

If you think this is a lot of effort to get SQL Server to run on a Windows ARM device - you're not alone.

All of this is a pain in the ass to figure, to run and not optimal in any way shape or form. But it does work and you can run a local instance of Sql Server.

It's pretty sad that Microsoft does not provide better ARM support for SQL Server. After all developers are important for adoption of the new architecture, and SQL Server is a widely used part of the Microsoft developer platform, so not having good support out of the box for it seems like a gaping hole in strategy. At minimum some documentation that points at the best recommended solution would be helpful.

It also doesn't help that Visual Studio installs an outdated version of LocalDb that doesn't support the latest version of Sql Server. It would have saved me a lot of wasted time to know that I needed a newer version of LocalDb to connect to a newer database. Heck I didn't even know offhand that you could update LocalDb.

Regardless of complexity and discovery overhead, I'm glad that This solution works, but it's hard to recommend this a simple solution 😂

this post created and published with the Markdown Monster Editor

Posted in .NET SQL Server Windows

Creating APIs Part 8: Validation

Jesse Liberty — Sat, 19 Oct 2024 17:33:11 GMT

Performance is king (well, after accuracy) in APIs. Sending a request to the Database only to discover that the request is invalid is a waste of resources. Thus, we want to validate the request as soon as it hits the … Continue reading →

Reboot!

Jesse Liberty — Mon, 14 Oct 2024 22:10:29 GMT

This site has been quiet for a few months while I finish up my book (.NET APIs with C#). I’m happy to reboot both the blog and Yet Another Podcast, starting soon with an interview of Mads Torgerson (lead designer … Continue reading →

Querying over the current time in RavenDB

Oren Eini — Fri, 11 Oct 2024 16:00:00 GMT

We got a really interesting question from a user, which basically boils down to:

I need to query over a time span, either known (start, end) or (start, $currentDate), and I need to be able to sort on them.

That might sound… vague, I know. A better way to explain this is that I have a list of people, and I need to sort them by their age. That’s trivial to do, since I can sort by the birthday, right? The problem is that we include some historical data, so some people are deceased.

Basically, we want to be able to get the following data, sorted by age ascending:

Name	Birthday	Death
Michael Stonebraker	1943	N/A
Sir Tim Berners-Lee	1955	N/A
Narges Mohammadi	1972	N/A
Sir Terry Prachett	1948	2015
Agatha Christie	1890	1976

This doesn’t look hard, right? I mean, all you need to do is something like:

order by datediff( coalesce(Death, now()), Birthday )

Easy enough, and would work great, if you have a small number of items to sort. What happens if we want to sort over 10M records?

Look at the manner in which we are ordering, that will require us to evaluate each and every record. That means that we’ll have to scan through the entire list and sort it. That can be really expensive. And because we are sorting over a date (which changes), you can’t even get away with a computed field.

RavenDB will refuse to run queries that are only applicable for small amounts of data. This is part of our philosophy, saying that things should Just Work. Of course, in this case, it doesn’t work, so the question is how does this match the philosophy?

The idea is simple. If we cannot make it work in all cases, we will reject it outright. The idea is not to have your system susceptible to hidden traps. By explicitly rejecting it upfront, we make sure that you’ll have a good solution, and not something that will fail as your data size grows.

What is the appropriate behavior here, then? How can we make it work with RavenDB?

The key issue is that we want to be able to figure out what is the value we’ll sort on during the indexing stage. This is important, because otherwise we’ll have to compute it across the entire dataset for each query. We can do that in RavenDB by exposing that value to the index.

We cannot just call DateTime.Today, however. That won’t work when the day rolls over, of course. So instead, we store that value in a document config/current-date, like so:

{ // config/current-date
  "Date": "2024-10-10T00:00:00.0000000"
}

Once this is stored as a document, we can then write the following index:

from p in docs.People
let end = p.Death ?? LoadDocument("config/current-date", "Config").Date
select new
{
  Age = end - p.Birthday 
}

And then query it using:

from index 'People/WithAge'
order by Age desc

That works beautifully, of course, until the next day. What happens then? Well, we’ll need to schedule an update to the config/current-date document, to the correct date.

At that point, because there is an association created between all the documents that loaded the current date, the indexing engine in RavenDB will go and re-index them. The idea is that at any given point in time, we already computed the value, and are able to run really quick queries and sort on it.

When you update the configuration document, it is a signal that we need to re-index the referencing documents. RavenDB is good at knowing how to do that on a streaming basis, so it won’t need to do a huge amount of work all at once.

You’ll also note that we only load the configuration document if we don’t have an end date. So the deceased people’s records will not be affected or require re-indexing.

In short, we are able to benefit from querying over the age, without having to pay the query time costs and are able to defer those costs to background indexing time. The downside is that we need to set up a cron-job to make it happen, but that isn’t that big a task, I think.

You can utilize similar setups for other scenarios, where you need to query over changing values. The benefit in terms of performance here is enormous. And what is more interesting, even if you have a huge amount of data, this approach will just keep on ticking and delivering great results at very low latencies.

Webcam randomly pausing in OBS, Discord, and websites - LSVCam and TikTok Studio

Scott Hanselman — Wed, 09 Oct 2024 23:32:28 GMT

I use my webcam constantly for streaming and I'm pretty familiar with all the internals and how the camera model on Windows works. I also use OBS extensively, so I regularly use the OBS virtual camera and flow everything through Open Broadcasting

New features for RavenDB Cloud

Oren Eini — Mon, 23 Sep 2024 16:00:00 GMT

The Cloud team at RavenDB has been working quite hard recently. The company at large is gearing up for the upcoming 6.2 release, but I can’t ignore the number of goodies that have dropped for RavenDB Cloud Customers.

Large Clusters & Sharding

RavenDB Cloud runs your production cluster with 3 nodes by default. Each one of them operates in a separate availability zone for maximum survivability. The new feature allows you to add additional nodes to your cluster. In the RavenDB Cloud Portal, you can see the “Add node” button and its impact:

Clicking this button allows you to add additional nodes to your cluster. The nodes will be deployed and attached to your cluster within a minute or two. The new nodes will be deployed in the same region (but not necessarily the same availability zone) where your cluster is already deployed.

There are plans in place to add support for deploying nodes in other regions and even in a multi-cloud environment. I would love to hear your feedback on this proposed feature.

You can see the new instances in the RavenDB Studio as well:

The key reason for adding additional nodes to a cluster is when you have very large datasets and you want to shard the data. Here is what this can look like:

In this case, we have sharded the data across 5 nodes, with a replication factor of 2.

Feature selection

There are certain Enterprise features that are only available in the higher-end instances in RavenDB Cloud (typically P30 or higher). We now allow you to selectively enable these features even on lower-tier instances.

This feature allows you to easily pick & choose (on an a-la-carte basis) the specific features you want, without having to upgrade to the more expensive tiers.

Metrics & monitoring

This feature isn’t actually new, but it absolutely deserves your attention. The RavenDB Cloud Portal has a metrics button that you should get familiar with:

Clicking it will provide a wealth of information about your cluster and its behavior. That can be really useful if you want to understand the system’s behavior. Take a peek:

Alerts & Warnings

In addition to just looking at the metrics, the RavenDB Cloud backend will give you some indication about things that you should pay attention to. For example, let’s assume that we had a node failure. You’ll typically not notice that since the RavenDB Cluster & client will work to ensure high availability.

You’ll be able to see that in the metrics, and the RavenDB Cloud Portal will bring it to your attention:

Summary

The major point we strive for in RavenDB and RavenDB Cloud is the notion that the entire experience will be seamless. From deployment and routine management to ensuring that you don’t have to concern yourself with the minutiae of data management, so you can focus on your application.

Being able to develop both the software and its execution environment greatly helps in providing solutions that Just Work. I’m really proud of what we have accomplished and I would love to get your feedback on it.

RavenDB 6.2 release

Oren Eini — Wed, 18 Sep 2024 16:00:00 GMT

It has been almost a year since the release of RavenDB 6.0. The highlights of the 6.0 release were Corax (a new blazing-fast indexing engine) and Sharding (server-side and simple to operate at scale). We made 10 stable releases in the 6.0.x line since then, mostly focused on performance, stability, and minor features.

The new RavenDB 6.2 release is now out and it has a bunch of new features for you to play with and explore. The team has been working on a wide range of new features, from enabling serverless triggers to quality-of-life improvements for operations teams.

RavenDB 6.2 is a Long Term Support (LTS) release

RavenDB 6.2 is a Long Term Support release, replacing the current 5.4 LTS (released in 2022). That means that we’ll support RavenDB 5.4 until Oct 2025, and we strongly encourage all users to upgrade to RavenDB 6.2 at their earliest convenience.

You can get the new RavenDB 6.2 bits on the download page. If you are running in the cloud, you can open a support request and ask to be upgraded to the new release.

Data sovereignty and geo-distribution via Prefixed Sharding

In RavenDB 6.2 we introduced a seemingly simple change to the way RavenDB handles sharding, with profound implications for what you can do with it. Prefixed sharding allows you to define which shards a particular set of documents will go to.

Here is a simple example:

In this case, data for users in the US will reside in shards 0 & 1, while the EU data is limited to shards 2 & 3. The data from Asia is spread over shards 0, 2, & 4. You can then assign those shards to specific nodes in a particular geographic region, and with that, you are done.

RavenDB will ensure that documents will stay only in their assigned location, handling data sovereignty issues for you. In the same manner, you get to geographically split the data so you can have a single world-spanning database while issuing mostly local queries.

You can read more about this feature and its impact in the documentation.

Actors architecture with Akka.NET

New in RavenDB 6.2 is the integration of RavenDB with Akka.NET. The idea is to allow you to easily manage state persistence of distributed actors in RavenDB. You’ll get both the benefit of the actor model via Akka.NET, simplifying parallelism and concurrency, while at the same time freeing yourself from persistence and high availability concerns thanks to RavenDB.

We have an article out discussing how you use RavenDB & Akka.NET, and if you are into that sort of thing, there is also a detailed set of notes covering the actual implementation and the challenges involved.

Azure Functions integration with ETL to Azure Queues

This is the sort of feature with hidden depths. ETL to Azure Queue Storage is fairly simple on the surface, it allows you to push data using RavenDB’s usual ETL mechanisms to Azure Queues. At a glance, this looks like a simple extension of our already existing capabilities with queues (ETL to Kafka or RabbitMQ).

The reason that this is a top-line feature is that it also enables a very interesting scenario. You can now seamlessly integrate Azure Functions into your RavenDB data pipeline using this feature. We have an article out that walks you through setting up Azure Functions to process data from RavenDB.

OpenTelemetry integration

In RavenDB 6.2 we have added support for the OpenTelemetry framework. This allows your operations team to more easily integrate RavenDB into your infrastructure. You can read more about how to set up OpenTelemetry for your RavenDB cluster in the documentation.

OpenTelemetry integration is in addition to Prometheus, Telegraf, and SNMP telemetry solutions that are already in RavenDB. You can pick any of them to monitor and inspect the state of RavenDB.

Studio Omni-Search

We made some nice improvements to RavenDB Studio as well, and probably the most visible of those is the Omni-Search feature. You can now hit Ctrl+K in the Studio and just search across everything:

Commands in the Studio
Documents
Indexes

This feature greatly enhances the discoverability of features in RavenDB as well as makes it a joy for those of us (myself included) who love to keep our hands on the keyboard.

Summary

I’m really happy about this release. It follows a predictable and stable release cadence since the release of 6.0 a year ago. The new release adds a whole bunch of new features and capabilities, and it can be upgraded in place (including cross-version clusters) and deployed to production with no hassles.

Looking forward, we have already started work on the next version of RavenDB, tentatively meant to be 7.0. We have some cool ideas about what will go into that release (check the roadmap), but the key feature is likely to make RavenDB a more intelligent database, one might even say, artificially so.

Read more: RavenDB 6.2 release | Subscribe

Debugging the Linux kernel using awesome psychic powers

Oren Eini — Tue, 17 Sep 2024 16:00:00 GMT

I wanted to test low-level file-system behavior in preparation for a new feature for RavenDB. Specifically, I wanted to look into hole punching - where you can give low-level instructions to the file system to indicate that you’re giving up disk space, but without actually reducing the size of the file.

This can be very helpful in space management. If I have a section in the file that is full of zeroes, I can just tell the file system that, and it can skip storing that range of zeros on the disk entirely. This is an advanced feature for file systems. I haven't actually used that in the past, so I needed to gain some expertise with it.

I wrote the following code for Linux:

int fd = open("test.file", O_CREAT | O_WRONLY, 0644);
lseek(fd, 128 * 1024 * 1024 - 1, SEEK_SET); // 128MB file
write(fd, "", 1);
fallocate(fd, // 32 MB hole from the 16MB..48MB range
    FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE, 
    16 * 1024 * 1024, 32 * 1024 * 1024); 
close(fd);

The code for Windows is here if you want to see it. I tested the feature on both Windows & Linux, and it worked. I could see that while the file size was 128MB, I was able to give back 16MB to the operating system without any issues. I turned the code above into a test and called it a day.

And then the CI build broke. But that wasn’t possible since I tested that. And there had been CI runs that did work on Linux. So I did the obvious thing and started running the code above in a loop.

I found something really annoying. This code worked, sometimes. And sometimes it just didn’t.

In order to get the size, I need to run this code:

struct stat st;
fstat(fd, &st);
printf("Total size: %lld bytes\n",
    (long long)st.st_size);
printf("Actual size on disk: %lld bytes\n", 
    (long long)st.st_blocks * 512);

I’m used to weirdness from file systems at this point, but this is really simple. All the data is 4KB aligned (in fact, all the data is 16MB aligned). There shouldn’t be any weirdness here.

As you can see, I’m already working at the level of Linux syscalls, but I used strace to check if there is something funky going on. Nope, there was a 1:1 mapping between the code and the actual system calls issued.

That means that I have to debug deeper if I want to understand what is going on. This involves debugging the Linux Kernel, which is a Big Task. Take a look at the code in the relevant link. I’m fairly certain that the issue is in those lines. The problem is that this cannot be, since both offset & length are aligned to 4KB.

I got out my crystal ball and thinking hat and meditated on this. If you’ll note, the difference between the expected and actual values is exactly 4KB. It almost looks like the file itself is not aligned on a 4KB boundary, but the holes must be.

Given that I just want to release this space to the operating system and 4KB is really small, I can adjust that as a fudge factor for the test. I would love to understand exactly what is going on, but so far the “file itself is not 4KB aligned, but holes are” is a good working hypothesis (even though my gut tells me it might be wrong).

If you know the actual reason for this, I would love to hear it.

And don't get me started on what happened with sparse files in macOS. There, the OS will randomly decide to mark some parts of your file as holes, making any deterministic testing really hard.

Getting the ASP.NET Core Server Hosting Urls at Startup and in Requests

Rick Strahl — Wed, 04 Sep 2024 13:31:35 GMT

Today I was helping out a customer with their ASP.NET core application that wasn't starting up on a live server, hosted in IIS. Not uncommon in a first install, and when this happens I often resort to starting the app directly using Kestrel first, rather than trying to debug startup problems through the IIS system context and hunting down errors in the unwieldy event log.

To do this I can simply run the .exe file of the project (or dotnet run if the SDK is installed) and 90% of the time it's easy to track down issues this way especially if running in debug mode.

Which Port am I Hosting?

But in this case there was a problem: We couldn't figure out which port the app was running on. 😄 A lot of hilarity (NOT!) ensued trying to guess port numbers - the default port of 5000, the dev port that I typically use 5200/5201 plus a few others. Long story short none of those ports worked.

...because... it turns out the developer had changed the default startup Url in code and so the server started a custom port that neither of us would have guessed - until we looked at the source code.

Wouldn't it be nice if we could display that Url somewhere reliably? As it turns we can do that with some startup code, but it's not what I would call easily discoverable, and there are different ways that work at different times in the ASP.NET lifecycle.

Now, you can override the startup Urls via command line and environment options, but in this case even that didn't work because of the explicit override. But for most scenarios explicitly using --urls "<urlList>" or --https_ports works to override the Url.

Overiding Hosting Urls on Startup

FWIW there are million ways to specify startup Urls, and I'm going to refer you to Andrew Lock's in depth post that shows 8 ways to set the hosting Urls.

Getting the Server Urls at Runtime is not Easy

Looking in the source code solved the problem, but that shouldn't be necessary and really what I want in all of my apps is a reliable way that shows me the actual startup urls that are being used and display them on startup as part of an application banner.

I'm a big fan of writing out some useful startup information that tells me the startup Urls, platform and environment at minimum. Something like this:

Figure 1 - Showing a startup banner that includes the startup hosting Urls

Specifically I want to see those startup Urls and I want to see them consistently regardless of whether I'm running in dev with Launch Profiles or environment variables or whether the Urls were set in code.

Besides providing valuable information on what port to use, it's also nice to have the Urls right there during development, because you can click on them to open the browser from the terminal, which is handy.

Lots of ways, but use the Right Way!

So the task at hand is to get the Hosting Urls as part of the startup code in program.cs so that it can be written out as part of a start up banner as shown in Figure 1.

I have actually written about this topic before (updated now) and in that previous post I mentioned a different approach that works in most cases, but didn't work in this case:

// in program.cs -  DON'T USE THIS  
var urls = builder.WebHost
                  .GetSetting(WebHostDefaults.ServerUrlsKey)?
                  .Replace(";", " "); // make clickable

This code works only with assigned Urls from Launch Profile, explicitly assigned urls from the command line (--urls) or environment variables. It does not work with the default url, or urls that are explicitly assigned in the WebBuilder startup. Because this solution returns the assigned Urls not the actual Urls, the values can be returned before the server starts running but after the Urls have been assigned. But again - this only works if the Urls were explicitly assigned via configuration in some way, so it's not a 100% reliable solution.

To reliably retrieve the actually running Urls rather than the assigned values, you have to make sure the app has started running. Once it's running app.Urls is set with a string collection that you can read and it reflects the actual Urls that have been assigned and are live.

So how do we do that? We have to make sure we access app.Urls after app.Start() has been fired:

Figure 2 - Capturing Hosting Addresses on Startup

This code works in all situations, but it requires that you not use the conventional app.Run() command, but instead use explicit app.Start() and app.WaitForShutdown() to execute your server event loop. The code to retrieve the host Urls must then live somewhere between these two statements. Effectively you have to put the Url retrieval code towards the very end of your startup code after the server has been started.

Here's the code for the complete code for the startup banner in Figure 2:

// at the bottom of program.cs
// app.Run()    // can't use this

// use this instead
app.Start();

Console.ForegroundColor = ConsoleColor.DarkYellow;
Console.WriteLine($@"---------------------------------
West Wind Web Store v{wsApp.Version}
---------------------------------");
Console.ResetColor();

var urlList = app.Urls;
string urls = string.Join(" ", urlList);

Console.Write("    Urls: ");
Console.ForegroundColor = ConsoleColor.DarkCyan;
Console.WriteLine(urls, ConsoleColor.DarkCyan);
Console.ResetColor();

Console.WriteLine($" Runtime: {RuntimeInformation.FrameworkDescription} - {builder.Environment.EnvironmentName}");
Console.WriteLine($"Platform: {RuntimeInformation.OSDescription} ({RuntimeInformation.OSArchitecture})");
Console.WriteLine();

app.WaitForShutdown();

This appears to work for all scenarios and always returned the Urls regardless on how they were set. Yay!

Retrieving Host Urls in a Request

You can also retrieve the host urls inside of a request by requesting a IServerAddressesFeature from an IServer instance and then requesting the feature and the addresses:


public object SystemInfo([FromServices] IServer server)
{
    var addresses = server.Features.Get<IServerAddressesFeature>()?.Addresses;   
    ...
}

which looks like this:

Figure 3 - Returning addresses as part of a request.

You can grab IServer from dependency injection either via method (used here) or ctor injection.

For completeness sake, you can also use this same IServer approach in the Startup code:

app.Start();

var server = app.Services.GetService(typeof(IServer)) as IServer;
var addrs = server.Features.Get<IServerAddressesFeature>()?.Addresses;

...

app.WaitForShutDown();

Like app.Urls this code also works only after app.Start() has fired, and given that app.Urls is simpler and gets you the same result, there's no good reason to use that code. Stick to app.Urls there.

Addendum: ASP.NET Core Debug Information

As @Thomas pointed out in the comments, ASP.NET Core apps print out the hosting ports if Information logging is enabled.

Assuming you are running the Development environment you can see the ports listed at startup:

Figure 4 - Debug log output displays hosting Urls, but requires special config you likely wouldn't use in production.

You can switch environments via the command with:

$env:ASPNETCORE_ENVIRONMENT =  "Development"
dotnet run

Actually, the host port logging is triggered by the logging settings for "Microsoft.Hosting.Lifetime" = "Information" and you can also adjust those directly in the local appsettings.json without making other environment changes:

{
  "Logging": {
    "LogLevel": {
      "Default": "Warning",
      "Microsoft": "Error",
      
      // this!!!
      "Microsoft.Hosting.Lifetime": "Information"      
    }
  }
  ...
}

Both of these work in a pinch if you're hunting for ports, but it's not a consistent solution as you're unlikely to run an application in Development or have Information logging enabled in a production app.

Summary

While it's easy to set hosting Urls with many different ways to specify them, getting them back out at runtime is a little more tricky as there are specific rules that need to be followed. Specifically you can only reliably get the the hosting addresses after the server has been started and you have to use the magically undiscoverable references of Iserver.Features to extract the IServerAddressesFeature to retrieve the addresses at runtime. Well, once you know, you know, and now you know 😄

Resources

this post created and published with the Markdown Monster Editor

Posted in asp.net

Getting the ASP.NET Core Server Hosting Urls at Startup and in Requests

Rick Strahl — Wed, 04 Sep 2024 13:31:35 GMT

To do this I can simply run the .exe file of the project (or dotnet run if the SDK is installed) and 90% of the time it's easy to track down issues this way especially if running in debug mode.

Which Port am I Hosting?

Overiding Hosting Urls on Startup

FWIW there are million ways to specify startup Urls, and I'm going to refer you to Andrew Lock's in depth post that shows 8 ways to set the hosting Urls.

Getting the Server Urls is not Easy

I'm a big fan of writing out some useful startup information that tells me the startup Urls, platform and environment at minimum. Something like this:

Figure 1 - Showing a startup banner that includes the startup hosting Urls

Lots of ways, but use the Right Way!

So the task at hand is to get the Hosting Urls as part of the startup code in program.cs so that it can be written out as part of a start up banner as shown in Figure 1.

I have actually written about this topic before (updated now) and in that previous post I mentioned a different approach that works in most cases but didn't work in this case:

// in program.cs -  Don't use this
var urls = builder.WebHost
                  .GetSetting(WebHostDefaults.ServerUrlsKey)?
                  .Replace(";", " "); // make clickable

This code works, but only with assigned Urls from Launch Profile, explicitly assigned urls from the command line (--urls) or environment variables. It does not work with the default url, or urls that are explicitly assigned in the WebBuilder startup. It does however work before the server is started because it essentially looks at explicitly assigned Urls.

The problem is that there are a few ways that the port gets assigned that bypasses explicit assignment. Specifically if you use the default port or if the port is assigned directly as part of WebBuilder setup.

To reliably retrieve the actually running Urls rather than the assigned values, you have to actually have the app start running.

This code works in all situations, but it does require that you not use app.Run() and instead use app.Start() and app.WaitForShutdown() to execute your server event loop, and the code to retrieve the host Urls must live somewhere between these two statements. So effectively you have to put the Url retrieval code towards the very end of your startup code.

// at the bottom of program.cs

// app.Run()    // can't use this

// use this instead
app.Start();

Console.ForegroundColor = ConsoleColor.DarkYellow;
Console.WriteLine($@"---------------------------------
West Wind Web Store v{wsApp.Version}
---------------------------------");
Console.ResetColor();

var urlList = app.Urls;
string urls = string.Join(" ", urlList);

Console.Write("    Urls: ");
Console.ForegroundColor = ConsoleColor.DarkCyan;
Console.WriteLine(urls, ConsoleColor.DarkCyan);
Console.ResetColor();

Console.WriteLine($" Runtime: {RuntimeInformation.FrameworkDescription} - {builder.Environment.EnvironmentName}");
Console.WriteLine($"Platform: {RuntimeInformation.OSDescription} ({RuntimeInformation.OSArchitecture})");
Console.WriteLine();

app.WaitForShutdown();

This appears to work for all scenarios and always returned the Urls regardless on how they were set. Yay!

Retrieving Host Urls in a Request

You can also retrieve the host urls inside of a request by requesting a IServerAddressesFeature from an IServer instance and then requesting the feature and the addresses:

[Route("adminservice/systeminfo")]
public object SystemInfo([FromServices] IServer server)
{            
    var addresses = server.Features.Get<IServerAddressesFeature>()?.Addresses;          
    return new {
        Version = wsApp.Version,
        HostAddresses = addresses,
        Platform = $"{RuntimeInformation.FrameworkDescription}- {wsApp.EnvironmentName}",
        Os = RuntimeInformation.OSDescription + " (" + RuntimeInformation.OSArchitecture + ")"
    });
}

You can grab IServer from dependency injection either via method (used here) or ctor injection.

For completeness sake, you can also use this same IServer approach in the Startup code:

app.Start();

var server = app.Services.GetService(typeof(IServer)) as IServer;
var addrs = server.Features.Get<IServerAddressesFeature>()?.Addresses;

...

app.WaitForShutDown();

Summary

Resources

this post created and published with the Markdown Monster Editor

Posted in asp.net