Registering DLL

[cfps.Christian]

I've got a nice little deadline here and have to deal with the dumbest
things possible to get it done. I had to create an application that
is spliced into another application via an event handler class. When
the original program sees the event handler is uses the handler's code
to execute my code (I code the handler as well). Anyway I've coded
all this and of course it works locally but I don't need it to work
locally I need it to work on another machine FROM a network share.

This gets better though...

The starting program (being spliced into) is on the user's machine and
I need to register the dll there and it refuses to with regasm,
regsvr32, or with the little program the manufacturer sent with.

I desperately need to register this dll so I can deal with what is
going to be the next problem of integrating the local event handler
with the networked program.

 

[Herfried K. Wagner [MVP]]

I've got a nice little deadline here and have to deal with the dumbest
things possible to get it done. I had to create an application that
is spliced into another application via an event handler class. When
the original program sees the event handler is uses the handler's code
to execute my code (I code the handler as well). Anyway I've coded
all this and of course it works locally but I don't need it to work
locally I need it to work on another machine FROM a network share.

This gets better though...

The starting program (being spliced into) is on the user's machine and
I need to register the dll there and it refuses to with regasm,
regsvr32, or with the little program the manufacturer sent with.

Typically .NET DLLs do not need to be registered at all. Without knowing
the application which should use the DLL, it's impossible to give an answer.

 

[Guest]

It sounds like a COM dll on a file share, so that conceptually should
register. What is the error? It sounds like a commercial product, so is it
a licensing error? If they sent a special registration code, then it would
seem that they had good reason for that code rather than regasm or regsvr32.
I hate to say it, but it sounds like you are at the manufacturers mercy.

 

[Michael C]

I've got a nice little deadline here and have to deal with the dumbest
things possible to get it done. I had to create an application that
is spliced into another application via an event handler class. When
the original program sees the event handler is uses the handler's code
to execute my code (I code the handler as well). Anyway I've coded
all this and of course it works locally but I don't need it to work
locally I need it to work on another machine FROM a network share.

Putting dlls or exes on a network share is a really bad idea. If you want
some way to update your app from a central location then write some sort of
automatic install.

Michael

 

[Cor Ligthert[MVP]]

cfps.

Dealing with running from network shares has always to do with a lot of work
with security settings (politics). I can not help you with an exact answer,
because I always try to avoid that.

Cor

 

[cfps.Christian]

It sounds like a COM dll on a file share, so that conceptually should
register. What is the error? It sounds like a commercial product, so is it
a licensing error? If they sent a special registration code, then it would
seem that they had good reason for that code rather than regasm or regsvr32.
I hate to say it, but it sounds like you are at the manufacturers mercy.

It is my understanding that it is supposed to be a COM file. When I
turn on Register for COM interop on the network share the project
refuses to build I'm guessing because I or the share doesn't have
rights to register with the server (which isn't a problem I don't want
it on there). I compiled the dll on my machine (because it registers
there) and transferred the dll to the machine that actually needs to
run the program and it doesn't register there.

As far as registering the dll I get an entry error or something of the
like. I'm very new to dll registration and network share programming
so doing all this is not very exciting to me, especially since they
want the project done pretty much today.

 

[cfps.Christian]

It is my understanding that it is supposed to be a COM file. When I
turn on Register for COM interop on the network share the project
refuses to build I'm guessing because I or the share doesn't have
rights to register with the server (which isn't a problem I don't want
it on there). I compiled the dll on my machine (because it registers
there) and transferred the dll to the machine that actually needs to
run the program and it doesn't register there.

As far as registering the dll I get an entry error or something of the
like. I'm very new to dll registration and network share programming
so doing all this is not very exciting to me, especially since they
want the project done pretty much today.

Could this be the difference between an app being developed on an 32
bit system going to a 64 bit system?

 

[Guest]

Hmmm....

I have just gotten a 64 bit machine at work and have run into some features
that I was not aware of as applications use the registry. Someone should
chime in more with the details, but what I saw was that there are two
partitions in the registry, separating storage of keys with 64 and 32 bit
apps.

Also, I had to set the build mode in VS to compile to x86 rather than Any OS
before an add-in dll that I was building would work in the 32 bit app on my
machine. Maybe this will be of some help....

 

[Guest]

Putting dlls or exes on a network share is a really bad idea. If you
want some way to update your app from a central location then write
some sort of automatic install.

If it's an intranet app, the OP could use ClickOnce for automatic updates.

 

[Guest]

Anyway I've coded
all this and of course it works locally but I don't need it to work
locally I need it to work on another machine FROM a network share.

Running from a network share has a different set of permissions
(Intranet).

Some features are not possible unless you change the default
permissions.

This gets better though...

The starting program (being spliced into) is on the user's machine and
I need to register the dll there and it refuses to with regasm,
regsvr32, or with the little program the manufacturer sent with.

What do you mean "spliced"?

I desperately need to register this dll so I can deal with what is
going to be the next problem of integrating the local event handler
with the networked program.

Very strange way of doing things - why are you storing the DLLs on a
network share?!

You should have used something like Remoting, WCF, or Web Services...
What you're doing is kind of wacky...

 

[cfps.Christian]

"cfps.Christian" wrote in
Running from a network share has a different set of permissions
(Intranet).

Some features are not possible unless you change the default
permissions.



What do you mean "spliced"?

The original program has a way of telling it a dll to use for events
and within that dll I can call my own code. For instance we want to
do our own search instead of using theirs so we have overriden their
search. I thought spliced was a good term for that.

Very strange way of doing things - why are you storing the DLLs on a
network share?!

They want the dll there so we have full access to edit it and in this
case I don't necessarily disagree since it has to be registered on
each machine. And its in reverse order for Click Once, my
understanding was that we would need a program that called a dll
rather than a dll that called a program.

You should have used something like Remoting, WCF, or Web Services...
What you're doing is kind of wacky...

I'm working at a shop that refuses to use .NET on the grounds that
they don't understand it, trust me I agree. I think our solution
should have been to install the entire program on the network and have
the users run off of that.

 

[Guest]

But your dll is .Net, right? That means they will need .Net. Am I missing
something?

 

[cfps.Christian]

But your dll is .Net, right? That means they will need .Net. Am I missing
something?

Yeah they have the .NET framework and currently they have VS.NET since
the only way I could get the dll to register properly was to rewrite
it and compile it on the user's machine (By rewrite I copied the code
into a new project and recompiled). When I compiled the dll elsewhere
I got tons of different errors in registration, my favorite was
LoadLib() saying it wasn't a valid dll.

 

[Guest]

They want the dll there so we have full access to edit it and in this
case I don't necessarily disagree since it has to be registered on
each machine. And its in reverse order for Click Once, my
understanding was that we would need a program that called a dll
rather than a dll that called a program.

So how is the DLL calling your application without the app loading it
first?

I'm a bit confused here...

 

[cfps.Christian]

"cfps.Christian" wrote in @19g2000hsx.googlegroups.com:



So how is the DLL calling your application without the app loading it
first?

I'm a bit confused here...

Wow, I'm confused now...

I'll try to do this slightly differently to hopefully clear up any
problems.

Purchased software goes on user computer
Purchased software calls a dll I create that in turns calls an
application I create
The dll and my application are supposed to be stored on a network
drive so the user can use it there (my order are no software installed
on user's machine)

My problem is that I can compile the code on my machine and get it
working just fine, but when the SAME code is on the network it refuses
to work and gives me all kinds of fun errors. I made a complete copy
of the code and moved it to the network drive in hopes of solving the
issues and I kept running into dependency issues with references that
got moved with the files. These issues were not "file not found" it
was more like "worked before now it doesn't" errors.

My hacked solution was to take the entire application (dll and all)
onto the user's computer and compile it using VS2005 there and
register the dll.

At one point I got regasm to return an error that LoadLib() returned:
%1 which means it wasn't a valid .NET dll which I knew it was.

I realize that none of this is probably the "best" way to do this but
its the way it has to be done thanks to the third party software I'm
using and my workplace restrictions.

 

[Guest]

Purchased software goes on user computer
Purchased software calls a dll I create that in turns calls an
application I create
The dll and my application are supposed to be stored on a network
drive so the user can use it there (my order are no software installed
on user's machine)

If the purchase software calls your DLL, can you use any transport
mechanism?

Since you're the one writing the DLL - can you use WCF/Remoting/Sockets etc
to talk to your application?

As for the calling application - if they run into any issues that's their
problem ;-)


You might be having issues because .NET enforces stricter security when
running files off a network drive. The issues you're seeing is probably due
to Code Access Security (CAS).

 

[Guest]

I agree with everybody else as what you are doing is pretty whacky. It's
asham that the shop you work for does not value your professional opinion on
how things should be done.

To address your issue, you might want to Google "Reg Free COM" or "Registry
Free COM". This technique will allow your COM callable wrappers to be used
without registering it. The down side to this is that it only works if the
client is Windows XP or above. If all your clients are WinXP, there
shouldn't be a problem.

 

[Michael C]

If it's an intranet app, the OP could use ClickOnce for automatic updates.

Yes, something like that is a much better solution. Even something that just
copies the files locally would be better

 

[cfps.Christian]

Yes, something like that is a much better solution. Even something that just
copies the files locally would be better

The problem I'm finding is that ClickOnce won't work for the dll and
thats the one that really needs moved since the dll is acting like a
program here. I tried to use ClickOnce but in the end I didn't need
my application to be mobile (it works fine on the server) but just the
dll.