Randall said:
In general, my problem is that right off the bat I run into security
obstacles. I mentioned one, the inability to use IIS on my laptop to
run an aspx page. Searching on the subject led me to suggestions
involving batch files running CACL commands. Not a single CACL call
I executed was successful. Sigh. The suggestion to add a new user
to machine.config failed because the server didn't recognize the
recommended username value. Other recommendations all involve
registry hacks, text file editing, etc etc etc-- all very crude
solutions IMO and not one tried has worked. So, specifically, I
still cannot execute aspx files on my development pc using IIS.
First of all, you don't need to run CACLS to run ASP.NET pages. What
problems were you having?
If you do have a need to run CACLS from a Web page, we have plenty of people
doing this and it will work. However, once again, you have to understand the
architecture. You must make sure that you do one of two things:
1. Either run the worker process under a privileged user who can run CACLS.
(Not recommended, Intranet or not.)
2. Impersonate a privileged user who can run CACLS.
Number 2 is the strong recommendation, and in this type of scenario, it
would be strongly advisable to use code-level impersonation.
I've already belabored the clipboard dilemma that has cost me
countless hours of deadend trial and error. I have a solution now
that works, but I'm still disgusted that there's no clean way to do
what I wanted and that I had to resort to a kludge that uses Word as
a table-copying engine. Which brings up another gripe: THAT solution
won't run from my server. The error is that Word can't be started. I
assume this means Word needs to be installed on the server (I had
assumed the interop would create the instance on the client machine--
oops). But I guarantee you the IT guys I have to deal with on this
will nix that. So now my solution is kaput. Back to square 1: I
still cannot copy a simple html table from a web page to a Powerpoint
application, a feature my application MUST have. That confounds and
astounds me.
Once again, this is an architectural issue. Office applications are not
designed to be run non-interactively. When they load up, they load up
user-specific settings from the profile. When you are running your ASP.NET
app, the worker process is running under the context of a non-interactive
user and automation of Office applications is not supported.
Even if you can get it to work, doing it would be highly inadvisable due to
resource problems that would likely be encountered. This is not an
architectural flaw. It simply has to do with the fact that Windows
applications are designed to be run by the one person logged into the
console and not by a large number of users accessing a Web application.
Sorry to beat this dead horse-- but I have a project upon which key
managers have pinned high expectations and it's frustrating to me to
hit so many walls over what I had presumed to be minor details. I
can create this app in VB6. I can even create it in vb.net winforms.
But for various reasons I prefer asp.net webforms. And I hate having
to call it quits, but it sure looks like I'll have to. A shame. I
was really excited at what I thought asp.net could do.
I don't think you have to call it quits. However, I do think (as I've said
before) that you need to do some work up-front in understanding the
achitecture you are using. Doing so will ease your frustration and will
allow you to create better and more robust applications.
--
Jim Cheshire
================================
Blog:
http://blogs.msdn.com/jamesche
Latest entry:
Getting the PID and TID of a COM Call
Describes how to get the PID of the
dllhost process a COM call is executing
in and how to locate the thread as well.