Any risks if I update my ASP.NET 2.0 application to 3.5?

  • Thread starter Thread starter Warren Tang
  • Start date Start date
W

Warren Tang

Hi everyone

I have a web application that is built for ASP.NET 2.0. Now I want to
update it to 3.5, so that I can use the AJAX controls.

What are the risks if I update it? What are the things that I need to
pay attention to?

Thanks in advance for your guidance!

Regards
Warren
 
Hi Mark

Thank you for the comment.

I noticed that a lot of new stuffs are added to web.config which I
haven't have the time to fully investigate yet. You know people are
usually nervous about the things that they don't know about. I am a lot
more comfortable about the clean web.config in 2.0.

The one thing I am especially worried about is that the existing code
may no longer work properly if I do the migration.

According to your comment, could I say that the possibility of that
regression is zero or quite low?

Regards
Warren

That the production server doesn't have v3.5 of the Framework
Click to expand...
installed...

I don't have to worry about that because the server is maintained by me :)

Regards
Warren
 
Hi Mark

Thank you for the comment.

I noticed that a lot of new stuffs are added to web.config which I
haven't have the time to fully investigate yet. You know people are
usually nervous about the things that they don't know about. I am a lot
more comfortable about the clean web.config in 2.0.

The one thing I am especially worried about is that the existing code
may no longer work properly if I do the migration.

According to your comment, could I say that the possibility of that
regression is zero or quite low?

That the production server doesn't have v3.5 of the Framework
Click to expand...
installed...

I don't have to worry about that because the server is maintained by me :)

Regards
Warren
 
Warren Tang said:
Hi Mark

Thank you for the comment.

I noticed that a lot of new stuffs are added to web.config which I haven't
have the time to fully investigate yet. You know people are usually
nervous about the things that they don't know about. I am a lot more
comfortable about the clean web.config in 2.0.

The one thing I am especially worried about is that the existing code may
no longer work properly if I do the migration.

According to your comment, could I say that the possibility of that
regression is zero or quite low?
Click to expand...

There is very little possibility of a regression because .NET 3.5 does not
replace .NET 2.0 - it adds to it. .NET 3.5 includes .NET 2.0 SP2, but that's
the only change your .NET 2.0 code should see - a service pack.

The .NET 3.5 stuff can't hurt you until you start using it.

This is in total contrast to the upgrade from .NET 1.0 to 1.1 and 1.1 to
2.0. They heard us, and they fixed that.
 
Hi John

Now I understand the 3.5 more. Thanks for the explanation.

Let me explain more about the scenario I am facing. I am going to extend
an existing ASP.NET 2.0 web application (say Project A). In order to
keep the existing things intact, I decided to create a new Web
Application project (say Project B), and place it in a subfolder of
Project A. (What I mean is that all the aspx files of App B are placed
in the subfolder, while the assembly of App B is put into the root bin
folder.)

Here is the file hierarchy:
--Root (Project A, built in ASP.NET 2.0, is a virtual directory in IIS)
----bin for all binaries
----web.config
----Subfolder (Project B, built in ASP.NET 3.5)
------web.config


Now problems come if I want to let Project B target 3.5. App A and B
have different web.config, while I have to merge the two in some way.

But how?

Regards
Warren
 
Warren Tang said:
Hi John

Now I understand the 3.5 more. Thanks for the explanation.

Let me explain more about the scenario I am facing. I am going to extend
an existing ASP.NET 2.0 web application (say Project A). In order to keep
the existing things intact, I decided to create a new Web Application
project (say Project B), and place it in a subfolder of Project A. (What I
mean is that all the aspx files of App B are placed in the subfolder,
while the assembly of App B is put into the root bin folder.)

Here is the file hierarchy:
--Root (Project A, built in ASP.NET 2.0, is a virtual directory in IIS)
----bin for project A binaries
----web.config
----Subfolder (Project B, built in ASP.NET 3.5) bin for project B binaries
------web.config
Click to expand...

There's no reason you can't make project B a separate web application.

Furthermore, you should just build the whole thing against .NET 3.5. Then,
all of the assemblies you currently reference in ASP.NET 2.0 will continue
to be .NET 2.0 code. It won't make any difference at all, unless it turns
out that you're depending on something that was a bug in .NET 2.0 but that
has been fixed in one of the service packs.

Remember that .NET 3.5 doesn't replace any of the .NET 2.0 code, except that
it installs a service pack, .NET 2.0 SP2. So you're not going to have some
code that's built in ASP.NET 2.0. _ALL_ of your code will be built on .NET
2.0 unless you decide to use a new feature. You would access the new feature
by adding a reference to the assembly that defines the new feature. It's no
magic - it's just as though the new feature came from a third party and you
added a reference to their library. Adding a new library doesn't change
which .NET version your code is using; neither will installing .NET 3.5.
 
Hi John

Thanks for your patience to explain it to me, and now I understand how
3.5 extends 2.0.

I finally solved the problem, and I'd like to share how I did it. Before
that there is one thing I need to clarify a bit.

Have a look at the hierarchy I mentioned:
--Root folder (Project A, built in ASP.NET 2.0, is a virtual directory
in IIS)
----bin folder for all binaries
----web.config A
----Subfolder B folder (Project B, built in ASP.NET 3.5)
------web.config B

What I want to emphasize is that Subfolder B (Project B) is not a
Virtual Directory or an Application in IIS. Project B is still in the
same application as Project A.

It take me three attempts to get the job done.

1. The first attempt is that I can leave the files and folders in the
above hierarchy as is, expecting everything would be fine. The thought
is that the web.config B will override web.config A, so that A and B
would not affect each other. But I got the following error:

Parser Error Message: It is an error to use a section registered as
allowDefinition='MachineToApplication' beyond application level. This
error can be caused by a virtual directory not being configured as an
application in IIS.
Source Error:
Line 27: <authentication mode="Windows"/>

Certainly the proposal is not what I need. Still I know that some
configuration cannot be place in web.config in a sub folder. So I
comment this line in web.config B:

<!--<authentication mode="Windows"/>-->

After that I openned an Ajax page in Subfolder B, I still got an error
saying:

Error: ASP.NET Ajax client-side framework failed to load.

I thought the reason was probably that the modules or handlers are not
able to be loaded from web.config B. I stopped here and went on to my
second attempt.

2. I was thinking maybe I can put all the stuffs in web.config B into a
<location> section in web.config A. In this way things in web.config A
and B are still not completely mixed up, and Web.config B would not
affect files out of Subfolder B.

Unfortunately, there was another error:

Parser Error Message: Only one <configSections> element allowed per
config file and if present must be the first child of the root
<configuration> element.

So it seems that <location> is not generous enough to accept the whole
things.

3. OK, now is the time to (or I should see I have to) mix up the two
web.config files. What I did was creating a new 2.0 project, put the
web.config A in the new project, and then updated it to 3.5. All the 3.5
stuffs were added to web.config A (lets say it A+). Everything seemed to
be fine, but it was not long before I was disappointed again.

I put the mixed web.config back into the root folder. However when I
tested the Ajax page in Subfolder, the Page was always postbacked. After
some time of hunting, I found this line made a difference:

<xhtmlConformance mode="Legacy"/>

So I made a modification to web.config A+.

<location path="subfolder">
<system.web>
<xhtmlConformance mode="Transitional"/>
</system.web>
</location>

Finally I got the job done, though not perfectly as I had thought.

I had hoped that there would be some documents specifying what
can/cannot be put in a web.config in a sub folder, and what can/cannot
be put in a <location> section. If anyone know this kind of document, do
tell me and I will really appreciate it.

So, that's all (Engish is not my native language so I found myself
unable to express all my feelings sometimes).

If you have any thoughts or suggestions, please let me know.

Regards
Warren
 
Hi John

Thanks for your patience to explain it to me, and now I understand how
3.5 extends 2.0.

I finally solved the problem, and I'd like to share how I did it. Before
that there is one thing I need to clarify a bit.

Have a look at the hierarchy I mentioned:
--Root folder (Project A, built in ASP.NET 2.0, is a virtual directory
in IIS)
----bin folder for all binaries
----web.config A
----Subfolder B folder (Project B, built in ASP.NET 3.5)
------web.config B

What I want to emphasize is that Subfolder B (Project B) is not a
Virtual Directory or an Application in IIS. Project B is still in the
same application as Project A.

It take me three attempts to get the job done.

1. The first attempt is that I can leave the files and folders in the
above hierarchy as is, expecting everything would be fine. The thought
is that the web.config B will override web.config A, so that A and B
would not affect each other. But I got the following error:

Parser Error Message: It is an error to use a section registered as
allowDefinition='MachineToApplication' beyond application level. This
error can be caused by a virtual directory not being configured as an
application in IIS.
Source Error:
Line 27: <authentication mode="Windows"/>

Certainly the proposal is not what I need. Still I know that some
configuration cannot be place in web.config in a sub folder. So I
comment this line in web.config B:

<!--<authentication mode="Windows"/>-->

After that I openned an Ajax page in Subfolder B, I still got an error
saying:

Error: ASP.NET Ajax client-side framework failed to load.

I thought the reason was probably that the modules or handlers are not
able to be loaded from web.config B. I stopped here and went on to my
second attempt.

2. I was thinking maybe I can put all the stuffs in web.config B into a
<location> section in web.config A. In this way things in web.config A
and B are still not completely mixed up, and Web.config B would not
affect files out of Subfolder B.

Unfortunately, there was another error:

Parser Error Message: Only one <configSections> element allowed per
config file and if present must be the first child of the root
<configuration> element.

So it seems that <location> is not generous enough to accept the whole
things.

3. OK, now is the time to (or I should see I have to) mix up the two
web.config files. What I did was creating a new 2.0 project, put the
web.config A in the new project, and then updated it to 3.5. All the 3.5
stuffs were added to web.config A (lets say it A+). Everything seemed to
be fine, but it was not long before I was disappointed again.

I put the mixed web.config back into the root folder. However when I
tested the Ajax page in Subfolder, the Page was always postbacked. After
some time of hunting, I found this line made a difference:

<xhtmlConformance mode="Legacy"/>

So I made a modification to web.config A+.

<location path="subfolder">
<system.web>
<xhtmlConformance mode="Transitional"/>
</system.web>
</location>

Finally I got the job done, though not perfectly as I had thought.

I had hoped that there would be some documents specifying what
can/cannot be put in a web.config in a sub folder, and what can/cannot
be put in a <location> section. If anyone know this kind of document, do
tell me and I will really appreciate it.

So, that's all (Engish is not my native language so I found myself
unable to express all my feelings sometimes).

If you have any thoughts or suggestions, please let me know.

Thanks again, John and Mark, for your help.

Regards
Warren
 
Back
Top