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.

1 Like

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.