By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
448,967 Members | 1,625 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 448,967 IT Pros & Developers. It's quick & easy.

Error installing DLL component in system32

P: n/a
Hi,

I am working on an installer application to install 2 COM components in
the system32 directory. I had this implemented previously to install
to a different directory (i.e. C:\sample\dll) and it worked fine. The
setup app seems to crash though when I changed the path to
C:\windows\system32. This is the error I receive...

System.Runtime.InteropServices.COMException (0x80110401) Errors
occurred accessing one or more objects

I am guessing its a configuration problem?

Any help would be appreciated.

Thanks!

Sep 15 '06 #1
Share this Question
Share on Google+
10 Replies


P: n/a
You shouldn't be installing COM components into system32.

Are these COM components .NET components that are registered to work
through interop? If so, install the assemblies in the GAC (they need to be
strong named) and then register those with COM interop.

Since COM components have visibility across the whole machine, it makes
sense that they go in the GAC. You also won't have location/lookup issues
either.

Hope this helps.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

<al******@gmail.comwrote in message
news:11**********************@b28g2000cwb.googlegr oups.com...
Hi,

I am working on an installer application to install 2 COM components in
the system32 directory. I had this implemented previously to install
to a different directory (i.e. C:\sample\dll) and it worked fine. The
setup app seems to crash though when I changed the path to
C:\windows\system32. This is the error I receive...

System.Runtime.InteropServices.COMException (0x80110401) Errors
occurred accessing one or more objects

I am guessing its a configuration problem?

Any help would be appreciated.

Thanks!

Sep 15 '06 #2

P: n/a
After a discussion with the architecture team this is what they decided
upon because the system path environment variable was too full on the
server and we couldn't add "C:\sample\dll" to it.

It doesn't come down to being my decision really...that the way it is
unfortunately.

And they don't want them to be installed in the GAC, I gotta stick to
the specs.

Nicholas Paldino [.NET/C# MVP] wrote:
You shouldn't be installing COM components into system32.

Are these COM components .NET components that are registered to work
through interop? If so, install the assemblies in the GAC (they need to be
strong named) and then register those with COM interop.

Since COM components have visibility across the whole machine, it makes
sense that they go in the GAC. You also won't have location/lookup issues
either.

Hope this helps.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

<al******@gmail.comwrote in message
news:11**********************@b28g2000cwb.googlegr oups.com...
Hi,

I am working on an installer application to install 2 COM components in
the system32 directory. I had this implemented previously to install
to a different directory (i.e. C:\sample\dll) and it worked fine. The
setup app seems to crash though when I changed the path to
C:\windows\system32. This is the error I receive...

System.Runtime.InteropServices.COMException (0x80110401) Errors
occurred accessing one or more objects

I am guessing its a configuration problem?

Any help would be appreciated.

Thanks!
Sep 15 '06 #3

P: n/a
I hate to tell you, but your specs are wrong.

If they knew anything about .NET, they would know that Fusion (the
assembly loader) does NOT look in System32 for dlls.

But hey, if that's what the spec says, who am I to argue?

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

<al******@gmail.comwrote in message
news:11*********************@p79g2000cwp.googlegro ups.com...
After a discussion with the architecture team this is what they decided
upon because the system path environment variable was too full on the
server and we couldn't add "C:\sample\dll" to it.

It doesn't come down to being my decision really...that the way it is
unfortunately.

And they don't want them to be installed in the GAC, I gotta stick to
the specs.

Nicholas Paldino [.NET/C# MVP] wrote:
>You shouldn't be installing COM components into system32.

Are these COM components .NET components that are registered to work
through interop? If so, install the assemblies in the GAC (they need to
be
strong named) and then register those with COM interop.

Since COM components have visibility across the whole machine, it
makes
sense that they go in the GAC. You also won't have location/lookup
issues
either.

Hope this helps.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

<al******@gmail.comwrote in message
news:11**********************@b28g2000cwb.googleg roups.com...
Hi,

I am working on an installer application to install 2 COM components in
the system32 directory. I had this implemented previously to install
to a different directory (i.e. C:\sample\dll) and it worked fine. The
setup app seems to crash though when I changed the path to
C:\windows\system32. This is the error I receive...

System.Runtime.InteropServices.COMException (0x80110401) Errors
occurred accessing one or more objects

I am guessing its a configuration problem?

Any help would be appreciated.

Thanks!

Sep 15 '06 #4

P: n/a
I don't get much room to argue here either....

So I guess you are saying there is no solution to my problem because
its all wrong? Must be a previliges issue....?
Nicholas Paldino [.NET/C# MVP] wrote:
I hate to tell you, but your specs are wrong.

If they knew anything about .NET, they would know that Fusion (the
assembly loader) does NOT look in System32 for dlls.

But hey, if that's what the spec says, who am I to argue?

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

<al******@gmail.comwrote in message
news:11*********************@p79g2000cwp.googlegro ups.com...
After a discussion with the architecture team this is what they decided
upon because the system path environment variable was too full on the
server and we couldn't add "C:\sample\dll" to it.

It doesn't come down to being my decision really...that the way it is
unfortunately.

And they don't want them to be installed in the GAC, I gotta stick to
the specs.

Nicholas Paldino [.NET/C# MVP] wrote:
You shouldn't be installing COM components into system32.

Are these COM components .NET components that are registered to work
through interop? If so, install the assemblies in the GAC (they need to
be
strong named) and then register those with COM interop.

Since COM components have visibility across the whole machine, it
makes
sense that they go in the GAC. You also won't have location/lookup
issues
either.

Hope this helps.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

<al******@gmail.comwrote in message
news:11**********************@b28g2000cwb.googlegr oups.com...
Hi,

I am working on an installer application to install 2 COM components in
the system32 directory. I had this implemented previously to install
to a different directory (i.e. C:\sample\dll) and it worked fine. The
setup app seems to crash though when I changed the path to
C:\windows\system32. This is the error I receive...

System.Runtime.InteropServices.COMException (0x80110401) Errors
occurred accessing one or more objects

I am guessing its a configuration problem?

Any help would be appreciated.

Thanks!
Sep 15 '06 #5

P: n/a
And to add what Nicholas said, if they knew anything about windows they
wouldn't even think about System32.
COM DLL's directory don't even need to be in the path environment. Native
COM components just like .NET assemblies registered as COM components, are
registered in the registry. .NET registered COM components don't need to
reside the GAC either, just register them using the regasm.exe /codebase
option and their location will be stored in the registry such that any COM
client is able to load them.

Willy.

<al******@gmail.comwrote in message
news:11*********************@p79g2000cwp.googlegro ups.com...
| After a discussion with the architecture team this is what they decided
| upon because the system path environment variable was too full on the
| server and we couldn't add "C:\sample\dll" to it.
|
| It doesn't come down to being my decision really...that the way it is
| unfortunately.
|
| And they don't want them to be installed in the GAC, I gotta stick to
| the specs.
|
| Nicholas Paldino [.NET/C# MVP] wrote:
| You shouldn't be installing COM components into system32.
| >
| Are these COM components .NET components that are registered to work
| through interop? If so, install the assemblies in the GAC (they need to
be
| strong named) and then register those with COM interop.
| >
| Since COM components have visibility across the whole machine, it
makes
| sense that they go in the GAC. You also won't have location/lookup
issues
| either.
| >
| Hope this helps.
| >
| --
| - Nicholas Paldino [.NET/C# MVP]
| - mv*@spam.guard.caspershouse.com
| >
| <al******@gmail.comwrote in message
| news:11**********************@b28g2000cwb.googlegr oups.com...
| Hi,
|
| I am working on an installer application to install 2 COM components
in
| the system32 directory. I had this implemented previously to install
| to a different directory (i.e. C:\sample\dll) and it worked fine. The
| setup app seems to crash though when I changed the path to
| C:\windows\system32. This is the error I receive...
|
| System.Runtime.InteropServices.COMException (0x80110401) Errors
| occurred accessing one or more objects
|
| I am guessing its a configuration problem?
|
| Any help would be appreciated.
|
| Thanks!
|
|
Sep 15 '06 #6

P: n/a
Forgive me if I didnt mention it....its a 3rd party C++ DLL

Do the same rules apply here?
Willy Denoyette [MVP] wrote:
And to add what Nicholas said, if they knew anything about windows they
wouldn't even think about System32.
COM DLL's directory don't even need to be in the path environment. Native
COM components just like .NET assemblies registered as COM components, are
registered in the registry. .NET registered COM components don't need to
reside the GAC either, just register them using the regasm.exe /codebase
option and their location will be stored in the registry such that any COM
client is able to load them.

Willy.

<al******@gmail.comwrote in message
news:11*********************@p79g2000cwp.googlegro ups.com...
| After a discussion with the architecture team this is what they decided
| upon because the system path environment variable was too full on the
| server and we couldn't add "C:\sample\dll" to it.
|
| It doesn't come down to being my decision really...that the way it is
| unfortunately.
|
| And they don't want them to be installed in the GAC, I gotta stick to
| the specs.
|
| Nicholas Paldino [.NET/C# MVP] wrote:
| You shouldn't be installing COM components into system32.
| >
| Are these COM components .NET components that are registered to work
| through interop? If so, install the assemblies in the GAC (they need to
be
| strong named) and then register those with COM interop.
| >
| Since COM components have visibility across the whole machine, it
makes
| sense that they go in the GAC. You also won't have location/lookup
issues
| either.
| >
| Hope this helps.
| >
| --
| - Nicholas Paldino [.NET/C# MVP]
| - mv*@spam.guard.caspershouse.com
| >
| <al******@gmail.comwrote in message
| news:11**********************@b28g2000cwb.googlegr oups.com...
| Hi,
|
| I am working on an installer application to install 2 COM components
in
| the system32 directory. I had this implemented previously to install
| to a different directory (i.e. C:\sample\dll) and it worked fine. The
| setup app seems to crash though when I changed the path to
| C:\windows\system32. This is the error I receive...
|
| System.Runtime.InteropServices.COMException (0x80110401) Errors
| occurred accessing one or more objects
|
| I am guessing its a configuration problem?
|
| Any help would be appreciated.
|
| Thanks!
|
|
Sep 15 '06 #7

P: n/a

<al******@gmail.comwrote in message
news:11*********************@m73g2000cwd.googlegro ups.com...
| Forgive me if I didnt mention it....its a 3rd party C++ DLL
|
| Do the same rules apply here?
|
|

Does it mean that the C++ DLL is not a COM DLL or what? Plain old DLL's
don't have to be registered, they have to be copied to a private install
folder(like x:\Program Files\SomeFolder) and this folder path should be in
the path environmant variable or their location must be stored in a
configuration file, all depends on the applications using (depending) on the
DLL and the way they load the DLL(s).

Willy.

Sep 15 '06 #8

P: n/a
That's the way I originally had it (private install directory), and it
was working....the DLLs were going to some folder and I was adding the
folder to the path environment variable. However, as already
mentioned, this is not possible on the server which is why this
approach was chosen.

Now I found out that you can add a System Folder to the installation
project, but the components would still need to be added to the COM+
component services catalog under my application name (i.e.
SampleApp/Components/myDll) with...

objCatalog.InstallComponent(bstrAppIDOrName, dll, "", "");

this is the line that was throwing the error in the first place

Willy Denoyette [MVP] wrote:
<al******@gmail.comwrote in message
news:11*********************@m73g2000cwd.googlegro ups.com...
| Forgive me if I didnt mention it....its a 3rd party C++ DLL
|
| Do the same rules apply here?
|
|

Does it mean that the C++ DLL is not a COM DLL or what? Plain old DLL's
don't have to be registered, they have to be copied to a private install
folder(like x:\Program Files\SomeFolder) and this folder path should be in
the path environmant variable or their location must be stored in a
configuration file, all depends on the applications using (depending) on the
DLL and the way they load the DLL(s).

Willy.
Sep 15 '06 #9

P: n/a

<al******@gmail.comwrote in message
news:11*********************@h48g2000cwc.googlegro ups.com...
| That's the way I originally had it (private install directory), and it
| was working....the DLLs were going to some folder and I was adding the
| folder to the path environment variable. However, as already
| mentioned, this is not possible on the server which is why this
| approach was chosen.
|
| Now I found out that you can add a System Folder to the installation
| project, but the components would still need to be added to the COM+
| component services catalog under my application name (i.e.
| SampleApp/Components/myDll) with...
|
| objCatalog.InstallComponent(bstrAppIDOrName, dll, "", "");
|
| this is the line that was throwing the error in the first place
Ok, the DLL contains native code COM+ components, that explains the COM
exception (0x80110401). Just like COM objects, COM+ DLL's don't have to be
in the path. They are registered in the COM+ catalog (registry) using the
ComCatalog API's, sure the registration utility has to find the DLL(s),
therefore you can hardcode the path like this:

string serverPath = "c:\MyPrograms\Components\MyServer.dll"
objCatalog.InstallComponent(bstrAppIDOrName, serverPath, "", "");
Willy.



Sep 15 '06 #10

P: n/a
Thanks for the input guys...I'm no COM expert, I was just asked if I
could do this because I was available.

This is what was causing my error.....the setup project was configured
to dump the DLLs into c:\someFolder\DLL and I was trying to register
those COM+ components by looking in the system folder...hence the
exception.

Once I reconfigured the setup application to dump the DLLs to the
system folder, all was fine.

Cheers!
Willy Denoyette [MVP] wrote:
<al******@gmail.comwrote in message
news:11*********************@h48g2000cwc.googlegro ups.com...
| That's the way I originally had it (private install directory), and it
| was working....the DLLs were going to some folder and I was adding the
| folder to the path environment variable. However, as already
| mentioned, this is not possible on the server which is why this
| approach was chosen.
|
| Now I found out that you can add a System Folder to the installation
| project, but the components would still need to be added to the COM+
| component services catalog under my application name (i.e.
| SampleApp/Components/myDll) with...
|
| objCatalog.InstallComponent(bstrAppIDOrName, dll, "", "");
|
| this is the line that was throwing the error in the first place
Ok, the DLL contains native code COM+ components, that explains the COM
exception (0x80110401). Just like COM objects, COM+ DLL's don't have to be
in the path. They are registered in the COM+ catalog (registry) using the
ComCatalog API's, sure the registration utility has to find the DLL(s),
therefore you can hardcode the path like this:

string serverPath = "c:\MyPrograms\Components\MyServer.dll"
objCatalog.InstallComponent(bstrAppIDOrName, serverPath, "", "");
Willy.
Sep 20 '06 #11

This discussion thread is closed

Replies have been disabled for this discussion.