Found solution

The last permission I needed to set was Local Activation for the ASPNET user.
Then I could run Excel from my app.

So to review, for other readers, the steps I went through were:

- run dcomcnfg.exe
From within dcomcnfg (it's titled "Component Services" in the title bar):
- Select "Component Services"
- Expand "Computers", and "My Computer" under it
- Select "DCOM Config" (listed under "My Computer")
- Find "Microsoft Excel Application", right-click on it and
bring up "Properties"
- Select the "Security" tab
- Under "Launch and Activation Permissions" select
"Customize"
- hit the "Edit" button in "Launch and Activation
Permissions"
- Add user "ASPNET" to the list of users who have this
permission
- Select the ASPNET user in the list, and then select
"Local Launch"
and "Local Activation" in the "Allow" column in the
list box below,
then hit OK.
- Under "Access Permissions" select "Customize"
- Hit the "Edit" button in "Access Permissions"
- Add user "ASPNET" to the user list
- Select the ASPNET user, then select "Local Access" in
the "Allow"
column in the list box below, then hit OK.
- Hit OK in the Properties dialog

Also, I have had to deal with the problem of the Excel process not exiting
when I'm done with it. I followed the advice of someone who posted at
http://www.tech-archive.net/Archive/DotNet/microsoft.public.dotnet.framework.interop/2004-02/0351.html (thanks Elsa for the link!).

Basically what I did was I called app.Workbooks.Close(), called Quit() on
the application component, and made sure I set any class-level references to
Excel components to Nothing, then called GC.Collect(). This last step is
normally not advisable for ASP.Net apps. as it suspends all threads while the
garbage collector runs, so it will degrade performance, but I found it did
the trick. I don't think the Excel functionality for the app. I'm developing
will be used that often, so I don't consider it a big minus.

The reason this may have been necessary is that I had some lines of code
that went like this:

Dim rng As Excel.Range = ws(index).Range(startLoc)
Dim name As String = CStr(rng.Offset(index1, index2).Value)

>From what I understand, calls to Range() and such create instances of COM
objects. Eventually all of my range references went out of scope. So
setting them to Nothing would've been redundant. Lines like the above call
to Offset() create temporary .Net objects, which would need to be garbage
collected before the COM objects they might reference are completely
destroyed. The alternative I guess would've been to call ReleaseComObject()
but I have a hard time knowing what call creates a COM object and what
doesn't.

In any case, only when all of the COM objects in the application are shut
down does Excel finally exit.

---Mark

"Mark Miller" wrote:

> Thanks for this information. I had Microsoft Excel Application set to Local
> Launch and Local Access for the ASPNet user, though I just noticed that Local
> Activation was not checked. Are the local permissions what I need? There
> are also "remote" permissions. Maybe I should be setting remote access for
> ASPNet instead?
>
> Re: Interop w/ Excel is not supported or recommended and generally doesn't
> work
>
> I agree dealing with Excel is a challenge. My customer has been using Excel
> workbooks for data entry, and they want to continue doing so. Personally I
> wouldn't have designed it this way, but this was their decision. I know that
> Excel has been accessed through COM interop. even going back to the ASP 6
> days, so apparently a lot of people have been doing it this way, despite it
> not being supported. When we first started on this project I suggested using
> DTS w/ Excel, however I got talked out of it by someone who's used DTS longer
> than I have, saying that using DTS with Excel was glitchy. So using Excel
> through COM interop. seemed to be the better route.
>
> What strategy would you recommend for dealing with Excel spreadsheets on the
> server side in the future?
>
> ---Mark
>
>
> "Willy Denoyette [MVP]" wrote:
>
> >
> > "Mark Miller" <MarkMiller@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
> > news:0ED5361D-C65B-403E-BD1C-ACE147B3A7B6@xxxxxxxxxxxxxxxx
> > > I'm trying to run Excel on the server side, uploading an Excel file to the
> > > server and having it processed there.
> > >
> > > I've read elsewhere about how to configure security for this, but I'm
> > > unclear on all I need to do.
> > >
> > > The advice I've read is to use dcomcnfg.exe to grant access and execute
> > > rights to the ASPNET user for Microsoft Excel Application. I've done
> > > this,
> > > but when I run my ASP.Net app., I still get the same error: "Unable to
> > > create
> > > ActiveX control".
> > >
> > > What I'm unclear about is, I've heard I need to do something in the
> > > Identity
> > > tab of the properties, but I'm not sure what. There are a few selections:
> > >
> > > - The interactive user
> > > - The launching user
> > > - This user (followed by textboxes for userID and password)
> > >
> > > I've tried selecting "This user" and entering the ASPNET ID, but dcomcnfg
> > > apparently thinks the ASPNET ID has an associated password. I don't know
> > > what it is. I've tried the other settings "The interactive user" and "The
> > > launching user", but I get the same result.
> > >
> > > I need a little more help here.
> > >
> > > Thanks,
> > >
> > > ---Mark
> > >
> >
> > No, it's the security tab you have to select and gran launch and access
> > permissions to aspnet.
> >
> > Willy.
> > Note that using Office server side is not supported and in general doesn't
> > work at all.
> >
> >
> >
.