I understand that sometimes (more often than I'd like) the answer is just "you can't". If that's the case, then I'll have to deliver the bad news to the boss.

But I'm not quite ready to give up just yet if anybody else has a suggestion?

The only way that I can even remotely tihnk to accomplish this would be an AcitveX control that you could run over RDP in the clients browser. Just remember, at this point your user is no long a causal web browser they have a direct connection to your server, be careful not to open Pandoras Box.

-------------------------
I will only tell you how to do it, not do it for you.
Unless, of course, you want to hire me to do work for you.

^^Thats my signature

It's an application for internal use only, so the security concerns are few. But the process for gaining approval to install anything on the workstation is so daunting it's eaiser to say "it can't be done".

In addition to ensuring that installed components play well with EVERYTHING else on the machine, all gov't applications must be strictly compliant with section 508 of the Employees with Disabilities Act. That means that visually or mobility impaired government users must be able to use all applications any other gov't employee must use. Native web controls are barely accessible as it is (ever try navigating a web site without a monitor or mouse?) and user controls only add layers of complexity. So, I try to stick to native web controls whenever possible for this reason.

But thanks for the suggestion!

Enquiring minds may wish to know I was finally able to get this &^%$ thing to work as wished. The problems I was encountering were related to how links were coded, network security and how VS programs upload files.

First, I was unable to edit uploaded files that were stored in a folder below the VS application on the IIS server due to security on the application folder that was inherited to embedded folders. I could've opened the application folder up to modifications, but there are obvious security and integrity issues associated with doing that.

So, I moved the upload folder to another server and opened it to the world. I could then edit documents in place (although the links we discussed obviously had to be changed to reference the other server as well as the folder directly, rather than relatively as was suggested.) That meant it wasn't necessary to save edited documents to the local hard drive and upload them again, which is a tedious process for an alleged document management system.

BUT, moving the upload folder to another server caused other problems (and I hope MS is paying attention here, because this is what really frustrated us about this whole mess). While Windows authentication uses the user's network PIN to access files via links as you would expect (assuming anonymous users are not allowed, of course), the PostedFile.SaveAs method for input file tags appears to use IIS_User instead, which did not have rights to the upload folder. And the message returned is "Login or password failed" without mentioning which PIN was being used to perform the upload - about as useless as "Object undefined" when you don't know which object it means. WE were left to deduce that it was not using pass through authentication to referece the folder. Rather than giving IIS_USER rights to the folder, we relied on impersonation using the web.config file to use an internal service ID with the necessary permissions:

<system.web>
    <identity impersonate="true" userName="john smith" password="password" />
</system.web>

Users can now edit downloaded files from their location on the server using their native editor (documents in Word, spreadsheets in Excel, etc.) as we suspecteed should be possible, and then save them back using the SAVE option in the editor. Finding the right folder using the browser or downloading and then uploading again via the HTML input file object really is not required if the folder has proper security AND the application's user has the necessary rights.

Thanks again for everybody's help figuring this little anomaly out!