G
Guest
Short version:
IE7 and .NET Framework 2.0 breaks no touch deployment for .NET 1.1
applications. IE6 and .NET Framework 1.1 + 2.0 works fine. IE7 with .NET
Framework 1.1 only is fine, once we add .NET Framework 2.0, no touch
deployment does not work in a reliable manner.
See following table.
|.net 1.1 |.net 2.0(while keeping 1.1)
-----------------------------------------------
Ie6 |works |works
Ie7 |works |doesn’t work
Long version:
Since IE7 has been deployed in our organization, we’ve been having problems
with out .NET 1.1 applications that are deployed through no-touch deployment.
These applications have worked fine for more than 2 years.
Users use a desktop shortcut pointing to the .exe file :
http://deployserver.domain.com/notouch/app1/app1.exe
When they click their shortcuts, the behavior is seemingly random.
Sometimes everything works fine, some other times we see the IE7 window flash
by just like when the application is going to start but the nothing happens.
On other occasions, the IE7 window is stuck with “Connecting…†This happens
on several workstations, never with the same shortcut. Even on our
workstations, it’s not always the same shortcut. One can be broken for 2
days then suddenly starts working without any change from our part.
We tried to launch the applications from the command line using the
following syntax and we got similar results:
"C:\Program Files\Internet Explorer\iexplore.exe"
http://deployserver.domain.com/notouch/app1/app1.exe
We noticed that often, iexplore.exe gets stuck in the background when we
check in the task manager. But even after we get rid of those instances, the
problem persists. No amount of reboots help. It seems to never get to the
IEExec.exe step for the problematic shortcuts/URLs.
After a lot of tests (mostly by trial and error) we realized that once the
..NET framework 2.0 and Internet explorer 7 are installed, the problem
happens. We had been running IE6 and the .NET framework 1.1 + 2.0 for a
while and never had such problems. Keep in mind that we always kept .NET
Framework 1.1 on all computers used for testing.
The application does launch if we open up IE7, paste the URL into the
address bar and press enter. The same exact URL copied from the shortcut.
The problem goes away completely if we uninstall the .NET framework 2.0 (but
keep the 1.1) even if we keep IE7. But this is a solution we’d use as a last
resort as someone in the organization will sooner or later need the .NET
framework 2.0 for a commercial application. The problem comes back when we
re-install the .NET framework 2.0.
Our website is currently specified in the intranet zone of IE7. We tried
moving it to the trusted sites zone and the problem hasn’t gone away. We
lowered the security to the minimum setting.
We remade new shortcuts, disabled anti phishing, disabled the pop up blocker
and disabled manually all browser module/extensions/activex. We disabled the
windows firewall and completely uninstalled the anti-virus software. No
other extra software was installed on the test workstations.
We used a network sniffer to figure out what was going on.
We cleared the IE7 cache before each test. Windows firewall was disabled
When everything works, we can see the whole .exe getting downloaded. The
total size of the traffic between the workstation and the web server hosting
the application files is normal. We get a http response like this when the
..exe gets downloaded :
HTTP/1.1 200 OK Content-Length: 430080
The total size of the traffic captured is bigger than this content-length.
When the IE7 window flashes by and thing seem like they’re just going to
work but nothing happens we get to see that the total size of traffic between
the server and the workstation is smaller than what’s specified in
content-length even if we capture for over 4-5 minutes.
In the IIS logs we see only the first request from the client, which gets a
401 reply because the client never authenticates itself at the first try, it
usually retries with the window authentication and then gets the .exe. In
this case IIS seems to reply with the .exe but seems to not write in the log
incompleted requests.
When we get the IE7 window showing “Connecting…†absolutely nothing is
exchanged between the client and server. 0 packets.
All size totals specified were for packets exchanged between the workstation
and the deployment server only. All other traffic was ignored when we
measured the traffic size.
IE7 and .NET Framework 2.0 breaks no touch deployment for .NET 1.1
applications. IE6 and .NET Framework 1.1 + 2.0 works fine. IE7 with .NET
Framework 1.1 only is fine, once we add .NET Framework 2.0, no touch
deployment does not work in a reliable manner.
See following table.
|.net 1.1 |.net 2.0(while keeping 1.1)
-----------------------------------------------
Ie6 |works |works
Ie7 |works |doesn’t work
Long version:
Since IE7 has been deployed in our organization, we’ve been having problems
with out .NET 1.1 applications that are deployed through no-touch deployment.
These applications have worked fine for more than 2 years.
Users use a desktop shortcut pointing to the .exe file :
http://deployserver.domain.com/notouch/app1/app1.exe
When they click their shortcuts, the behavior is seemingly random.
Sometimes everything works fine, some other times we see the IE7 window flash
by just like when the application is going to start but the nothing happens.
On other occasions, the IE7 window is stuck with “Connecting…†This happens
on several workstations, never with the same shortcut. Even on our
workstations, it’s not always the same shortcut. One can be broken for 2
days then suddenly starts working without any change from our part.
We tried to launch the applications from the command line using the
following syntax and we got similar results:
"C:\Program Files\Internet Explorer\iexplore.exe"
http://deployserver.domain.com/notouch/app1/app1.exe
We noticed that often, iexplore.exe gets stuck in the background when we
check in the task manager. But even after we get rid of those instances, the
problem persists. No amount of reboots help. It seems to never get to the
IEExec.exe step for the problematic shortcuts/URLs.
After a lot of tests (mostly by trial and error) we realized that once the
..NET framework 2.0 and Internet explorer 7 are installed, the problem
happens. We had been running IE6 and the .NET framework 1.1 + 2.0 for a
while and never had such problems. Keep in mind that we always kept .NET
Framework 1.1 on all computers used for testing.
The application does launch if we open up IE7, paste the URL into the
address bar and press enter. The same exact URL copied from the shortcut.
The problem goes away completely if we uninstall the .NET framework 2.0 (but
keep the 1.1) even if we keep IE7. But this is a solution we’d use as a last
resort as someone in the organization will sooner or later need the .NET
framework 2.0 for a commercial application. The problem comes back when we
re-install the .NET framework 2.0.
Our website is currently specified in the intranet zone of IE7. We tried
moving it to the trusted sites zone and the problem hasn’t gone away. We
lowered the security to the minimum setting.
We remade new shortcuts, disabled anti phishing, disabled the pop up blocker
and disabled manually all browser module/extensions/activex. We disabled the
windows firewall and completely uninstalled the anti-virus software. No
other extra software was installed on the test workstations.
We used a network sniffer to figure out what was going on.
We cleared the IE7 cache before each test. Windows firewall was disabled
When everything works, we can see the whole .exe getting downloaded. The
total size of the traffic between the workstation and the web server hosting
the application files is normal. We get a http response like this when the
..exe gets downloaded :
HTTP/1.1 200 OK Content-Length: 430080
The total size of the traffic captured is bigger than this content-length.
When the IE7 window flashes by and thing seem like they’re just going to
work but nothing happens we get to see that the total size of traffic between
the server and the workstation is smaller than what’s specified in
content-length even if we capture for over 4-5 minutes.
In the IIS logs we see only the first request from the client, which gets a
401 reply because the client never authenticates itself at the first try, it
usually retries with the window authentication and then gets the .exe. In
this case IIS seems to reply with the .exe but seems to not write in the log
incompleted requests.
When we get the IE7 window showing “Connecting…†absolutely nothing is
exchanged between the client and server. 0 packets.
All size totals specified were for packets exchanged between the workstation
and the deployment server only. All other traffic was ignored when we
measured the traffic size.