ASP.NET 2.0

ASP.NET final release will be launched soon.
Application migration from 1.1 to 2.0 will not be so fast.
It can be useful if in script manager a web admin can chose what .net framework version use on a web server.
Chose the version (1.x or 2.x) from a combo box and enable it.
Give the ability to hcadmin to specify two .net framework paths for .net script configuration, one for 1.x and one for 2.x instead of one as is now.

Regards.

right, couldnt agree more. I believe HC is already getting ready for the asp.net 2.0

it would be nice to hear HC about whats being done for the new .net version.

thx

Please check this thread and let me know If it is working fine with HC. Thanx

No it does not. Current script mappings needs to be changed individually by customers as their needs. Shall we discus here or there on the other thread?

We are working on it and will update you soon. Thanx for your patience.

There are not big differences with ASP.NET 2.0 at IIS level.
In the mappings should be added more mappings.
ASP.NET 2.0 creates mapping also for these extensions:
.browser
.cd
.compiled
.dsdgm
.dsprototype
.jsl
.ldb
.ldf
.lsad
.lsaprototype
.master
.mdb
.mdf
.msgx
.sdm
.sdmDocument
.sitemap
.skin
.ssdgm
.ssmap
.svc
.vjproj

ASP.NET 2.0 runs by default with impersonation turned off and trust level Full, like 1.1.
This means that asp.net applications run by default under the process identity of the application pool ("NETWORK SERVICE" the default). So, "NETWORK SERVICE" should have at least READ/LIST on document root.

There¬s the need of two buttons in the Script Manager, one to enable 1.x and another to enable 2.0, obviously exclusive.

It is more of an "Executable Path" issue more than the extensions itself. The current path needs to changed like "c:\windows\microsoft.net\framework\v2.0.50215\aspnet_isapi.dll" where needed. And we would need an interface for the webadmins to be able switch to 2.0 and back to 1.1 on thier own.

Thank you very much "comdotitaly" and "hgurol
" for the information. I will keep updating you about its support with HC. :)

Another thing. Dotnet 1.x and 2.x cannot run mixed in the same application pool.
So all dotnet 2.0 sites have to be grouped on a dedicated application pool.

ASP.NET 2.0 would be supported soon but HC will not handle more than one ASP version simultaneously. Whatever version path you have provided in HC Settings under Scripting tab HC will set mappings accordingly.

Which will help nothing Im not sure if you have realized the need here. Would you like to re-read the thread or want me to re-phrase the need to you?

Please explain why you want to keep multiple versions of ASP.NET?

As comdotitaly have already said; the migration from 1.1 to 2.0 will not be fast. Some of the client, both the current ones and the new coming ones, will need asp.net version 1.1 while some of them will ask for the new 2.0 version. This requires us to provide both versions at the sometime so that clients can choose which version they want to work with. If they upgrade their code to 2.0 they would be able to switch themselves to 2.0 while others may want to keep their 1.1 version. If I globally upgrade my version and force every client, at least every new client to use the new 2.0 version I probably will be losing them. I can not make a cut and do a sharp 2.0 upgrade for the whole server. This migration will take time and during that time both of them should be avaliable to customers upon their request.

I hope this is clear enough.

Did you mean that there are some version specific code problems in ASP.Net and new version is not backward compatible, that might crash the code already running on sites? I do not consider Microsoft would do such things.

Anyway we have seen some articles showing that people tend to use multiple versions of .Net framework on their systems, so we would be supporting it too. But we are not satisfied with your reasoning that the .Net code that was working on previous version would break on this latest version 2.0. I¬m sure you would have some articles to prove this theory. Thanx

Abdullah

v1.1 was only %90 compatible with 1.0 and that %10 part was enough to produce a hell of a problem to us. It was specially something with validators as long as I remember. Im not a developer, a developer would explain it better than I do. I dont need to look for an article to prove my theory, actually its not a theory but a fact which I have experienced with the previous upgrade. You are already working on and investigating this issue and Im sure you will find related articles about it.

There was a special directive like "Require version=1.0" which you place in the web.config files of the applications to make them work with the older version. We have tried that in the past and expected it to solve our problems at that time but honestly the only solution worked for us was to point the old version path in the script mappings. This is also something I have experienced in the past, not a theory.

Anyway, you will find related information during your investigation if you know what to look for and now you know what to look for :)