Hi there!
The problem is likely caused by the fact that WG4 is sure it is in the root of the web site http://address:port/, but when you add proxy in the mix, you effectively change the location to the subfolder: http://externaldomain/
guide/. WG4, as other .NET applications, may generate URLs using '~/' prefix, because some reusable components on the page (like login control) may be placed on pages with different nesting level, so login control cannot use relative URL for redirection and has to use application-root-based URLs. If that's the case, then it is very possible that when you hit
http://mydomain.com/guide/, WG4, thinking it's in the web site root, generates redirect URL like this: /default.apx, which resolves as
http://mydomain.com/default.aspx instead of
http://mydomain.com/guide/default.aspx.
To verify this theory you may want to install
Fiddler http tracer on the client machine and see which URLs are being requested when 404 start to crop in.
If this theory is right, there are a couple of possible workarounds.
1. Instead of using port 80 and /Guide subfolder, configure your proxy to use the same port as the application itself so that the final root URL looks like
http://mydomain.com:YYYY/ instead of
http://mydomain.com/Guide/.
2. Try (results are not guaranteed) to register WG4 with UltiDev Cassini so that all the WG4 files are in the /Guide subfolder. For example, place all WG4 files in the c:\WG4\Guide folder, then create dummy web.config in the c:\WG4 folder, and register the WG4 application with UltiDev Cassini using physical folder c:\WG4 and default document being Guide/default.aspx. If this works, then both local and external URLs will have the same structure http://host/Guide/...
Please let us know if this has helped.
Best regards,
UltiDev Team.
Please donate at
http://www.ultidev.com/products/Donate.aspx to help us improve our products.