This is a new test post - checking whether this is a realistic way to post

@Richard - Thanks for the extra info. I've updated the post with additional information!

Dark Mode - glad you like it. Site's finally been updated to .NET Core from WebForms (eek!) and while at it added theme support and cleaned up some of the rendering while mostly keeping the layout the same.

Hopefully not going to run into too many broken edges. So far so good.

You can avoid having to worry about the X-Forwarded-For header by using the forwarded headers middleware:

Configure ASP.NET Core to work with proxy servers and load balancers | Microsoft Learn

That reads the X-Forwarded-For, X-Forwarded-Proto, X-Forwarded-Host, and X-Forwarded-Prefix headers; validates that the headers come from a trusted source; and updates the relevant properties on the connection and request.

(Loving the new dark mode BTW!)

Thanks @Jon - Fixed. The Weblog site's gone through a major port and I'm still dealing with a few rough edges. Totally missed the bad Urls - was wondering why new posts weren't getting hit from the feed. This explains it 😄

Hi Rick,

The links in your RSS feed are malformed:

https://weblog.west-wind.com/https://weblog.west-wind.com/posts/2026/May/13/Getting-the-Client-IP-Address-in-ASPNET-Core

Otherwise, love your content!

With .NET AOT, you can even write ActiveX controls compatible with 30+ years old dev tools, like Fox Pro you mention 😃 https://github.com/smourier/ActiveN

Timestamping failures have been a long term issue. I work around this by separating signing and timestamping operations, and use a list of timestamp servers and retry with a different server if timestamping fails. I occasionally change or re-order the list when one ts server becomes unreliable.

Thanks a ton friend. The BitmapImage solution worked like a charm. Seems like the kinda thing they should have as part of the Image control, huh?...

Signing is considerably faster than what I saw with my old SignTool based workflow, with signing times under two seconds for most files (this is one is quite large). Based on this speed, it looks like sign uses locally created hashes rather than uploading the entire file to the server for processing.

I can confirm, we don't upload files and calculate hashes of the files for signing.

@JR - I'm not trying for full Handlebars compatibility - the goal is to allow full C# language access, using the raw C# language. If there are special script tags, then you're into that weird pseudo code area which I'm trying to explicitly avoid because it's limited to what you implement.If you want that kind of compatibility you can use DotLiquid or Fluid which are more true to Handlebars syntax.

Very nice and useful. Thanks!

If I may, I really don't like the Handlebars-like syntax though, as I find it really confusing, particularly within a mix of HTML and C# code. As an example, this looks horrible to me:

{{% if (...) { }} ... {{% } }}

As a possible alternative syntax, consider a more HTML-friendly syntax, such as PHP: https://www.php.net/manual/en/language.basic-syntax.phptags.php
The previous code would be much more readable:

<? if (...) { ?> ... <? } ?>

That's just a suggestion 😉

@Stephen,

Have you done any work with getting C# language support working when embedded in another language?

No, and honestly not sure I understand what that means. I mean, Razor is that and in a more limited way so is the Handlebars markup, no? Ultimately it just depends on whether you can separate the literals, and languages into their respective sections and execute each according to what they do.

Re: #line No I wasn't aware of that. I have to take a look and see what that does. If it does what I think it does, not sure that I can match code line numbers exactly because the parser doesn't know what line it's on while creating the code (at least not in the current implementation that parses code block by code block).

Great article - fun read!

I'm working on something vaguely similar (using C# snippets in another language, but not as a template). Have you done any work with getting C# language support working when embedded in another language? Syntax highlighting and code completion in particular. I'm curious to know how hard that would be.

in there I adjust the line numbers so they match up with the user provided code. It ain't exactly Visual Studios Error Pane but it's pretty good for a generic template solution to pinpoint the line of generated code where the error occurred that you can translate into whatever line that matches in your script.

Have you tried the #line preprocessor directive?

For better performance, use the --max-concurrency option and a lot of files in single sign code artifact-signing call.

Default is 4, try to set 10 or more.

@Josip - if you're referring to the banner on the top of the page, that is a generated image - it's not real.

Not related to this subject but I noticed the Windows Theme you are using. It reminds me of OS/2.

Would you share which one is it?

I paid the $9.99 and am unable to get pass au10tix validation - when it gets to the point of scanning the QR code to get to the phone, the phone shows me "Error in backend service." Au10tix says it is not their problem and Microsoft (at least the last 24+ hours) has been completely non responsive. Help!

Finally tried dotnet sign again (it didn't work work for me with trusted-signing originally), and now using artifact-signing option, client side signing can be accomplished a lot easier than what's described in this post using SignTool.

Here's another post with how to use dotnet sign:

Azure Trusted Signing Revisited with Dotnet Sign

@Ralph - I'm using SignTool with multiple files in a single call. But there are two calls - one to sign the included binaries and one to sign the final setup binary. The way it looks though - SignTool is sending each request separately. Rate limiting on a timestamp server would be beyond dumb if that's the case at least for the amount of requests that are being made.

Heh, it seems to be on par with how Microsoft is today.

We are using Azure Key Vault signing with the dotnet sign tool and for us I can say the MS acs endpoint is reliable to ship a few releases every day.

Do you sign every single file in a separate call? (rate limiting?)

Our single CLI command:

$filesToSign = "my-dlls*.dll";
dotnet sign code azure-key-vault $filesToSign 
        --azure-key-vault-url "$env:AzureKeyVaultUrl" 
        --azure-key-vault-certificate "$env:AzureKeyVaultCertificate" 
        --recurse-containers=false 
        --base-directory "$env:CI_PROJECT_DIR\bin\";

Wow, after trying 3 times I finally found the solution.

"And what does hot reload to do with any of this?"

Unfortunately I can't use XAML because it breaks theoretical rules to do with my app design. I'm hot compiling fluent interfaces (and testing various GUI frameworks like Avalonia and Prowl https://github.com/ProwlEngine/Prowl). I needed a general hot compiler that isn't XAML specific, since it will be a mix of heavy WPF/Avalonia UIs for boostrapping the v1 UI, which I'll then rewrite in itself with low level immediate mode rendering. End result will be something equal to or better than ⇒ https://youtu.be/PUv66718DII?t=239

For that type of creative coding, I need Bret-victor style tight compile loops. Basically what JS has out of the box. Either way your post helped a ton 🚀

@ChrisC - Yeah, Mono had a wrapper around their compiler - as is this code - to make it easier but that doesn't negate the same issue that compilers have options and parse trees and and and... underneath it all.

If you want to build a library or tools, you want to go as close to the metal as you can. And FWIW, the Roslyn APIs are pretty straight forward to use - what sucks is that the documentation is horrible and there are a number of different ways to do the same thing with no explanation what each is intended for or works best with.

This post is long and complex because it shows a bunch of different ways to leverage the underlying compiler features into something you can actually use in your application directly for common scripting style tasks.

And what does hot reload to do with any of this? And... WPF has had hot reload for years. I use it everyday - out of box.

So I managed to adapt your excellent scripting code to do Roslyn hot reload in WPF .NET 10. Thanks for all your work! I can edit hot.cs and have the changes instantly appear in the UI with full working intellisense in Rider (because it's not a CSX). Crude POC but happy it works. Cheers! https://github.com/xstos/apps/tree/master/playground/csharp/HotReload2/HotReload2

Incredible how much work it is to do what (now deprecated) mono did in a few lines of code. Can't really understand what Microsoft is smoking.

I managed to get WPF hot reload in about an hour's work yesterday so I can tighten the absurdly long compile loop when working on my visual programming language prototypes. https://github.com/xstos/apps/tree/master/playground/csharp/HotReload/HotReload

Ridiculous this isn't out of the box functionality.

Incredible how much work it is to do what (now deprecated) mono did in a few lines of code. Can't really understand what Microsoft is smoking.

I managed to get WPF hot reload in about an hour's work yesterday so I can tighten the absurdly long compile loop when working on my visual programming language prototypes. https://github.com/xstos/apps/tree/master/playground/csharp/HotReload/HotReload

Ridiculous this isn't out of the box functionality.

@Rick Well it seems the VS2022 Publish wizard that generated the msixbundle signs the .msixbundle file, and the .msix file inside the bundle, but the .exe (our program) seems to be note signed.

I'm using the Trusted signing with the signtool and when pointed to the msixbundle also signs the msix inside the bundle, adds a publickey file and then signs the msixbundle file itself, but also does not sign our executables.

The cert doesn't check anything. You sign your executable with your valid cert and the cert gets embedded into the EXE along with a hash and checksum. Once you've signed, the EXE (or other installer file) can't be changed without breaking the checksum.

The certificate's only real job is to certify that this file was built by the signer, and not modified after it was built.

That's basically all the cert provides. The cert itself contains identifying information and presumably SmartScreen uses that to create a score of your application over installed applications. But that's Microsoft's SmartScreen APIs that do that and not something you directly affect.

Specifically, according to ChatGpt:

It tracks primarily by publisher identity + signing chain, and for SmartScreen also file reputation (hash prevalence).

So frequent certificate rotation does not reset you to zero each time — assuming the publisher identity stays consistent.

Your application can also check the certificate. For example, in Markdown Monster I check the certificate on startup to ensure that the EXE is signed with my certificate. If it's not the file's been hacked. This won't stop a sophisticated Cracker (they'll just bypass the check code), but it provides some basic protection identification.

@Rick Do you actually now how a signing cert checks the validaity. And especially that a new installer is in fact an update of an existing installed program. With Trusted signing the thumbprint and serial are new eacht time they generate a new cert. Only the Subject line stays the same. So How would Windows check to see whether this new installer is in fact a legitimate update to an already installed program?

It's been 3 years since I bought the Sectigo signing cert, but to my recollection I supplied the public key and some company info in text fields. I think they phoned me on a phone number they could find based on the company name (on our public website) But even that, the phone number was also in my Sectigo account. So how hard would it be to find a less than honourable provider that does not check and just gives me a signing cert that says I'm Microsoft. Or are there strict guidelines these providers have to adhere to to be able to become a signings cert supplier?

At least it feels not that much of a security mechanism. But maybe this show how little I know about this 😮

P.S. I also noticed that notepad.exe is not signed directly but uses an "Catalogue Signatures" whatever that is.

I have the sharing tab. However, for all non-shared drives, the [Share] button on that tab is inoperable (greyed out). I had previously shared my D: and M: drives. When I look at their properties, it says they are shared and gives their network path. The [Share] button is greyed out. And I cannot see the devices on the network, much less get access. No settings were changed (by me). I've checked that they are still as told to be in this and various other sites. Any suggestions? -ceej

Rick, thanks for keeping to reply in this thread. I'm stuck with AppInstaller for the moment but sometimes regret this step due to some strange behaviours and it breaking in places Microsoft decides.

I'm testing with an app I signed and installed, and after three days will create a new installer to update the existing app and see whether that works. If not I think I will spend the 1000 USD for a 3 year USB Signing cert and hope things improvce during tha ttime. But in any case if that does not work We will have to tell around 200 dekstopt to uninstall the old and install the new version after switching the cert (if it is not compatible with updates like I fear) 😮 😦

Again thanks for answering my questions. Some of these topic are fringe and there is not a lot to find, as I have also see nwith info about AppInstaller and wapproj, they feel niche 'products'

Inno can sign optionally but I sign myself after the EXE was built. Same thing really, just different mechanism. And I don't think Inno will work with Trusted Signing unless you export certs to a local cert first which is a major hassle and not recommended. I do it manually because I'm already signing all my other files that way.

I've not seen any issues with SmartScreen worse than they normally are with non high end, non-EV certs. If anything I would think that signing with Trusted Signing and a Microsoft certificate will help with SmartScreen as Microsoft can verify directly. From what I understand the online generated certs include some marker that identify the signer and product with a unique id, so it's not treated as a brand new certificate each time so continuity might be better than with a 1 year or 3 year renewed certificate actually.

Trusted signing is meant to be used using the online mechanism. If you export it's just not worth the hassle and I would not recommend that. Using online signing for me is fine other than that it's slow - it takes between 3-10 seconds to sign each file and I sign 8 files total (i'd say it takes about 1 minute for all the signing where local signing took a few seconds), but the process is automated so it doesn't matter that much.

Rick: But Inno will also sign the installer that it generates, otherwise you still get the Smartscreen misery. Or do you sign the Inno generated AppSetup.exe as well?

Anyway, my fear is that the msix-bundle files we use detect that a version of our App that is already installed was using a different signing certificate (if it's more than a day old) and NOT install the update. I did not keep notes but previously we had a signing cert that had our company with some lowercase letters, and the new crt had those letters in uppercase. I could not upgrade the app that was installed with the old cert with an installer for the new cert.

While testing I observed the same with our current (expiring cert) I have an installer with that cert, and craeted a new installer with a Trusted Signing cert. Again reasons, ths old(current) cert has our info as:

Publisher="CN=Calway Nederland b.v., O=Calway Nederland b.v., S=Groningen, C=NL"

and the new cert has some more required fields which ended up as:

Publisher="CN=Calway Nederland b.v., O=Calway Nederland b.v., L=Groningen, S=Groningen, C=NL"

When I tried to install the newly signed msixbundle it did not offer an update but instead gave me a new parallel installed program. But all previous installers I generated with our old(current) cert detect the App is installed and offer to update. This might be something of the way msixbundles (or even wapproj's) work. Dealing with this every 3 years was OK, but having to deal with this every install that has a new trusted signing cert is unworkable.

I did not change anything, only updated the publisher to reflect the cert, and it seems to break updates.

At first I even forgot to update my Package.appmanifest with the new Publisher info and then I got an App failed to install issue, the number I got resulted in a google search that said the cert used to sign must match the Publisher mentioned in the appmanifest. So my whole issue might be installer related 😦

P.S. Because of my long post I always have to secure the text and reload the page and paste my comment due to the page being invalidated too fast for me 😃

@Johann,

The certificate expiration only applies to validity window in regards to when the file is signed. Once signed the signature is valid and never expires, regardless of the expiration date of the cert. If that wasn't so you would never be able to install an old version of any software 😄. The certificate only needs to be valid on the date of signing, so with Trusted Signing if the cert auto-rotates you're always signing with a current certificate.

As to installation: My build process (Powershell scripts) build my applications for distribution and in that process sign all the relevant files. I use the signing script from the post to sign all of my main executables (EXE, DLLs) and the final packaged installer in AppSetup.exe. I use Inno Installer so it's an EXE but same story if you're building MSIX packages.

So I forgot about this and came back to it today. Our signing cert expires in March 20206. I got signing of an msixbundle working with your giude, thank you very much for that. It also signs the msix files inside the bundle it seems and since this is a .wapproj there are about 4-5 msix inside so every publish will take 5 calls out of the 5000 monthly limit. We are also using .appinstaller files to get automatic updates the Microsoft way 😐I am wondering something:

Previously I renewed a cert but was not accurate with some of the fields, a casing change in the O= field which seemed to mess up updates. We have a windows application that received regular updates using .appinstaller and the update did not go though due to a changed cert. I noticed that starting the msixbundle installer with the new cert does not recognise that an older version already installed and signed with the current cert. I have not tested yet but am afraid that just pointing the .appinstaller to a new msixbundle that is signed with the new cert will break updates...again. Previously we had to tell customers to uninstall the old version and reinstall the new one. At the time I thought that's a one time thing and at worst I don't have to do this 3 years, the length of the new (previous) cert.

But I am wondering what happens when these Trusted Signing certs that only live 3 days. Will that be a problem for .appinstaller msixbundle updates. Or does this process actually only look at the Publisher="CN=....." value, which will remain the same now and still update.

@Rick: Do you use installer or are you code-signing the .exe and do you have an update mechanism? What method of updates do you use. I guess for a single .exe program you could simply replace, but our software is not single file and we use th package.appmanifest to create some shortcuts.

I just created a new installer, installed it and will wait three days and then generate a new msixbundle with a new cert and see whether this updates, of parallel installs 😮

@Mirco, so I tried this but was unable to duplicate the behavior I see in MM.

I'm using this after trying to create the nul file as you mentioned (and several other ways actually). I don't know how to really check but this code is not failing afterwards:

echo "OK" > echo OK >>\\.\d:\temp\test\nul

Then in LinqPad:

string baseFolder = @"d:\temp\test";
var opts = new EnumerationOptions
{
   MatchType = MatchType.Simple,
   AttributesToSkip = FileAttributes.None // FileAttributes.Hidden | FileAttributes.Temporary 
              
};

// MatchType.Simple
var folders = Directory.GetDirectories(baseFolder, "*", opts);
folders.Dump();   

// Old School Windows pathing  ( MatchType.Win32)
folders = Directory.GetDirectories(baseFolder, "*.*");
folders.Dump();

This doesn't fail and lists all the folders as expected.

@Lukas, what's your location? My guess is that you're signed up through a region that is not support (yet?)...

Thanks for the detailed instructions.

I'm encountering a problem at the very beginning: In my Azure Portal, there is no "Trusted Signing Accounts". When I type "trusted" into the search box, nothing is being found.

Has anyone seen this issue?

@Rick "dotnet sign" does indeed support azure trusted signing. I just tried it with a registered app as my service principal to automate my stuff and it works. Cheers!