RDM 2025 - requiring .NET9 is a bad idea!

Hello,

Thank you for sharing your thoughts with our community.

The mobile teams were awaiting critical fixes that were only addressed in .NET 9, including the SQL Server TLS issue on Android, which will not be available in .NET 8. These fixes were essential to ensuring the stability, security, and functionality of our application across all our platforms.

Beyond these specific fixes, our decision to move to .NET 9 was also driven by performance improvements. Upgrading now allows us to optimize our application, take advantage of the latest enhancements, and ensure a smoother transition to future versions. Additionally, preparing for .NET 10 is a key part of our strategy, as it aligns with our roadmap for maintaining a modern and efficient tech stack.

We appreciate your feedback and understand the importance of versioning considerations. We have taken note of your comments and are actively planning an update to .NET 10 by the end of the year to keep our application up-to-date with the latest advancements.

Best regards,

Hello,

to be honest, as long as .NET9 is a requirement I am not sure if we or other companies are able to use this version...

Rolling out multiple .NET versions on Windows clients involves testing and compatibility considerations and this whole effort only that we have .NET9 for let´s say 7-9 months on a subset of clients? And this is also nothing we ca do today as we have some lead time and other projects that are already in the pipeline.

Can´t you stay with the Windows version on .NET8?

Brgds Andreas

Hello Andreas,

We understand your concerns regarding updating to a Standard Term Support version of .NET rather than a Long Term Support version. Unfortunately, the decision to update to .NET9 was made a while back in our development cycle and it's not possible for us to revert these changes at this point. As Érica mentioned above, we decided that upgrading to .NET9 and getting these security fixes and performance improvements were crucial enough for our products that requiring a STS version of .NET was the right call.

We're taking your feedback very seriously and alongside planning to update to .NET10 (LTS) once it's available, we will discuss how we will handle future .NET updates, in particular when it comes to the advantages and disadvantages of STS and LTS versions.

Regards,

Hello Hubert,

Thanks for that - I will discuss with my client team if and when they are willing to do a .NET9 rollout for a specific subset of clients.

Brgds Andreas

Hi Andreas

In the RDM 2024.x timeframe (.NET 8) we explored some methods of getting RDM to use a portable (not installed) version of the .NET runtime. I don't see why that wouldn't be possible with 2025.x and .NET 9. Let me know if that's something interesting for your use case and we can provide more details and review this further.

Kind regards,

Hello Richard,

yes - of course! If this would be possible it would be an option...

Thanks a lot for your help!

Brgds Andreas

Hi Andreas

First - and I don't know If this is an option for you - but the RDM installer has the capability to install (downloading if necessary) the required .NET runtime. You can activate it by installing from the command line and passing an additional parameter to the installer. Depending on your needs that may or may not be useful, but I believe we have a knowledge base that explains how to do that if it's interesting.

Otherwise, I did prototype the ability to download the .NET runtime to a location on disk (i.e. download the .zip archives direct from Microsoft and extract them, without installing them). It's then possible to set up the environment in such a way that RDM will use that "local" .NET copy rather than an installed one. In my tests I did that by using a wrapper script, but that was just a simple way to achieve the required result. I never tested this approach thoroughly but it seemed to work well. That's an idea that we can develop further. If it's interesting for your use case, let me know - I will dust off my notes on that and start by checking it's still viable with .NET 9.

Best regards,

Hello Richard,

I know that option for the installer, but I would prefer not installing it, if the process to use a portable version is not too complicated...

Another option I just thought of - would it be possible (also for the future) if there is a folder "dotnet" inside "C:\Program Files\Devolutions\Remote Desktop Manager" that RDM automatically uses this runtime instead of the installed one? This way no workaround is needed to start RDM with a portable .NET version.

Brgds Andreas

Hi Andreas

I understand about the installer option, but let's keep it mind if it can be helpful in the future.

To give some background: it's possible to ship a .NET application "self contained"; i.e. including the relevant runtime pieces it needs so it can be used without installing a standalone runtime. We don't take this approach with RDM for two reasons: firstly, it would greatly increase the size of the downloaded application; secondly - and most importantly - it ties the application to that specific runtime version. What this means in a practical sense is that minor updates of the runtime often include important security fixes, and having these be applied out of band (e.g. through Windows Update) ensures the framework is current without the user necessarily needing to update RDM as well.

As we talk about a portable installation, that second point becomes quite important - a portable copy of the runtime will have to be maintained (kept current) by the user. The negative effect of not doing that is missing important security or bug fixes. How important that is for you depends on your specific requirements of course.

In practical terms (and I just tried this on my side to check it still works), it's possible to download .zip archives of both the .NET Runtime and the .NET Windows Desktop Runtime (both are needed). This isn't obvious because it's not shown on the download page, but you can find the links in the releases.json.

If we check the main releases index here, you can find the channel you're interested in (in this case 9.0) and then get the link for the specific releases.json. You'll find that the relevant packages have both .exe and .zip downloads. Parsing this information is quite straightforward and could be scripted easily (we already do that in the RDM installer).

With both those archives downloaded it's as simple as extracting them to the same directory (e.g. c:\dotnet). You now have a portable .NET runtime.

To get RDM to use this runtime; you need to set the environment variable `DOTNET_ROOT`. So, sticking with my example folder above:

PowerShell 7.5.0
PS C:\Users\rmarkiewicz> $Env:DOTNET_ROOT="c:\dotnet"
PS C:\Users\rmarkiewicz> & 'C:\Program Files\Devolutions\Remote Desktop Manager\RemoteDesktopManager.exe'

And I confirm with ProcMon.exe that RDM is indeed using my portable runtime. This will also work on a machine with no .NET runtime installed.

Unfortunately it's not so simple as just dropping the dotnet folder inside the RDM install folder, because we need to setup the environment first. But that can be easily achieved via a simple wrapper script.

Here's a gist of a simple script I put together to show the viability of a self-contained RDM install that could run from a USB stick, for example.

A downside is that RDM must be launched with the environment set. If, for example, RDM is not already running and you click a rdm:// link, it will try to open RemoteDesktopManager.exe directly and bypass this (it won't work). There are ways around this too, although it starts getting more complicated. But that's an example of an edge case doing things this way - there may be others I haven't though about.

If this sounds interesting - and, given the disclaimer above about keeping .NET update - it should be relatively easy to script, or we could explore this idea further on our side and see if there's a reasonable middle ground between now and the end of the year (.NET 10).

Please let me know if you have some question or something isn't clear

Hello,
I have to agree with Deas, that requiring a .NET STS version for a product targeted at business users is not a good idea.
At our company we can only use the LTS versions of .NET and the same goes for PowerShell. So at the moment I have to use .NET 8 and PowerShell 7.4 on my client and our servers (I use RDM on a couple different jump hosts).
That means I am stuck with RDM 2024 and PowerShell module 2024 for a year until your next release.
Please consider sticking with LTS for .NET and PowerShell for your next release and skipping the STS versions.

Also, thank you, Richard, for your comprehensive post about building a portable environment, at which I will take a look later.
But from what I can already see it is not as user-friendly as I would hope and I don't understand why you couldn't just package a self-contained installer or ZIP and offer it at your downloads page. You could still keep your standard release for users that want the smaller package and add the self-contained package as optional download.
You release RDM often, so that the .NET in your package would be reasonable up-to-date (hinting at security concerns).

Thanks for your considerations

Hi

Shipping RDM alongside a portable .NET runtime is probably not something we want to start doing. In the first case, I'm not sure that this approach is something officially supported by the .NET team - I figured this out by reading the code of their native bootstrapper executable. It's not documented anywhere that I could find. What this means is, it's essentially an implementation detail and could change unexpectedly. I can't imagine that they would change it, at least outside a major release, but the risk is there. Leading me to the second case - it's an investment on our side in terms of how we build, package and distribute RDM for a problem that will ultimately go away in the next major release cycle with .NET 10.

That being said, I could propose a middle ground: it would be academic to provide a "batteries included" PowerShell script that could automatically download the latest runtime and RDM, and package it up in a neat way. That would be something you could run on your side to make your own RDM "distribution". We already had a contribution along those lines for our documentation, although it focused on the runtime side of things and had the user supply the RDM download. It would be straightforward to write something like that did "everything".

Let me know if that sounds interesting.

As always, thanks for your feedback and please don't hesitate with further questions or comments

Kind regards

Hello,
I understand. You decide to stick with .NET 10 (and PowerShell 7.6 pls) for your future releases, then it would make no sense to ship a self-contained version. I am completely fine with that. This is what I wanted in the first place.

Your tailored script sounds VERY interesting and I would use it in a blast, but before that I have a few questions:

• Can I deploy the portable package on my servers and still use the jump host functionality? You said something before about not registering with rdm:// links. I guess that wouldn't apply to my case, because I use the agent on the servers?
• Can I use the PowerShell module 2024 with RDM 2025 (including up to version 2025.3)? I recently discovered RDM and the extensive functionality it has, including PowerShell scripting support - which is a huge selling point for me.

Thanks

Hello

I've been thinking about this and have some ideas about how we can ship a portable + .NET version in the interim before .NET 10 / 2026.1.

I'd like to address your questions first to help determine how useful this will be.

• Jump host functionality should work the same as far as I can tell. Indeed the installer does setup like register the handler for rdm:// links (although, this is just adding the proper entries to the registry, there's no magic here). Since you use the Agent on the server that should work fine.
• PowerShell is something that's harder to address. You can use the 2024.x PowerShell module against a 2025.x RDM version, but you'll probably hit issues with that in terms of the data structures and feature compatibility. You wont' be able to use the Devolutions.PowerShell module inside the portable RDM because the versions there are aligned (the 2025.x RDM ships the 2025.x PowerShell module). In general, PowerShell features inside RDM that don't use our PowerShell module should work as normal.

Let me know what you think

Kind regards

Hello,

I played around with the option you showed above with setting the "DOTNET_ROOT", but that is not practical and we would need to do a complete new rollout for our users to make that work. Current Shortcuts and links would not work - complicated...

So whatever solution you choose, it should be "automation friendly" and easy to deploy without the need to reinvent the wheel. As I already wrote above - if e.g. a "dotnet9" folder exists in a defined path you define, this version is used. If this path does not exist, use the runtime installed on the system.

Brgds Andreas

Hi Richard,

yeah, I use Devolutions.PowerShell module 2024.3.11 on my client. Like I said earlier, I discovered RDM not so lang ago and migrated from RDCMan. At work I manage 300+ Windows servers and used PowerShell to import additional data from csv, then change entry names, description, custom fields, iDRAC information and make sub entries. What I still want to do is make scripts for adding new servers and retiring old servers, which would include automating Tag management.
Also I already used "Edit --> Special action --> Custom PowerShell command" in RDM to change templates on entries for example.

This is something that has to work for me, otherwise I can't use RDM 2025.

Hello

@Laspeed: Ok, I understand. If PowerShell integration is a deal-breaker for you, I don't think this approach can be much help. It might be possible to also ship / support a portable PowerShell install but that really starts to get very complicated.

@Deas: Sadly it's not that simple. RemoteDesktopManager.exe is the native loader built by .NET; does some checks (e.g. is .NET installed?) and then does the equivalent of `dotnet run RemoteDesktopManager.dll`. It's this executable that checks for `DOTNET_ROOT` and uses it if it's defined. We can't influence its behaviour beyond modifying its environment; which is why my example uses a PowerShell script to set the environment before running the application. Now, that wrapper could check "Is there a portable copy of .NET here? If so, use it, otherwise use the installed version" but this still broadly breaks a bunch of integrations (since RemoteDesktopManager.exe might - probably - not be directly executable anymore).

The only viable workaround in that case is to replace the .NET loader (RemoteDesktopManager.exe) with a custom executable that could recreate the .NET native loader behaviour and provide this capabilities. Then it starts getting complicated, because someone would need to write and maintain that loader, integrate it into a CI, it would need to be signed, integrating into the delivery process; etc.

I'm not saying it's not possible, but it starts to look like a good chunk of work and an ongoing maintenance burden for an issue that will self-resolve within the next 6-7 months. We could do it; but I think we'd need to know that the interest was there and it would really solve the problem for affected customers. Especially since it's likely to be an imperfect stopgap - for example, the PowerShell version conflict that makes it not viable for @Laspeed.

Please, let me know if you have some questions

Kind regards

For now we will stick with the latest 2024 version, because the stunt with the PowerShell Script won´t work for an automated rollout for about 30 Users across our whole IT department - too many things could go wrong and RDM won´t start...

Brgds Andreas

Hello

Yes, I understand. I apologize for the inconvenience.

Kind regards,

Hello,

as .net 10 LTS is out now since November - when will RDM support or require .net 10? Wil it again be a hard cut from .net 9 to 10? Or is it possible to make it smoother for us?

Thanks a lot for your help!

Brgds Andreas

Hello,
This is something we plan to do for RDM 2026.1. This release is planned for March 2026. What do you need us to do to smooth things out? By the way, we don't plan to update to .NET 11 after that and will stay on the LTS only.

Regards

Hello David,

those are basically good news as we all have time enough to prepare our environments. In the meantime I have learned that .net versions can exist in parallel and don´t interfere each other. So we can plan and test our .net 10 rollout in Q1 2026.

I still don´t know if this is possible, but if RDM would work with 9 and 10 at the same time, I am sure it would help if it takes longer to do the .net 10 rollout.

Brgds Andreas

Hi @Deas

You're correct that .NET versions exist in isolation and don't interfere with each other.

It's technically possible for us to build the application in such a way that it would run on both .NET 9 and 10; but it would introduce complexity and technical debt on our side that we don't want. Moving forward with RDM 2026 we're "all in" on .NET 10. As David wrote we plan to skip .NET 11 and stay on LTS only, so the next potential time we go through this will be .NET 12. If Microsoft follows their current cadence, that would be after November 2027.

From our side, for the 2026 release we'll do the following:

• The .NET requirement will be clearly noted in the release notes
• The runtime installer can still be invoked by passing `INSTALL_DOTNET_RUNTIME="1"` to the msi and it will install the .NET runtime if needed. This may be useful for power users or, most specifically, customers using an MDM like InTune
• The update available page within RDM >= 2025.3.30 as well as the updater application itself will warn the user if a .NET update is required, and provide a direct link to download the framework
• For new installs or updates outside of RDM, the application itself will prompt for the missing framework on first run

Actually, those things seem largely irrelevant for your specific case: if you're able to rollout .NET 10 ahead of the RDM release in March, you'll be in a good position. I just wanted to highlight some of the changes we've been making to smooth the road here.

Please, as always, don't hesitate with further questions or comments

Kind regards,