I'm having the exact same problem, and I don't have the luxury to re-use the
primary Excel session. Has anyone found a solution for this?

Thanks!
/Fredrik

"Andrew Wiles" wrote:

Mark

Thanks for the links, I had come accross a coupl of these in my initial
searches. These links seem primarily to deal with xll add-ins. What I have is
a dll. To be more precise about the behaviour I am seeing the add-in is
recognised in the COMAddins collection of the Excel application but it does
not appear that the udfs have been loaded.

I have actually solved my problem by taking a different approach in which I
re-use the primary Excel session that the user launched from the desktop
rather than creating new instances but I would still be interested in finding
out why the udf's are not available.



"Mark Ivey" wrote:

Take a look at these sites:

http://www.xtremevbtalk.com/archive/.../t-153129.html

http://support.microsoft.com/default...b;en-us;270844
http://support.microsoft.com/default...b;en-us;213489
http://support.microsoft.com/default...b;en-us;108888

Mark Ivey

"Andrew Wiles" wrote in message
...
I am attempting to automate a process that creates a series of workbooks
each
with a different subset of data populated. The basic process is running
fine
however I have a number of user defined functions (UDF's) implemented via
an
automation add-in. If I load my newly created workbooks programatically
using

Excel._Application excelApp = new
Microsoft.Office.Interop.Excel.Application();
Excel.Workbook doc = excelApp.Workbooks.Open(myFile, missing, missing,
missing, missing, missing, missing, missing, missing, missing, missing,
missing, missing,missing, missing);

My udf's are not recognized and return #NAME?

When I open the workbooks in a normal Excel session launched from the
start
menu they behave correctly.

It would appear that I need to do something to force the automation dll to
load in this scenario?

Any help would be appreciated.

Regards

Andrew Wiles