Web Connection
Script map question
Gravatar is a globally recognized avatar based on your email address. Script map question
  Stein Goering
  All
  Jul 23, 2014 @ 10:53pm
Installing our app on a new system for a client running Server 2012. The app is installed in a virtual directory named wconnect, but we don't want to include that in the path when calling mapped pages so we configured the script maps at the root level of the default web site, something that's worked on dozens of other customer installations. We went through IIS Manager, which generated the following web.config in inetpub\wwwroot:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<handlers accessPolicy="Read, Execute, Script">
<add name="WCS" path="*.wcs" verb="*" modules="IsapiModule" scriptProcessor="C:\inetpub\wwwroot\WConnect\wc.dll" resourceType="Unspecified" preCondition="bitness32" />
<add name="WC" path="*.wc" verb="*" modules="IsapiModule" scriptProcessor="C:\inetpub\wwwroot\WConnect\wc.dll" resourceType="Unspecified" preCondition="bitness32" />
<add name="AWP" path="*.awp" verb="*" modules="IsapiModule" scriptProcessor="C:\inetpub\wwwroot\WConnect\wc.dll" resourceType="Unspecified" preCondition="bitness32" />
</handlers>
</system.webServer>
</configuration>

Despite this, we get a 404 error when trying to bring up a page with a mapped extension: http://cse-new.glendale.edu/ShowSchedule.awp

But it works if we include the virtual in the path: http://cse-new.glendale.edu/wconnect/ShowSchedule.awp

I could understand this behavior if we'd set up the mappings at the virtual level, but that was not the case. The virtual appears to be inheriting the mappings from the root, but those are not recognized at the root itself.

Any insights into what's going on here would be appreciated.

--stein


Gravatar is a globally recognized avatar based on your email address. Re: Script map question
  Stein Goering
  Stein Goering
  Jul 25, 2014 @ 09:21am
I assume that this reply to Serge's post was intended for mine...


That should work but make sure both virtuals are using the same App Pool and hte permissions are set properly on both. THe 404 may have nothing to do with the script map but the fact that the file doesn't exist (make sure that you uncheck file must exist flag)...
+++ Rick ---

We did clear the file must exist box - the App Pool could be the issue...

--stein



Installing our app on a new system for a client running Server 2012. The app is installed in a virtual directory named wconnect, but we don't want to include that in the path when calling mapped pages so we configured the script maps at the root level of the default web site, something that's worked on dozens of other customer installations. We went through IIS Manager, which generated the following web.config in inetpub\wwwroot:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<handlers accessPolicy="Read, Execute, Script">
<add name="WCS" path="*.wcs" verb="*" modules="IsapiModule" scriptProcessor="C:\inetpub\wwwroot\WConnect\wc.dll" resourceType="Unspecified" preCondition="bitness32" />
<add name="WC" path="*.wc" verb="*" modules="IsapiModule" scriptProcessor="C:\inetpub\wwwroot\WConnect\wc.dll" resourceType="Unspecified" preCondition="bitness32" />
<add name="AWP" path="*.awp" verb="*" modules="IsapiModule" scriptProcessor="C:\inetpub\wwwroot\WConnect\wc.dll" resourceType="Unspecified" preCondition="bitness32" />
</handlers>
</system.webServer>
</configuration>

Despite this, we get a 404 error when trying to bring up a page with a mapped extension: http://cse-new.glendale.edu/ShowSchedule.awp

But it works if we include the virtual in the path: http://cse-new.glendale.edu/wconnect/ShowSchedule.awp

I could understand this behavior if we'd set up the mappings at the virtual level, but that was not the case. The virtual appears to be inheriting the mappings from the root, but those are not recognized at the root itself.

Any insights into what's going on here would be appreciated.

--stein

Gravatar is a globally recognized avatar based on your email address. Re: Script map question
  Stein Goering
  Stein Goering
  Aug 4, 2014 @ 01:53pm
Just to complete the thread...

The issue was indeed that the web site root was pointing to the default application pool. Once we set it to use the West Wind pool, the mapped links worked from either location.

--stein


I assume that this reply to Serge's post was intended for mine...


That should work but make sure both virtuals are using the same App Pool and hte permissions are set properly on both. THe 404 may have nothing to do with the script map but the fact that the file doesn't exist (make sure that you uncheck file must exist flag)...
+++ Rick ---

We did clear the file must exist box - the App Pool could be the issue...

--stein



Installing our app on a new system for a client running Server 2012. The app is installed in a virtual directory named wconnect, but we don't want to include that in the path when calling mapped pages so we configured the script maps at the root level of the default web site, something that's worked on dozens of other customer installations. We went through IIS Manager, which generated the following web.config in inetpub\wwwroot:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<handlers accessPolicy="Read, Execute, Script">
<add name="WCS" path="*.wcs" verb="*" modules="IsapiModule" scriptProcessor="C:\inetpub\wwwroot\WConnect\wc.dll" resourceType="Unspecified" preCondition="bitness32" />
<add name="WC" path="*.wc" verb="*" modules="IsapiModule" scriptProcessor="C:\inetpub\wwwroot\WConnect\wc.dll" resourceType="Unspecified" preCondition="bitness32" />
<add name="AWP" path="*.awp" verb="*" modules="IsapiModule" scriptProcessor="C:\inetpub\wwwroot\WConnect\wc.dll" resourceType="Unspecified" preCondition="bitness32" />
</handlers>
</system.webServer>
</configuration>

Despite this, we get a 404 error when trying to bring up a page with a mapped extension: http://cse-new.glendale.edu/ShowSchedule.awp

But it works if we include the virtual in the path: http://cse-new.glendale.edu/wconnect/ShowSchedule.awp

I could understand this behavior if we'd set up the mappings at the virtual level, but that was not the case. The virtual appears to be inheriting the mappings from the root, but those are not recognized at the root itself.

Any insights into what's going on here would be appreciated.

--stein


Gravatar is a globally recognized avatar based on your email address. Re: Script map question
  Rick Strahl
  Stein Goering
  Aug 4, 2014 @ 02:00pm
Yup - you have to ensure if settings are inherited that you use the same AppPool. Actually if the two are in the same hierarchy I'd recommend to use a single application/virtual and consolidate the two as one. That way you are guaranteed there's only one configuration that applies at the virtual level. Further this also allows .NET modules to run and share multiple folders as a single application.

+++ Rick ---



Just to complete the thread...

The issue was indeed that the web site root was pointing to the default application pool. Once we set it to use the West Wind pool, the mapped links worked from either location.

--stein


I assume that this reply to Serge's post was intended for mine...


That should work but make sure both virtuals are using the same App Pool and hte permissions are set properly on both. THe 404 may have nothing to do with the script map but the fact that the file doesn't exist (make sure that you uncheck file must exist flag)...
+++ Rick ---

We did clear the file must exist box - the App Pool could be the issue...

--stein



Installing our app on a new system for a client running Server 2012. The app is installed in a virtual directory named wconnect, but we don't want to include that in the path when calling mapped pages so we configured the script maps at the root level of the default web site, something that's worked on dozens of other customer installations. We went through IIS Manager, which generated the following web.config in inetpub\wwwroot:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<handlers accessPolicy="Read, Execute, Script">
<add name="WCS" path="*.wcs" verb="*" modules="IsapiModule" scriptProcessor="C:\inetpub\wwwroot\WConnect\wc.dll" resourceType="Unspecified" preCondition="bitness32" />
<add name="WC" path="*.wc" verb="*" modules="IsapiModule" scriptProcessor="C:\inetpub\wwwroot\WConnect\wc.dll" resourceType="Unspecified" preCondition="bitness32" />
<add name="AWP" path="*.awp" verb="*" modules="IsapiModule" scriptProcessor="C:\inetpub\wwwroot\WConnect\wc.dll" resourceType="Unspecified" preCondition="bitness32" />
</handlers>
</system.webServer>
</configuration>

Despite this, we get a 404 error when trying to bring up a page with a mapped extension: http://cse-new.glendale.edu/ShowSchedule.awp

But it works if we include the virtual in the path: http://cse-new.glendale.edu/wconnect/ShowSchedule.awp

I could understand this behavior if we'd set up the mappings at the virtual level, but that was not the case. The virtual appears to be inheriting the mappings from the root, but those are not recognized at the root itself.

Any insights into what's going on here would be appreciated.

--stein





Rick Strahl
West Wind Technologies

Making waves on the Web
from Maui

© 1996-2024