Framework 2.0 interfering with 1.1 apps after upgrade

[dirk.dircksen]

Hi

I've searched quite a bit and haven't been able to find an answer to
this one:

We're in the process of installing .Net 2.0 on our production servers
(all Windows 2000 servers). None of the applications on the servers
use .Net 2.0 yet: all are on 1.1.

As soon as we install .Net 2.0, we start getting problems with our
applications, even though they're not running on the 2.0 framework. It
seems as if the ASP.Net process is picking up the machine.config for
2.0 or something and not the one we use for 1.1 as our applications
start refusing and dropping connections coming in or going out.

As far as I am aware, installing the 2.0 framework should have no
effect on existing applications: they should continue as before,
running on 1.1.

As soon as we take the servers offline, uninstall 2.0 and bring the
servers up again, the problem disappears.

If anyone has seen this or has any idea why/how this happens, I'd
appreciate some suggestions.

Thanks

DD

[Mike]

go to IIS, select your asp.net 1.1 web app,

right click --properties -- asp.net tab. make sure its configured to use
asp.net 1.1 and not 2.0.
If your .NET 1.x app is configured to use .NET 2.0 under IIS, it will fail.


<di***********@gmail.comwrote in message
news:11**********************@g4g2000hsf.googlegro ups.com...

Hi

I've searched quite a bit and haven't been able to find an answer to
this one:

We're in the process of installing .Net 2.0 on our production servers
(all Windows 2000 servers). None of the applications on the servers
use .Net 2.0 yet: all are on 1.1.

As soon as we install .Net 2.0, we start getting problems with our
applications, even though they're not running on the 2.0 framework. It
seems as if the ASP.Net process is picking up the machine.config for
2.0 or something and not the one we use for 1.1 as our applications
start refusing and dropping connections coming in or going out.

As far as I am aware, installing the 2.0 framework should have no
effect on existing applications: they should continue as before,
running on 1.1.

As soon as we take the servers offline, uninstall 2.0 and bring the
servers up again, the problem disappears.

If anyone has seen this or has any idea why/how this happens, I'd
appreciate some suggestions.

Thanks

DD

[dd]

Thanks, Mike.
I think the problem might be a bit more complicated than this.
If you read my post, you would have seen that the applications are not
failing, merely dropping ingoing and outgoing connections.
This means that they are running (which they wouldn't do if the .Net
version was wrong), but that after a .Net 2.0 install the ASP.Net
worker process cannot consistently and efficiently open outgoing
connections.
The amount of available outgoing connections and threads is normally
configured in the Machine.config file. I think, due to the fact that
after a .Net 2.0 install the *default* Machine.config is used by
ASP.Net, something is going wrong.
We work in a very high volume environment with multiple load balanced
servers, which means that we fine tune the servers as well as the
Machine.config to be able to handle the load.

Thanks once again

Dirk

[Alexey Smirnov]

On Jun 4, 8:59 am, dd <[e-mail]:

Thanks, Mike.
I think the problem might be a bit more complicated than this.
If you read my post, you would have seen that the applications are not
failing, merely dropping ingoing and outgoing connections.
This means that they are running (which they wouldn't do if the .Net
version was wrong), but that after a .Net 2.0 install the ASP.Net
worker process cannot consistently and efficiently open outgoing
connections.
The amount of available outgoing connections and threads is normally
configured in the Machine.config file. I think, due to the fact that
after a .Net 2.0 install the *default* Machine.config is used by
ASP.Net, something is going wrong.
We work in a very high volume environment with multiple load balanced
servers, which means that we fine tune the servers as well as the
Machine.config to be able to handle the load.

Thanks once again

Dirk

Dirk,

I think Mike is right and you should check the version of the ASP.NET,
once .NET2 is installed. I had an experience that ASP.NET Tab in IIS
could give you a wrong value, so, I would recommend to use
aspnet_regiis -lk

C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322>aspne t_regiis -lk

it returns all apps and .net versions

W3SVC/ 1.1.4322.2032
W3SVC/7/ROOT/ 2.0.50727.0
....

after that you can try to uninstall and install ASP.NET 1.1 again

aspnet_regiis -u
aspnet_regiis -i

[dd]

Thanks, Alexey.

I appreciate your comments, but, like I said previously, if the .Net
version was wrong, the applications would be failing completely, not
just acting strangely.
If my problem were only as simple as checking the version, I'd be
smiling ;)

So just to be clear: The applications are definitely running on .Net
1.1. The websites are definitely set up to run under 1.1. The sites
are not failing, they're just acting abnormally after a .Net 2.0
install, specifically when doing web requests to external providers.

I'm not sure what it is, but it just seems as if the ASP.Net process
is picking up the Machine.config from .Net 2.0 due to the fact that
there seems to be a difference in terms of how ASP.Net is handling
incoming and outgoing connections.

Thanks

Dirk

[Alexey Smirnov]

On Jun 4, 11:38 am, dd <[e-mail]:

if the .Net
version was wrong, the applications would be failing completely, not
just acting strangely.

Why do you think it would failed? ASP.NET 1.1 app should work on the
2.0 framework because ASP.NET 2.0 is almost backwards compatible with
ASP.NET 1.1.

[John Saunders [MVP]]

"dd" <di***********@gmail.comwrote in message
news:11**********************@k79g2000hse.googlegr oups.com...

Thanks, Alexey.

I appreciate your comments, but, like I said previously, if the .Net
version was wrong, the applications would be failing completely, not
just acting strangely.

This is not the case. Your ASP.NET 1.1 applications should work entirely, or
mostly, under .NET 2.0. In fact, this is much more likely to be a
configuration issue than a version-incompatibility issue.

This happened to me in the switch between .NET 1.0 and 1.1. I did not
understand that installing the new version would adjust the IIS script maps
to point to the new version.

You should "cd" to C:\WINDOWS\Microsoft.NET\Framework\V1.1.4322 and run
"aspnet_regiis -i". Note that it's important that you run the version of
aspnet_regiis from the correct framework version.
--
John Saunders [MVP]

[Juan T. Llibre]

Is your root application 1.1 or 2.0 ?

I was very much surprised when I found that web.config conflicts occur
in other applications no matter which .Net Framework is in the root.

I wouldn't be too surprised if there were some machine.config conflicts, too.

In the case of the web.config conflicts, the only thing which worked
was binding a website to a different IP or to a different port, i.e.,
*totally* isolating the .Net Framework versions from each other.

You might want to look into a similar workaround.

Juan T. Llibre, asp.net MVP
asp.net faq : http://asp.net.do/faq/
foros de asp.net, en español : http://asp.net.do/foros/
======================================
"dd" <di***********@gmail.comwrote in message
news:11**********************@k79g2000hse.googlegr oups.com...

Thanks, Alexey.

I appreciate your comments, but, like I said previously, if the .Net
version was wrong, the applications would be failing completely, not
just acting strangely.
If my problem were only as simple as checking the version, I'd be
smiling ;)

So just to be clear: The applications are definitely running on .Net
1.1. The websites are definitely set up to run under 1.1. The sites
are not failing, they're just acting abnormally after a .Net 2.0
install, specifically when doing web requests to external providers.

I'm not sure what it is, but it just seems as if the ASP.Net process
is picking up the Machine.config from .Net 2.0 due to the fact that
there seems to be a difference in terms of how ASP.Net is handling
incoming and outgoing connections.

Thanks

Dirk

[dd]

Hi Juan

The root aplication is set up as 1.1. All we're currently doing is
installing the 2.0 Framework in preparation for an upgrade. After the
install, we obviously have to do regression and load testing on our
1.1 apps, and this is when we start picking up problems.

I have checked in IIS Admin that the sites are running 1.1, as well as
making our web admins run "aspnet_regiis -lk" and "aspnet_regiis -i"
from the framework\v1.1 directory. There are no 2.0 sites or
applications on the servers at all.

Does this basically mean that unless we upgrade everything to 2.0
we're going to continue having problems with our 1.1 applications? Or
that we won't have a stable environment with both frameworks running
side by side?

Changing the IPs of our servers or creating new sites would,
unfortunately, not be possible, as we have public facing sites being
called by clients which cannot be changed (or rather, let me say: with
great difficulty and weeks of red tape).

I thought about application pools, but we're running IIS 5 on our
Win2000 servers, making that impossible.

Thanks a lot for your (and everybody else's) response, though. At
least I know I'm not going crazy :)

Dirk

[dd]

Hi

Just posting the resolution, should someone else have the same
problem.

The sites were running .Net 1.1.
They, however, were calling external DLLs which did not form part of
the original site.
These DLLs were picking up the 2.0 framework components.
To fix this:
Determined where the DLL is picking it's config up, i.e
AppDomain.CurrentDomain.GetData("APP_CONFIG_FILE") .ToString

And force the DLL to use the required framework by updating the
relevant config file as follows:

<configuration>
<startup>
<supportedRuntime version="v1.1.4322" />
<requiredRuntime version="v1.1.4322"/>
</startup>
</configuration>

Here's another link to an MSDN article about this:

http://msdn2.microsoft.com/en-us/library/9w519wzk.aspx

and a forum discussion with the resolution at the end:

http://forums.microsoft.com/MSDN/Sho...32380&SiteID=1

So, it was an version problem :), thanks to all who answered, hope
this helps someone in the future.