Lock framework version possible?

We are planning to integrate our Radzen project into a bigger .net-solution. To share parts of our codebase directly to Radzen. Now there is always the possibility that we are using the same framework but in different version. My very vague question is: Do we have the possibility to tell Radzen which framework-version it requires? Like for an example, you upgrade to ASP.NET Core 3, we do that too, but earlier or later than Radzen, how could we handle the situation?

Or maybe you have a download location for older versions? Which we would install and disable updating, dunno.

You can download any older version. Here is the format of a download link:


Also you can disable automatic updates.

Just have in mind that Radzen doesn't support side-by-side installations at the moment.


When I start a second instance, the 2 settings 'Watch for external changes' & 'Check for updates' are getting enabled again. And since the updates come forced ... is there a way to disable the update-checker in the whole?

Hi @Moo,

Unfortunately we would have to rewrite the way settings are stored in order to support this. Which will lose all user's settings. When you start a second instance you can disable both settings - this should work per instance.

I am a little bit afraid of the following situation:

  • I open another instance
  • I forget to instantly disable the update option
  • Radzen starts to force the update

Maybe you could find a totally different way to block updates?
Like taking the axe, breaking updates in the whole.

The only way to block updates of an Electron app such as Radzen is to not download them. This is what that settings does. We persist it in the localStorage but for some reason a new instance uses a clean new instance of localStorage. This is a known limitation which we can only overcome by changing the way settings are persisted. This is quite a bit of effort though and we won't be attempting it any time soon.

This linked issue is closed as wontfix. If it's by design, wouldn't it be better to directly prohibit a second instance if electron isn't made for this?

I mean, if I want to use it but it works in an unforseeable way it's probably not good.
Would make my problem worse but would be more consistent with the framework-design.
I should probably find another way to compare my settings anyway.

I just realized that VS Code can do this. So it has to be possible to work with multiple instances.
Aaaand it just happend, I opened another instance, disabled checking for updates as soon as I could but still I am now forced to update:

VS Code spawns a single main process with multiple windows. In order to implement something like this in Radzen we would have to rewrite a few core modules. Out of curiosity why don't you want to update Radzen? Do you not plan to get new features and fixes?

Yes I do, but I do want to control when. Would you like to work in an environment which forces you to change when it likes to do it? This intention is about controllability.

EDIT: there isn't even a heads-up to it. Imagine you are shortly before a release, of multiple components. And then one component just decides to change ... because it thinks now is a good time.

Well a lot of software gets updated automatically like this - Google Chrome, FireFox, VS Code. Even Windows Update is quite hard to stop.

Anyway we will change the way settings are persisted next year. So far this is the only case where people are using two Radzen instances all the time when this problem manifests.

I really like auto-updates. But for some parts these are horrible. Eg. we are using Win10 here, to do our job, to earn money. And it happened more than once to me that I had to start my day with rollbacks or driver/hardware problems. It is horrible when you loose control in your main working-environment. I just do not think this is the way to go for devs (end-users on the other hand: for sure).

Thank you for the bright looking future updates :slight_smile:

EDIT: to be a little bit more specific about your question: we integrated our Radzen-VS-Solution into a bigger solution and have to be careful with dependencies.