Autodeployed Win App - Vista IIS 7.0

[=?Utf-8?B?Tm9ybUQ=?=]

I have created a three tier application consisting of Client (Exe and
Exe.Config), Middle (WebServices) and Database tiers. The Client tier
contains an Exe, an Exe.Config and a dynamic Web reference. The Exe reads a
key-value pair from the Exe.Config file, which is a link to the appropriate
WebService that it should connect to, and sets the dynamic Web reference’s
URL. If the Exe.Config file does not contain the key-value or if the
Exe.Config is not found, the dynamic Web reference tries to establish a
connection to the default WebService, as specified on the development
machine. The WebService has a Web.Config file which contains a
ConnectionStrin g pointing to the Database.

I have auto-deployed this application (the Client and Middle tiers) on a
Windows 2000 server with IIS 5. From my Windows XP machine (with IIS 5) I can
run this application just fine using a URL such as:
http://myServer/myApps/myApp.Exe. Also, it connects to the WebServices I’ve
setup in the Exe.Config file.

I upgraded another Windows XP machine (with IIS 5) to Vista with IIS 7.0.
When I run the application on this machine, using the same URL as above, it
attempts to connect to the default WebService (my development WebService).
It’s behaving as if it can’t find or can’t read the Exe.Config on the server.
Do I have to make any changes in IIS 7.0 to allow the application to read and
download Exe.Config files that are not local? Any suggestions?

Thanks in advance.

[=?Utf-8?B?Tm9ybUQ=?=]

I should add that the three tier Windows application was developed using
Visual Studio 2003 on .NET Framework 1.1 SP 1.

"NormD" wrote:

I have created a three tier application consisting of Client (Exe and
Exe.Config), Middle (WebServices) and Database tiers. The Client tier
contains an Exe, an Exe.Config and a dynamic Web reference. The Exe reads a
key-value pair from the Exe.Config file, which is a link to the appropriate
WebService that it should connect to, and sets the dynamic Web reference’s
URL. If the Exe.Config file does not contain the key-value or if the
Exe.Config is not found, the dynamic Web reference tries to establish a
connection to the default WebService, as specified on the development
machine. The WebService has a Web.Config file which contains a
ConnectionStrin g pointing to the Database.

I have auto-deployed this application (the Client and Middle tiers) on a
Windows 2000 server with IIS 5. From my Windows XP machine (with IIS 5) I can
run this application just fine using a URL such as:
http://myServer/myApps/myApp.Exe. Also, it connects to the WebServices I’ve
setup in the Exe.Config file.

I upgraded another Windows XP machine (with IIS 5) to Vista with IIS 7.0.
When I run the application on this machine, using the same URL as above, it
attempts to connect to the default WebService (my development WebService).
It’s behaving as if it can’t find or can’t read the Exe.Config on the server.
Do I have to make any changes in IIS 7.0 to allow the application to read and
download Exe.Config files that are not local? Any suggestions?

Thanks in advance.

[Linda Liu [MSFT]]

Hi NormD,

I performed serial tests based on your description and did see the problem
on my side.

When I place my test application(wit h a exe.config) on IIS 5, and then
launch the application with a URL, such as:

http://localhost/TestApp/TestApp.exe

the application could access the exe.config file on the web server.
However, when I place the application on IIS 6 or 7, and then lauch the
application with a URL, the application couldn't access the exe.config file
on the web server, so it uses the default value of the settings.

I use a tool called 'Fiddler' to watch the requests to & responses from the
IIS 7. I found that every time the application sumbits a request for the
exe.config to the IIS 7, the response from IIS 7 is always 403 'Forbidden'.
If I modify the URL to request the exe.config file directly, such as:

http://localhost/TestApp/TestApp.exe.config

The response is also 403 'Forbidden'.

It seems that IIS higher than 6.0 block the .config file by default,
because these files may contain sensitive information such as user names
and passwords.

I will go on the research about how to change this behavior on IIS 6 or 7,
and will get the result back to you ASAP.

I appreciate your patience!

Sincerely,
Linda Liu
Microsoft Online Community Support

=============== =============== =============== =====
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
=============== =============== =============== =====

This posting is provided "AS IS" with no warranties, and confers no rights.

[=?Utf-8?B?Tm9ybUQ=?=]

Linda,

I ran Fiddler on the Vista machine as well, while running the application
from the Web/app server and from localhost, and noticed some weirdness.
Fiddler didn't capture traffic for localhost (i.e.
http://localhost/MyDir/MyApps/MyApp.exe). However, it did capture traffic
when I ran the application from the server (i.e.
http://myServer/myApps/myApp.Exe).

I noticed that Fiddler did not capture the request for the myApp.Exe.Confi g
file on this machine, as it does on my XP machine. Furthermore, I checked the
IIS logs on the web/app server and noticed that the myApp.Exe.Confi g file was
requested, by application running on the Vista machine, and it probably was
returned (the logs contained a status code 200(=OK)). Contrary to what you
found, when I requested the myApp.Exe.Confi g file in internet explorer I did
receive the complete XML.

Also, to confirm what you found, running the application from localhost on
Vista did not use the Exe.Config file either.

Thanks.

"Linda Liu [MSFT]" wrote:

Hi NormD,

I performed serial tests based on your description and did see the problem
on my side.

When I place my test application(wit h a exe.config) on IIS 5, and then
launch the application with a URL, such as:

http://localhost/TestApp/TestApp.exe

the application could access the exe.config file on the web server.
However, when I place the application on IIS 6 or 7, and then lauch the
application with a URL, the application couldn't access the exe.config file
on the web server, so it uses the default value of the settings.

I use a tool called 'Fiddler' to watch the requests to & responses from the
IIS 7. I found that every time the application sumbits a request for the
exe.config to the IIS 7, the response from IIS 7 is always 403 'Forbidden'.
If I modify the URL to request the exe.config file directly, such as:

http://localhost/TestApp/TestApp.exe.config

The response is also 403 'Forbidden'.

It seems that IIS higher than 6.0 block the .config file by default,
because these files may contain sensitive information such as user names
and passwords.

I will go on the research about how to change this behavior on IIS 6 or 7,
and will get the result back to you ASAP.

I appreciate your patience!

Sincerely,
Linda Liu
Microsoft Online Community Support

=============== =============== =============== =====
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
=============== =============== =============== =====

This posting is provided "AS IS" with no warranties, and confers no rights.

[Linda Liu [MSFT]]

Hi NormD,

Thank you for your prompt response.

Sorry that I made a mistake in my first reply. The fact is that the Fiddler
couldn't capture traffic for localhost on my side too. Only when I use the
server name in the URL, it could capture traffic.

But it is true that I couldn't access the config file directly in IE.

As I mentioned in my first reply, IIS 6 or later block any request or
download of a .config file by default. If it wasn't the case, someone could
also download the web.config file of a server that may be containing some
sensitive information such as configuration keys in the app settings
sections or some database connections strings. So it is definitely a good
security protection that IIS blocks these file extensions from being
downloaded.

If you do want to do this globally(though I wouldn't recommend it) you can:

1)Make a bakup of your IIS Sesttings
%windir%\System 32\inetsrv\appc md add backup

2)Edit the applicationHost .config file
%windir%\System 32\inetsrv\conf ig\applicationH ost.config

applicationHost .config
<requestFilteri ng>
<fileExtensio ns allowUnlisted=" true">
¡*
<add fileExtension=" .config" allowed="false" />
¡*
</requestFilterin g>

Note that since Vista has more security protection policy, you need to run
Notepad as Administrator and then open the applicationHost .config file in
Notepad.

3) Switch to true: <add fileExtension=" .config" allowed="true" />

4) Save the file

And you should be ready to go.

For more information:
http://www.iis.net/default.aspx?tabi...abid=25&i=1040

Please try my suggestion and let me know the result.

If you have anything unclear, please feel free to let me know.
Sincerely,
Linda Liu
Microsoft Online Community Support

[=?Utf-8?B?Tm9ybUQ=?=]

Hi Linda,

My %windir%\System 32\inetsrv\conf ig\applicationH ost.config file did not
contain the default setting:

<add fileExtension=" .config" allowed="false" />

But, I went ahead and added the true/enable setting anyway:

<add fileExtension=" .config" allowed="true" />

However, I still couldn't run the application from the server or localhost.
I also tried restarting IIS, but to no avail.

One thing that was different was that Fiddler did capture the "exe.config "
file request, which was "returned" with a status of 200.

Thanks.

"Linda Liu [MSFT]" wrote:

Hi NormD,

Thank you for your prompt response.

Sorry that I made a mistake in my first reply. The fact is that the Fiddler
couldn't capture traffic for localhost on my side too. Only when I use the
server name in the URL, it could capture traffic.

But it is true that I couldn't access the config file directly in IE.

As I mentioned in my first reply, IIS 6 or later block any request or
download of a .config file by default. If it wasn't the case, someone could
also download the web.config file of a server that may be containing some
sensitive information such as configuration keys in the app settings
sections or some database connections strings. So it is definitely a good
security protection that IIS blocks these file extensions from being
downloaded.

If you do want to do this globally(though I wouldn't recommend it) you can:

1)Make a bakup of your IIS Sesttings
%windir%\System 32\inetsrv\appc md add backup

2)Edit the applicationHost .config file
%windir%\System 32\inetsrv\conf ig\applicationH ost.config

applicationHost .config
<requestFilteri ng>
<fileExtensio ns allowUnlisted=" true">
¡Â*
<add fileExtension=" .config" allowed="false" />
¡Â*
</requestFilterin g>

Note that since Vista has more security protection policy, you need to run
Notepad as Administrator and then open the applicationHost .config file in
Notepad.

3) Switch to true: <add fileExtension=" .config" allowed="true" />

4) Save the file

And you should be ready to go.

For more information:
http://www.iis.net/default.aspx?tabi...abid=25&i=1040

Please try my suggestion and let me know the result.

If you have anything unclear, please feel free to let me know.
Sincerely,
Linda Liu
Microsoft Online Community Support

[Linda Liu [MSFT]]

Hi NormD,

Thank you for your quickly feedback.

>However, I still couldn't run the application from the server or

localhost.

What do you mean in the above sentence? Do you mean you could NOT run the
application by launching it from IE using a URL, or the application can run
but couldn't access the exe.config file?

Just a confirmation that we're talking about the same scenario: what's the
versions of OS and IIS on the web server where you place your application
and exe.config file? In my test, I place the application and exe.config
file on Windows Vista with IIS 7. On the same machine, I launch the
application via a URL in IE.

If you run the application by double-clicking it, could it access the
exe.config file properly?

Sincerely,
Linda Liu
Microsoft Online Community Support

[=?Utf-8?B?Tm9ybUQ=?=]

Hi Linda,

Sorry about all the confusion.

RE: "...I still couldn't run the application..." -- I meant that the
application ran but still did not read the exe.config file.

Scenario 1:
The application and exe.config file are deployed on a Windows 2000 server
with IIS 5. It is run/accessed from two other machines via a URL such as
http://myServer/myApps/myApp.Exe. The first machine has Windows XP (with IIS
5) and the application works; it reads the exe.config file. The second
machine was upgraded from Windows XP (with IIS 5); so now it has Vista (with
IIS 7.0). This is the machine I'm having problems with.

Scenario 2:
The same application and exe.config exist on localhost on our development
machines; these are the same two machines described above. It is run/accessed
via a URL such as http://localhost/MyDir/MyApps/MyApp.exe. On the XP (with
IIS 5) machine, the application works; it reads the exe.config file. On the
Vista (with IIS 7.0) machine the application runs but does not read the
exe.config file.

Scenario 3:
The same application and exe.config exist on localhost on our development
machines. It is run/accessed by double-clicking on the MyApp.exe file. Again,
on the XP (with IIS 5) machine, the application works; it reads the
exe.config file. However on the Vista (with IIS 7.0) machine the application
runs but DOES NOT read the exe.config file.

Thanks

"Linda Liu [MSFT]" wrote:

Hi NormD,

Thank you for your quickly feedback.

However, I still couldn't run the application from the server or

localhost.

What do you mean in the above sentence? Do you mean you could NOT run the
application by launching it from IE using a URL, or the application can run
but couldn't access the exe.config file?

Just a confirmation that we're talking about the same scenario: what's the
versions of OS and IIS on the web server where you place your application
and exe.config file? In my test, I place the application and exe.config
file on Windows Vista with IIS 7. On the same machine, I launch the
application via a URL in IE.

If you run the application by double-clicking it, could it access the
exe.config file properly?

Sincerely,
Linda Liu
Microsoft Online Community Support

[Linda Liu [MSFT]]

Hi NormD,

Thank your for the detailed explanation.

It seems strange that when your application is run by double-clicked on
Vista, it couldn't read the exe.config file. I thought this may be related
to the security issue of Vista, because the application is copied from
somewhere else to the Vista machine.

I performed a test, i.e. develop an application on Windows 2003 and then
copy it and its exe.config file to another machine installed Vista. Then I
run the application on Vista by double-clicking it. However, the result
turns out that the application could read the exe.config file without any
problem.

You may have a try running the application on Vista as administrator to see
if it could read the exe.config file.

I think only if you application could read the exe.config file when it is
run by double-clicked, it is possible to make it read the exe.config file
when it is run via a URL.
Sincerely,
Linda Liu
Microsoft Online Community Support

[=?Utf-8?B?Tm9ybUQ=?=]

Linda,

As per your suggestion, I ran the application as an Administrator by double
clicking on it and it used the exe.config as its supposed to. I also tried
running it in non-Administrator mode, and again it used the exe.config file.

"Linda Liu [MSFT]" wrote:

Hi NormD,

Thank your for the detailed explanation.

It seems strange that when your application is run by double-clicked on
Vista, it couldn't read the exe.config file. I thought this may be related
to the security issue of Vista, because the application is copied from
somewhere else to the Vista machine.

I performed a test, i.e. develop an application on Windows 2003 and then
copy it and its exe.config file to another machine installed Vista. Then I
run the application on Vista by double-clicking it. However, the result
turns out that the application could read the exe.config file without any
problem.

You may have a try running the application on Vista as administrator to see
if it could read the exe.config file.

I think only if you application could read the exe.config file when it is
run by double-clicked, it is possible to make it read the exe.config file
when it is run via a URL.
Sincerely,
Linda Liu
Microsoft Online Community Support