.Net COM interop initialization question...

Main Page | Report this Page

.NET DotNet Forum Index » ASP.NET Forum » .Net COM interop initialization question...

Page 1 of 1

.Net COM interop initialization question...

Author

Message

Mark...

Posted: Mon Oct 26, 2009 9:55 am

Guest

Hi...

I have a bit of an odd situation I'm trying to work around. Our code has a
bunch of ASP.Net code with several of the objects registered for COM interop.

Our websites also have an ISAPI filter that makes use of these COM interop
objects.

By default, in production, our app/objects read some configuration from the
registry.

My problem is that I'm trying to set up a box for shared development so
multiple people can RDP into a box and work - and these COM interop objects
are causing some headaches.

I tweaked our code so that the ASP.Net side can override the registry
settings with web.config changes and that works fine.

What doesn't currently work is that we only have 1 copy of the COM interop
objects registered at one time. Leaving aside the issue where user/website A
can be calling/using the COM interop object from user/website B's directory,
I've been trying to get user/website A's use of the COM interop objects
initialized with different values.

Here's what I tried:

1) I gave each user his own App Pool
2) I tweaked DllMain in the ISAPI filter to set the current working
directory to the website home
3) I created a w3wp.exe.config file with the setting overrides I wanted.

The hope was that even though I was running the code from a different path,
the COM interop objects for *my* w3wp.exe process would see w3wp.exe.config
and read settings from there.

Unfortunately it didn't work. When my website fired up and the ISAPI filter
fired up the com interop objects, they still got the configuration from the
shared registry settings.

Any idea where I went wrong in the above?

Thanks
Mark

Gregory A. Beamer...

Posted: Mon Oct 26, 2009 10:47 am

Guest

=?Utf-8?B?TWFyaw==?= <mmodrall at (no spam) nospam.nospam> wrote in
news:D5EF235D-43DB-4C0F-8DA9-33AF355E85A7 at (no spam) microsoft.com:

Quote:

Unfortunately it didn't work. When my website fired up and the ISAPI
filter fired up the com interop objects, they still got the
configuration from the shared registry settings.

Any idea where I went wrong in the above?

Think about how the IIS process works, I am not sure you can get around
this. The only way I can think of that might possible setting up a WCF UI
with a COM wrapper, but even then you could end up with a single instance
of the COM component (have to think this one through).

Perhaps setting up the COM component in COM+ might help overcome some of
the issues, but I am not 100% sure of that either.

is there a .NET equivalent you can code in for the future?

Peace and Grace,

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: at (no spam) gbworld
Blog: http://gregorybeamer.spaces.live.com

*******************************************
| Think outside the box! |
*******************************************

Mark...

Posted: Mon Oct 26, 2009 2:07 pm

Guest

Hi Greg...

Thanks for answering... I'm not sure what you're getting at with "Think
about how the IIS process works".

I found other articles (not related to IIS) that said .Net COM interop would
look for <image>.config files for settings in general. With IIS6, that
process would be w3wp.exe, hence w3wp.exe.config.

Of the points not covered in the articles I read were
1) Possibly when they said <image>.config, were they referring to the
registered dlls, not the instantiating process?

2) A managed program will look for and load its app.exe.config file from the
get-go; if the consumer of the COM objects is unmanaged, it wouldn't. Will
the COM interop do the looking for the config file? Perhaps that's what you
were alluding to?

I'll see if I can get a small test case thrown together...

Thanks
Mark

"Gregory A. Beamer" wrote:

Quote:

=?Utf-8?B?TWFyaw==?= <mmodrall at (no spam) nospam.nospam> wrote in
news:D5EF235D-43DB-4C0F-8DA9-33AF355E85A7 at (no spam) microsoft.com:

Unfortunately it didn't work. When my website fired up and the ISAPI
filter fired up the com interop objects, they still got the
configuration from the shared registry settings.

Any idea where I went wrong in the above?

Think about how the IIS process works, I am not sure you can get around
this. The only way I can think of that might possible setting up a WCF UI
with a COM wrapper, but even then you could end up with a single instance
of the COM component (have to think this one through).

Perhaps setting up the COM component in COM+ might help overcome some of
the issues, but I am not 100% sure of that either.

is there a .NET equivalent you can code in for the future?

Peace and Grace,

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: at (no spam) gbworld
Blog: http://gregorybeamer.spaces.live.com

*******************************************
| Think outside the box! |
*******************************************
.

Gregory A. Beamer...

Posted: Mon Oct 26, 2009 3:53 pm

Guest

=?Utf-8?B?TWFyaw==?= <mmodrall at (no spam) nospam.nospam> wrote in news:AD72DF21-3F40-
4B35-960A-38106366A6FB at (no spam) microsoft.com:

Quote:

Thanks for answering... I'm not sure what you're getting at with "Think
about how the IIS process works".

DISCLAIMER: Oversimplification in process

When you say ISAPI, do you mean something you wrote in C++ as an ISAPI
filter or do you mean a .NET HTTPhandler that calls COM components? I was
thinking the later when I started answering this thread and may be off
track. If so, apologies.

COM is a very complex subject, especially in regards to .NET.

When you cross the boundary from managed to unmanaged code, you open
yourself for errors. The standard .NET callable wrapper simply acts as a
proxy between the COM bits and the .NET bits, but this may not be enough,
especially if you have multiple applications hitting the same bits.

In newer versions of windows, there are some ways around the COM issue.
And, if the component is installed in COM+, you have other options. But the
person who programmed the COM component may have still boxed you in with
the way they set things up.

Since I don't know the actual component, I am shooting in the dark hoping
to hit a target. ;-)

IIS sits on top of COM+ (the MTS part primarily, where it has sat since IIS
4.0, at least I don't think earlier versions used MTS, but someone will
likely correct me if so). .NET sits on top of IIS. There is already a lot
of interop with the native components to get web processes finished, even
though some is going away as they retool .NET, the CLR, etc.

What I am attempting to do here is give you some places to look other than
a single document that is designed to solve a single problem. Even if the
problem sounds just like yours, the installation of the COM bits on the
server may null and void the solution.

As for COM: Depending on the component you are using, you may be completely
leaving the IIS/COM+ process to access the component. In these cases, it is
almost guaranteed to be a bottleneck.

if you don't mind me asking, what is the COM component in question?

Long term, I still think re-examining what the component does, and finding
a .NET option, is probably the wisest solution.

Peace and Grace,

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: at (no spam) gbworld
Blog: http://gregorybeamer.spaces.live.com

*******************************************
| Think outside the box! |
*******************************************

Mark...

Posted: Tue Oct 27, 2009 10:45 am

Guest

Quote:

=?Utf-8?B?TWFyaw==?= <mmodrall at (no spam) nospam.nospam> wrote in
news:E0A39783-9DB4-457F-BD03-FBCB2B4CD211 at (no spam) microsoft.com:

Maybe you're right - you can spend so much time trying to work around
the gorilla in the room that it may just be more profitable to tackle
some of the old problems.

Mark:

One possibility, although kludgy, would be to recompile the components with
different GUIDs, so they are seen differently. This will not eliminate all
problems, but could route each app to a different "component". Long term
maintenance would be a bear, however (a different gorilla?), so it would be
a stop gap measure only.

Peace and Grace,

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: at (no spam) gbworld
Blog: http://gregorybeamer.spaces.live.com

*******************************************
| Think outside the box! |
*******************************************
.

Mark...

Posted: Tue Oct 27, 2009 11:14 am

Guest

Ah well... I tried my next straw to grasp at - If I put a w3wp.exe.config in
inetsrv and had

<appSettings file="%MyPath%\My.config" />

in there, I might be able to get each web instance to set its own source.

Problem is that <appSettings file= doesn't appear to expand environment
variables...

Why are the easy solutions always so hard? :)

"Mark" wrote:

Quote:

Just as a general FYI, I found the flaw in my earlier reasoning...
ConfigurationManager doesn't care what your current working directory is - it
looks in the home directory of the .exe running. So if I moved my config
files to C:\windows\system32\inetsrv, the .net COM objects do see and process
the config.

Unfortunately putting things in inetsrv doesn't move me around my problem at
all...

Thanks
Mark

"Gregory A. Beamer" wrote:

=?Utf-8?B?TWFyaw==?= <mmodrall at (no spam) nospam.nospam> wrote in
news:E0A39783-9DB4-457F-BD03-FBCB2B4CD211 at (no spam) microsoft.com:

Maybe you're right - you can spend so much time trying to work around
the gorilla in the room that it may just be more profitable to tackle
some of the old problems.

Mark:

One possibility, although kludgy, would be to recompile the components with
different GUIDs, so they are seen differently. This will not eliminate all
problems, but could route each app to a different "component". Long term
maintenance would be a bear, however (a different gorilla?), so it would be
a stop gap measure only.

Peace and Grace,

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: at (no spam) gbworld
Blog: http://gregorybeamer.spaces.live.com

*******************************************
| Think outside the box! |
*******************************************
.

Mark...

Posted: Wed Oct 28, 2009 10:59 am

Guest

Okay, I think I found my loophole. Some are going to find this a gross hack,
but I think it'll work.

In the inetsrv directory, I have a w3wp.exe.config that looks like this:

<configuration>
<appSettings file="D:My.config"/>
</configuration>

Then I put all my web instances on drive D and have the isapi filter set the
current working directory to the website instance home.

The file attribute can expand relative paths *including* the
drive-current-working-directory.

This way you have multiple websites all going to their particular config...

Thanks
Mark

"Mark" wrote:

Quote:

Gregory A. Beamer...

Posted: Thu Oct 29, 2009 12:11 pm

Guest

=?Utf-8?B?TWFyaw==?= <mmodrall at (no spam) nospam.nospam> wrote in
news:0B46C168-757A-467B-B2E0-2BA10A73FCEB at (no spam) microsoft.com:

Quote:

Okay, I think I found my loophole. Some are going to find this a
gross hack, but I think it'll work.

In the inetsrv directory, I have a w3wp.exe.config that looks like
this:

configuration
appSettings file="D:My.config"/
/configuration

Then I put all my web instances on drive D and have the isapi filter
set the current working directory to the website instance home.

The file attribute can expand relative paths *including* the
drive-current-working-directory.

This way you have multiple websites all going to their particular
config...

Sounds like you may have found the kludge that works. I had to get
around networking security here today, so I understand the hacker
mentality. ;-)

I am going to play with this at some time, as it sounds interesting. Not
first on my list with the new VS 2010 bits.

Peace and Grace,

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: at (no spam) gbworld
Blog: http://gregorybeamer.spaces.live.com

*******************************************
| Think outside the box! |
*******************************************

Page 1 of 1

All times are GMT - 5 Hours The time now is Mon Dec 14, 2009 6:13 pm .NET DotNet Forum Index