Does Sentinel only run under .NET Framework 2.0?

[K4EET]

I just underwent a complete hard drive wipe to install Microsoft Windows 10 Home Version 21H1. This gives me a fresh start on life and a very fast running system that had become increasingly sluggish over the years . HDD and registry defrags and other system maintenance actions did not achieve the performance that I have now. Not wanting to copy any corrupted files back onto the HDD, I am reloading the essential programs to keep things running smoothly around here.

Then comes Sentinel Version 2.02.01 and the corresponding serial drivers. As a matter of course, I had previously loaded Microsoft .NET Framework v5.0.6 for another program but when I go to load Sentinel, I get an error dialog that states in part "This setup requires the .NET Framework version 2.0. Please install the .NET Framework and run this setup again."

Does Sentinel absolutely require .NET Framework version 2.0 and nothing higher?

Surely that is not the case. Microsoft .NET Framework version 2.0 is no longer supported by Microsoft. Anyway, I loaded .NET Framework version 2.0.9 and the Sentinel loader is still giving me the same error dialog that states in part "This setup requires the .NET Framework version 2.0. Please install the .NET Framework and run this setup again."

So I wonder what the issue could be? Surely Sentinel is not looking for Version 2.0 exactly. Has anybody tried to install Sentinel version 2.02.01 on a new computer with Windows 10 Home version 21H1 which became available on 18 May 2021 according to this Microsoft Windows Blog posting? While I mainly use ProScan and BuTel Software's ARC536PRO, which by the way are running under Microsoft Windows 10 Home version 21H1 and Microsoft .NET Framework version 5.0.6 just fine, I do use Uniden's Sentinel software every now and then. Of course, there are some things that can only be done with Sentinel software.

Anybody with some things that I might try to alleviate this issue, your comments will be greatly appreciated. Finally, here is a shoutout to @JoeBearcat who might also be able to shed some light on this dilemma.

Thanks everyone for reading! Cheers!

Dave K4EET

 

[hiegtx]

I just underwent a complete hard drive wipe to install Microsoft Windows 10 Home Version 21H1. This gives me a fresh start on life and a very fast running system that had become increasingly sluggish over the years . HDD and registry defrags and other system maintenance actions did not achieve the performance that I have now. Not wanting to copy any corrupted files back onto the HDD, I am reloading the essential programs to keep things running smoothly around here.

Then comes Sentinel Version 2.02.01 and the corresponding serial drivers. As a matter of course, I had previously loaded Microsoft .NET Framework v5.0.6 for another program but when I go to load Sentinel, I get an error dialog that states in part "This setup requires the .NET Framework version 2.0. Please install the .NET Framework and run this setup again."

Does Sentinel absolutely require .NET Framework version 2.0 and nothing higher?

Surely that is not the case. Microsoft .NET Framework version 2.0 is no longer supported by Microsoft. Anyway, I loaded .NET Framework version 2.0.9 and the Sentinel loader is still giving me the same error dialog that states in part "This setup requires the .NET Framework version 2.0. Please install the .NET Framework and run this setup again."

So I wonder what the issue could be? Surely Sentinel is not looking for Version 2.0 exactly. Has anybody tried to install Sentinel version 2.02.01 on a new computer with Windows 10 Home version 21H1 which became available on 18 May 2021 according to this Microsoft Windows Blog posting? While I mainly use ProScan and BuTel Software's ARC536PRO, which by the way are running under Microsoft Windows 10 Home version 21H1 and Microsoft .NET Framework version 5.0.6 just fine, I do use Uniden's Sentinel software every now and then. Of course, there are some things that can only be done with Sentinel software.

Anybody with some things that I might try to alleviate this issue, your comments will be greatly appreciated. Finally, here is a shoutout to @JoeBearcat who might also be able to shed some light on this dilemma.

Thanks everyone for reading! Cheers!

Dave K4EET

Yep, Sentinel has it's little peapickin' heart set on .net 2.0

What you'll need to do is actually install 3.5, which includes 2.0
I had to do the install on my primary desktop when I upgraded it to Windows 10 Home Premium (64-bit).

There's several ways to do this. Take a look at this link:

Install .NET Framework 3.5 on Windows 11, 10, 8.1, 8 - .NET Framework

Learn how to install the .NET Framework 3.5 on Windows 11, Windows 10, Windows 8.1, and Windows 8.

docs.microsoft.com

In my case, I ended up selecting 3.5 to be installed, then had Windows Update do the actual deed.

Google 'how to install .Net 2.0 on Windows 10 & you'll see a number of links on ways to walk you through it.

 

[K4EET]

Hi Steve (@hiegtx),

Thanks for your clear and concise post. I looked at the link you gave

Install .NET Framework 3.5 on Windows 11, 10, 8.1, 8 - .NET Framework

Learn how to install the .NET Framework 3.5 on Windows 11, Windows 10, Windows 8.1, and Windows 8.

docs.microsoft.com

and let Windows Update do all of the work. That could not have been easier! And the good news is, Uniden's Sentinel v2.02.01 installed and ran with no further complaints.

Thanks for getting me through this install!

Dave K4EET

 

[N9JIG]

I had the same experience as Steve. I recently bought an M1 Mac which runs on an ARM processor, not Intel like prior Macs. I use Parallels to run Windows on my Macs and have no problems running Sentinel, ARC, ProScan and our phone system applications in Windows on my Intel Macs. Some of these (Sentinel and our phone system) require DotNet 2.x to run.

I could not install DotNet 2.x on the M1 Mini as apparently it only works on x86 and not ARM. I read up on the issue and found that 3.5 includes the parts of 2.0 required and is a worthy substitute. I had to wait for the ARM version of Windows to request the necessary updates and a week later it finally did install 3.5, after which Sentinel and the phone system ran just fine.

I don't understand all the details as I am not a computer programmer but apparently there are different types of the DotNet Frameworks, higher value numbers do not necessarily include the needed bits of lower ones. Apparently 3.5 is a replacement for 2.x but 4 and 5 etc. are not.

It is my understanding that Windows does not install DotNet unless there is an application that requires it. Why they don't just roll in the features etc. into newer versions to require only the latest build is beyond my knowledge.

 

[K7MFC]

It my understanding that Windows does not install DotNet unless there is an application that requires it. Why they don't just roll in the features etc. into newer versions to require only the latest build is beyond my knowledge.

Long time .NET programmer here - I can help provide some additional insight - starting with .NET version 4 and later, it is backward compatible with apps that were built with earlier versions of .NET. So apps built with previous versions will (or should) work without code modification on the .NET Framework 4 and later versions.

Most apps that target .NET will include a configuration file that specifies the version to use. That config file can be edited to tell the app to target a specific .NET v 4.X version you have installed on your computer. See this for more info about the config file.

To the average user, it's kind of confusing, but from a technical standpoint, the .NET framework is quite a technical feat. It allows applications to be written once, then executed on computers with an incredibly wide variation of hardware from many different vendors/manufacturers - CPUs, graphics cards, RAM types, USB peripherals, etc. And now with the latest versions of .NET (5 +) applications will run in multiple different operating systems, including Windows (NT+), Linux, and POSIX operating systems, including MacOS. Versions 5 and above are a complete re-write of the framework and applications targeting versions 4 and below will never work on versions 5 and above.

It's a different philosophical approach than Apple takes with its "walled garden," where only very select hardware components are supported. The tradeoff with that approach being the goal of a better user experience by limiting users' hardware choices.

 

[ProScan]

Long time .NET programmer here - I can help provide some additional insight - starting with .NET version 4 and later, it is backward compatible with apps that were built with earlier versions of .NET. So apps built with previous versions will (or should) work without code modification on the .NET Framework 4 and later versions.

Most apps that target .NET will include a configuration file that specifies the version to use. That config file can be edited to tell the app to target a specific .NET v 4.X version you have installed on your computer. See this for more info about the config file.

I did not know that. You're right. I just tested it by editing the "exe.config" file and changed the line <supportedRuntime version="v2.0.50727"/>
to <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.8"/>

To the average user, it's kind of confusing, but from a technical standpoint, the .NET framework is quite a technical feat. It allows applications to be written once, then executed on computers with an incredibly wide variation of hardware from many different vendors/manufacturers - CPUs, graphics cards, RAM types, USB peripherals, etc.

That's actually Windows and not the .NET Framework. Windows is 'device independent'. Before Windows in the DOS days, I think printers were the worst to program as each manufacture had a different command set. Modems weren't as bad because the modem manufactures came out with a standard 'AT' command set.

And now with the latest versions of .NET (5 +) applications will run in multiple different operating systems, including Windows (NT+), Linux, and POSIX operating systems, including MacOS.

It's not as simple as changing the target platform, compile, and run. If a program uses any platform specific APIs then it will require modification to work on other platforms. Take the Win waveIn and waveout API sets used for audio from/to the sound card. The .NET Framework namespaces (or library's) has no audio capability so the Win APIs are needed. So each platform will need to use its own APIs. Some programs may have a hundred or more Win specific API so it would be quite a chore to target other platforms. Also some programs are using dll files with Win specific APIs.

 

[K7MFC]

It's not as simple as changing the target platform, compile, and run.

Oh, I know lol - at my last job I led a project to re-target an ASP.NET 4.8 application to .NET 5 and it was a massive undertaking. But that built-in dependency injection support in .NET 5 is so nice

 

[K4EET]

Gosh, from my simple problem child (Sentinel) question has come a lot of interesting comments. Thanks everyone! I have C++ in my background but I know very little about the .NET Framework world. Just goes to show that RadioReference is a great and awesome community. There seems to be every aspect of any subject matter represented here. Sometimes I wonder just what this "Think-Tank Community" could come up with if we all worked together to solve those unsolvable issues and challenges facing mankind...

 

[K7MFC]

Sometimes I wonder just what this "Think-Tank Community" could come up with if we all worked together to solve those unsolvable issues and challenges facing mankind...

The FOSS (free and open source software) ethos in a nutshell

 

[K4EET]

The FOSS (free and open source software) ethos in a nutshell

Yes, and SourceForge is a prime example of that...

 

[JoeBearcat]

Long time .NET programmer here - I can help provide some additional insight - starting with .NET version 4 and later, it is backward compatible with apps that were built with earlier versions of .NET.

Thanks for that info. It was always odd that later versions of .NET were not backward compatible.

 

[K7MFC]

Yeah, I unfortunately don't have an answer to why earlier versions of the .NET framework are not backwards compatible. My best educated guess is that Microsoft could push new features faster by not making new versions backwards compatible, having the frameworks installed side by side, and they did not need to worry about making changes non-breaking. At some point that view must have shifted (probably around the debut of .NET Core and cross-platform support), and .NET 4.5 featured backwards compatibility.