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
ConnectionString 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
ConnectionString 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(with 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.Config
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.Config 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.Config 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(with 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%\System32\inetsrv\appcmd add backup

2)Edit the applicationHost.config file
%windir%\System32\inetsrv\config\applicationHost.c onfig

applicationHost.config
<requestFiltering>
<fileExtensions allowUnlisted="true">
¡*
<add fileExtension=".config" allowed="false" />
¡*
</requestFiltering>

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%\System32\inetsrv\config\applicationHost.c onfig 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%\System32\inetsrv\appcmd add backup

2)Edit the applicationHost.config file
%windir%\System32\inetsrv\config\applicationHost.c onfig

applicationHost.config
<requestFiltering>
<fileExtensions allowUnlisted="true">
¡Â*
<add fileExtension=".config" allowed="false" />
¡Â*
</requestFiltering>

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

[Linda Liu [MSFT]]

Hi NormD,

Thank you for your feedback.

Since your application can read the exe.config file now when it is run on
Vista by double-clicked, you may have a try running it via a URL on Vista,
e.g. http://localhost/MyDir/MyApps/MyApp.exe, to see if it could read the
exe.config file.

Note that since IIS 7 blocks .config files by default, you need to edit the
applicationHost.config file
%windir%\System32\inetsrv\config\applicationHost.c onfig as follows:

applicationHost.config
<requestFiltering>
<fileExtensions allowUnlisted="true">
¡*
<add fileExtension=".config" allowed="true" />
¡*
</requestFiltering>

BTW, could you tell me what the "final mode" you'd like, i.e. place the
application and its exe.config file to Windows 2000 with IIS 5 and navigate
the website to launch the application on Windows Vista with IE 7, or place
the application and its exe.config file to Windows Vista with IIS 7 and
navigate the website to launch the application on the same machine(Vista
with IE 7)?

Sincerely,
Linda Liu
Microsoft Online Community Support

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

Linda,

I tried running the application via a URL again, before and after applying
the suggested changes to the applicationHost.config file, witht the same
result. It still does not read the exe.config file. I did a file search on
the pc to see if the exe.config file is event downloaded and found that is
the case. I found the file in: C:\Users\Administrator(or
UserName)\AppData\Local\Microsoft\Temporary Internet Files.

RE: "final mode". Typically our clients would run the app in the first
scenario, where the exe and exe.config file are sitting on a server and are
being accessed on another client pc. However the server doesn't always have
the same config (os and iis versions could differ).
Thanks

"Linda Liu [MSFT]" wrote:

Hi NormD,

Thank you for your feedback.

Since your application can read the exe.config file now when it is run on
Vista by double-clicked, you may have a try running it via a URL on Vista,
e.g. http://localhost/MyDir/MyApps/MyApp.exe, to see if it could read the
exe.config file.

Note that since IIS 7 blocks .config files by default, you need to edit the
applicationHost.config file
%windir%\System32\inetsrv\config\applicationHost.c onfig as follows:

applicationHost.config
<requestFiltering>
<fileExtensions allowUnlisted="true">
¡Â*
<add fileExtension=".config" allowed="true" />
¡Â*
</requestFiltering>

BTW, could you tell me what the "final mode" you'd like, i.e. place the
application and its exe.config file to Windows 2000 with IIS 5 and navigate
the website to launch the application on Windows Vista with IE 7, or place
the application and its exe.config file to Windows Vista with IIS 7 and
navigate the website to launch the application on the same machine(Vista
with IE 7)?

Sincerely,
Linda Liu
Microsoft Online Community Support

[Linda Liu [MSFT]]

Hi NormD,

Thank you for your reply.

I performed a test placing my test application and its exe.config file on
Windows XP machine with IIS 5 and navigating the web site on a Vista
machine installed IE 7.

The result is that I couldn't even launch the application via a URL on
Vista. The IE reports "Internet Explorer cannot display the webpage".

Could you launch the application via a URL on Vista? If so, how do you do
that?
Sincerely,
Linda Liu
Microsoft Online Community Support

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

Linda,

Yes, I can launch the application via URL on Vista, but it does not read the
associated exe.config file. That is the reason for the newsgroup post.

When I launched the windows application via a URL, I did not get the
"Internet Explorer cannot display the webpage" error. However, I did get that
same error when I tried to access the WebServices
(http://localhost/MyDir/MyWsv/MyWsv.asmx) directly in IE. I had to do the
following to resolve the errors:

1) World Wide Web Publishing Service: in Control Panel Administrative
Tools Services, set its Startup type to Automatic and Start it.

2) Ran WebService again & it gave me a different error "HTTP Error 403.3 -
Not Found", "The page you are requesting cannot e served because of the
Multipurpose Internet Mail Extension (MIME) map policy that is configured on
the Web Server. The page you requested has a file exetension that is not
recognized, and is not allowed".

Found MSDN article
(http://msdn2.microsoft.com/en-us/vstudio/bb188244.aspx) which pointed to
(http://www.iis.net/default.aspx?tabi...tabid=25&i=993)
Overview - There are 5 steps to installing ASP.NET v1.1 on IIS7:
2a) Ensure that "IIS Metabase Compatibility" is installed - NOTE: OK
2b) Install .NET Framework v1.1 and .NET Framework v1.1 SP1 - NOTE: Already
installed since we upgraded from XP to Vista
2c) Enable the ASP.NET v1.1 ISAPI Extension - NOTE: Ran
"%windir%\Microsoft.NET\Framework\v1.1.4322\aspnet _regiis -enable" command
2d) Add the IgnoreSection Handler to Framework v1.1 machine.config to
system.webServer - NOTE: Did not follow, since ours is not an Asp.NET
application
2e) Move your site or application to a Framework v1.1 application pool -
NOTE: Created new application pool called "DotNetFrame 1.1SP1POOL" for .NET
Framework 1.1. In IIS 7, changed WebServices's Application pool to the newly
created one.

3) Ran WebService again & it gave me another error "The page you are
requesting cannot be served because of the ISAPI and CGI Restriction list
settings on the Web server"
3a) Open the IIS Manager and navigate to the server level. In the Features
view, double-click ISAPI and CGI Restrictions to verify that the Web service
extension is set to Allowed. There I noticed that "ASP.NET v1.1.4322" was set
to Not Allowed. - NOTE: Changed it to Allowed.

4) Ran WebService again & it gave me yet another error: "An error occurred
during the processing of a configuration file required to service this
request. Please review the specific error details below and modify your
configuration file appropriately."
4a) Added the following, just before the </configSectionstag, to the
C:\Windows\Microsoft.NET\Framework\v1.1.4322\CONFI G\Machine.config file:
<section name="system.webServer"
type="System.Configuration.IgnoreSectionHandler, System, Version=1.0.5000.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089" />

Let me know if it helps.

"Linda Liu [MSFT]" wrote:

Hi NormD,

Thank you for your reply.

I performed a test placing my test application and its exe.config file on
Windows XP machine with IIS 5 and navigating the web site on a Vista
machine installed IE 7.

The result is that I couldn't even launch the application via a URL on
Vista. The IE reports "Internet Explorer cannot display the webpage".

Could you launch the application via a URL on Vista? If so, how do you do
that?
Sincerely,
Linda Liu
Microsoft Online Community Support

[Linda Liu [MSFT]]

Hi NormD,

Sorry for my delayed reply. I was perfoming tests on this problem for the
last two days.

Thank you for sharing your knowledge about how to trouble shoot the problem
of IE displaying "Internet Explorer cannot display the webpage" error. But
I'm afraid it doesn't help in my scenario, because it discusses how to
enable ASP.NET 1.1 on IIS 7.

In fact, the real reason that I couldn't visit any web site on XP with IIS
5 from Vista with IE 7 is that the Firewall located on the web server
blocks the requests from my Vista machine. After I change the settings of
the Firewall installed on the web server to enable Web Server(HTTP)
service, I could now visit the web sites from Vista.

I could now successfully launch the test application via a URL from my
Vista machine and the test application COULD access its exe.config on the
web server. I don't change any default setting on IIS 5.

Sorry that I didn't clarify in my previous replies that the IIS 7 installed
on the Vista machine has nothing to do with your problem, because you're
using IE to visit the web site on the web server. I mean that if we have
some problems when visiting web sites, the problem may has something to do
with the IIS installed on the web server, but absolutely has NOTHING to do
with the IIS installed on the client machine.

To summarize, IIS 5 doesn't block .config files and we could access .config
files directly using IE without changing any setting on IIS 5.

However, IIS 6 and later do block .config files. We could modify the
applicationHost.config file to unblock .config files.

If you still couldn't get your application to read its exe.config file when
you launch it via a URL from Vista with IE 7, you may have a try creating a
new folder for the application and its exe.config file on the web server to
see if it helps.

Sincerely,
Linda Liu
Microsoft Online Community Support

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

Hi Linda,

We are still stuck on this issue. Based on a suggestion you had previously
made we had already modified the applicationHost.config file to allow .CONFIG
files. I tried creating a new directory with the Application and exe.config
on the localhost and on the web server, but still no luck. Any other
suggestions?

Thanks.

"Linda Liu [MSFT]" wrote:

Hi NormD,

Sorry for my delayed reply. I was perfoming tests on this problem for the
last two days.

Thank you for sharing your knowledge about how to trouble shoot the problem
of IE displaying "Internet Explorer cannot display the webpage" error. But
I'm afraid it doesn't help in my scenario, because it discusses how to
enable ASP.NET 1.1 on IIS 7.

In fact, the real reason that I couldn't visit any web site on XP with IIS
5 from Vista with IE 7 is that the Firewall located on the web server
blocks the requests from my Vista machine. After I change the settings of
the Firewall installed on the web server to enable Web Server(HTTP)
service, I could now visit the web sites from Vista.

I could now successfully launch the test application via a URL from my
Vista machine and the test application COULD access its exe.config on the
web server. I don't change any default setting on IIS 5.

Sorry that I didn't clarify in my previous replies that the IIS 7 installed
on the Vista machine has nothing to do with your problem, because you're
using IE to visit the web site on the web server. I mean that if we have
some problems when visiting web sites, the problem may has something to do
with the IIS installed on the web server, but absolutely has NOTHING to do
with the IIS installed on the client machine.

To summarize, IIS 5 doesn't block .config files and we could access .config
files directly using IE without changing any setting on IIS 5.

However, IIS 6 and later do block .config files. We could modify the
applicationHost.config file to unblock .config files.

If you still couldn't get your application to read its exe.config file when
you launch it via a URL from Vista with IE 7, you may have a try creating a
new folder for the application and its exe.config file on the web server to
see if it helps.

Sincerely,
Linda Liu
Microsoft Online Community Support

[Linda Liu [MSFT]]

Hi NormD,

Thank you for your feedback.

Based on a suggestion you had previously made we had already modified

the applicationHost.config file to allow .CONFIG files.

If the web server is installed IIS 5, you needn't modify the
applicationHost.config file to allow .config files, because IIS 5 doesn't
block .config files at all.

I tried creating a new directory with the Application and exe.config on

the localhost and on the web server, but still no luck.

Could you tell me what the version of IIS is installed on the web server
and what the version of OS and IE are installed on the client?

If the client is installed Windows Vista, you may have a try running the IE
as administrator to see if it helps.

In addition, if you're using IIS 5 on the web server, you should ensure the
exe.config file on the web server is set to use a local path when connected
to.

To do this, open IIS manager and navigate to the virtual directory of the
application. In the right panel, right-click the exe.config file and choose
Properties. In the Properties page, switch to File tab and ensure the
option 'The designated file' is selected.
Sincerely,
Linda Liu
Microsoft Online Community Support

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

Linda,

Here are the configurations for the Web Server and the Client(localhost).

Web Server:
MS Windows 2000 SP4, IIS 5, IE 6

Client (also referred to as localhost):
Vista, IIS 7, IE 7

RE "exe.config file on the web server is set to use a local path" on IIS 5
--- this is true.

I want to clarify something again.

Scenario 1:

The application is installed on the Web Server. It is launched via a URL
from two different client machines. The first client has Vista (with IE 7 and
IIS 7). The second client has WinXP (with IE 6 and IIS 5). We're only having
trouble with the Vista machine; it does not read the app.exe.config file.

Scenario 2:

The application is installed on the Vista machine itself under the localhost
(:\Inetpub\wwwroot\...). It is launched via a URL from the same machine
(http://localhost/...). It does not read the app.exe.config file.

In both scenarios, it is the Vista machine that is not reading the
Exe.Config File. On the Vista machine, I modified the applicationHost.config
file to allow .config files. This should allow the application on the
localhost to run successfully, but it does not.

Thanks.

"Linda Liu [MSFT]" wrote:

Hi NormD,

Thank you for your feedback.

Based on a suggestion you had previously made we had already modified

the applicationHost.config file to allow .CONFIG files.

If the web server is installed IIS 5, you needn't modify the
applicationHost.config file to allow .config files, because IIS 5 doesn't
block .config files at all.

I tried creating a new directory with the Application and exe.config on

the localhost and on the web server, but still no luck.

Could you tell me what the version of IIS is installed on the web server
and what the version of OS and IE are installed on the client?

If the client is installed Windows Vista, you may have a try running the IE
as administrator to see if it helps.

In addition, if you're using IIS 5 on the web server, you should ensure the
exe.config file on the web server is set to use a local path when connected
to.

To do this, open IIS manager and navigate to the virtual directory of the
application. In the right panel, right-click the exe.config file and choose
Properties. In the Properties page, switch to File tab and ensure the
option 'The designated file' is selected.
Sincerely,
Linda Liu
Microsoft Online Community Support

[Linda Liu [MSFT]]

Hi NormD,

Thank you for your clarification.

For both of the two scenarioes you mentioned, I have all tested in my
tests.

When the application is placed on Windows XP machine with IIS 5 installed,
and I launch the application via a URL from a Vista machine, the
application runs properly and could read its exe.config from the Windows XP
machine.

When the application is placed on Windows Vista machine with IIS 7
installed, I modify the applicationHost.config file to allow .config files.
When I launch the application via a URL from the same machine, the
application runs properly and could read its exe.config from the local
machine.

Just a reminder, please ensure that the exe.config file is placed in the
same directory as the application on the web server.

In my test, the OS version of my Vista machine is Windows Vista Enterprise.
What's the OS version of your Vista machine? I suggest that you have a try
on another Vista machine to see if the problem still exists.

Sincerely,
Linda Liu
Microsoft Online Community Support