.net Framework V1.1 Download

0 views

Skip to first unread message

Najee Laboy

unread,

Aug 3, 2024, 5:27:55 PM8/3/24

to guetepobo

I suspect the reason you can't select Framework v1.1 when adding a new application pool or modifying an existing one is that the 1.1 installer doesn't know how to add some critical piece of metadata or config info to IIS.

.NET 2.0 ships with 2008 and .NET 4.0 being a later product is IIS7 friendly as well so there is most likely better IIS integration. Or, v1.1 doesn't have some essential nugget of metadata that IIS7's InetMgr needs to be able to add this to its various lists.

The reason you can see v1.1 in the drop downlist for the ASP.NET 1.1 pool Basic Settings dialogue and not the other pools is because it's already been set and so will just be included in the list. I experimented and changed this on the newly created ASP.NET 1.1 pool and set it to 2.0, saved, then re-opened. The result is that v1.1 isn't visible any more.

Additionally the reason it's called v1.1 and not .NET Framework v1.1.4322 is because the value is being picked up from the managedRuntimeVersion attribute in the app pool config in applicationHost.config. The reason that versions 2.0 and 4.0 show a full description is that there's probably some piece of IIS friendly metadata with a resource string being looked up that isn't present for 1.1.

I wish I could explain away why the ASP.NET 1.1 application pool magically gets created or how the installer manages to do the right thing with the handler mappings (somehow all the correct preConditions are set, so either the installer has been updated or IIS has some kind of trigger to look for 1.1 being installed and fix up things).

"If memory serves, in Vista/Windows 2008 there was an application compatibility shim created which would detect the 1.1 installer and do the app Pool creation/handler mapping.However, in Windows 7 / Windows Server 2008 R2, .NET framework 1.1 is no longer supported and I wouldn't be surprised if this code was pulled, though I don't know for sure."

I encountered the same problems whilst trying to install an old .Net 1.1. on Win2k8/IIS7. In the end I found it was easier and quicker just to bump everything to .Net 2.0. I would recommend you do the same.

Also look at log files. They usually have enough infos to find the problem. And likely not the case, but make sure you're not running out of disk space (I've had that problem once in vmware with a default 8gb partition which filled all too fast and made the .net framework install mysteriously fail, which it never had done before). Could be countless things.

I'm merely trying to install .Net 1.1 on an existing server that was built using an nLited image. .Net 2.0 isn't needed at this time. I was following the theory that nLite RC8 did something that kept the setup routine from succeeding. (Remember that this is Windows Server 2003 R2 Standard x64. .Net 1.1 is not included in the OS on 64-bit versions.)

Yeah, I know nLite 1.0 and later are out, but I'm using RC8 because I'm trying to find and fix something that was broken in a build that I originally created with RC8. I didn't want to change too much before I knew for sure the cause, you know?

Through the process of elimination, I finally figured out the issue was DEP! I can't remember for sure now, but I think nLite stuck the offending line in my winnt.sif at some point. Not knowing any different, I had left it in.

I knew this issue was related to our custom unattend/sysprep image which was built with an nLited CD. I started by removing items in winnt.sif and rebuilding a test box until the issue disappeared. Then I gradually eliminated/added back items to determine the root cause.

But on the existing server (where my current issue is), the ability to turn off DEP was disabled. (See the screenshot.) I had to create a new entry in boot.ini and re-boot to force DEP to its default state. (See for more information.)

Yeah, I'm not surprised honestly. While DEP sounded like a good idea at first, the implementation seems horribly broken. First time I've seen DEP in action was when a friend bought a new laptop with hardware that supported it. His Windows XP that came with it would crash in apps like notepad or the calculator... Turned DEP off, all problems gone.

If your integrations use connections to services that require the TLS v1.2 protocol, you should update your environment. The steps needed to keep your environment up-to-date depend on the .NET framework that you use.

In .NET applications, you can enable specific versions of the TLS protocol by setting the System.Net.ServicePointManager.SecurityProtocol property. The easiest way to achieve this in Kentico is to create a custom module and set the security protocol during the application initialization:

Here is an example of the TlsFixModule class:using System.Net;using CMS;using CMS.DataEngine;[assembly: AssemblyDiscoverable][assembly: RegisterModule(typeof(TlsSupport.TlsFixModule))]namespace TlsSupport internal class TlsFixModule : Module public TlsFixModule() : base("Custom.TlsFixModule") protected override void OnPreInit() SecurityProtocolType.Tls12;

These .NET versions are not compatible with TLS v1.1 or higher. To keep your integrations compatible with the latest standards, it is recommended to upgrade to the latest .NET framework version and Kentico version.