VB2005 registering a dll

[Galen Somerville]

I have an app using a VB6 ActiveX.dll which I also have made as an exe. Both
the dll and exe have exactly the same code and start in Sub Main. There is
no form involved.

I start this activex as a Process like so:

Dim NewProcess As Process = New Process

Then I use one of these:

Process.Start(" D:\Test\VB6\dll \MyProg.dll", CStr(Arg1) & " " &
CStr(Arg2))

Process.Start(" D:\Test\VB6\MyP rog.exe", CStr(Arg1) & " " & CStr(Arg2))

If I start the exe version all goes well. But if I start the dll version a
MsgBox pops up (and screws up the timing) with this message

"Dll RegisterServer in D:\Test\VB6\dll \MyProg.dll succeeded"

Ive tried putting the MyProg.dll in System32 folder and the VB2005 app's Bin
folder. Of course I unregister all other appearances.

The message pops up every time I run the app not just the first time.

Help !!!!

Galen

[Walter Wang [MSFT]]

Hi Galen,

I'm not sure if I fully understand your question. So please feel free to
correct me if I missed anything.

The Process.Start by default uses
ShellExecuteEx(http://msdn2.microsoft.com/en-us/library/ms647733.aspx) to
start the file. For an EXE file, the EXE gets executed directly. For a DLL
file, the default verb
(http://msdn.microsoft.com/library/en...l/programmersg
uide/shell_basics/shell_basics_ex tending/fileassociation s/fa_verbs.asp?fr ame
=true) is used to execute file. In your case, I guess some COM register
tool is associated with the DLL file and it's executed with your DLL and
other parameters passed to it as command line. In this case, the tool
reports that your DLL is registered successfully.

To register your DLL, you can use regsvr32.exe in your system32 directory:

Dim NewProcess As Process = Process.Start(" regsvr32.exe", "/s
d:\Test\VB6\MyP rog.exe " & CStr(Arg1) & " " & CStr(Arg2))
To know whether the registration is successful or not, wait it to exit and
read its ExitCode:

NewProcess.Wait ForExit()
if NewProcess.Exit Code = 0 then
Console.WriteLi ne("Registratio n successful")
else
Console.WriteLi ne("Registratio n failed")
end if
Hope this helps.
Sincerely,
Walter Wang (wa****@online. microsoft.com, remove 'online.')
Microsoft Online Community Support

=============== =============== =============== =====
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications. If you are using Outlook Express, please make sure you clear the
check box "Tools/Options/Read: Get 300 headers at a time" to see your reply
promptly.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
=============== =============== =============== =====

This posting is provided "AS IS" with no warranties, and confers no rights.

[Herfried K. Wagner [MVP]]

"Galen Somerville" <ga***@communit y.nospamschrieb :

>I have an app using a VB6 ActiveX.dll which I also have made as an exe.
Both the dll and exe have exactly the same code and start in Sub Main.
There is no form involved.

I start this activex as a Process like so:

Dim NewProcess As Process = New Process

Then I use one of these:

Process.Start(" D:\Test\VB6\dll \MyProg.dll", CStr(Arg1) & " " &
CStr(Arg2))

Process.Start(" D:\Test\VB6\MyP rog.exe", CStr(Arg1) & " " & CStr(Arg2))

If I start the exe version all goes well. But if I start the dll version a
MsgBox pops up (and screws up the timing) with this message

"Dll RegisterServer in D:\Test\VB6\dll \MyProg.dll succeeded"

DLLs cannot be started directly except maybe using "rundll.exe ". However,
just start your executable file that uses the DLL file. This will work if
the DLL has been registered properly, which can be archieved using
"regsvr32.e xe" for use with VB6 and "regasm.exe " for use within .NET-based
applications.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

[Galen Somerville]

"Herfried K. Wagner [MVP]" <hi************ ***@gmx.atwrote in message
news:eF******** *****@TK2MSFTNG P04.phx.gbl...

"Galen Somerville" <ga***@communit y.nospamschrieb :

>>I have an app using a VB6 ActiveX.dll which I also have made as an exe.
Both the dll and exe have exactly the same code and start in Sub Main.
There is no form involved.

I start this activex as a Process like so:

Dim NewProcess As Process = New Process

Then I use one of these:

Process.Start(" D:\Test\VB6\dll \MyProg.dll", CStr(Arg1) & " " &
CStr(Arg2))

Process.Start(" D:\Test\VB6\MyP rog.exe", CStr(Arg1) & " " & CStr(Arg2))

If I start the exe version all goes well. But if I start the dll version
a MsgBox pops up (and screws up the timing) with this message

"Dll RegisterServer in D:\Test\VB6\dll \MyProg.dll succeeded"

DLLs cannot be started directly except maybe using "rundll.exe ". However,
just start your executable file that uses the DLL file. This will work if
the DLL has been registered properly, which can be archieved using
"regsvr32.e xe" for use with VB6 and "regasm.exe " for use within .NET-based
applications.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

Thanks for the replies Herfried and Walter.

By it's very nature the dll is registered when it's created. If I move it I
use Regsvr32 to register it. Just made me curious.

Using either the dll or the exe doesn't solve my real problem. As Walter
knows, this process makes a USB device call based on COM for speed. The
VB2005 app uses a referenced VB6 dll which contains all of the USB
interfacing code.

This works fine but the USB responses are very slow. Too slow to capture
real time data. So the one USB call that needs to be fast is in this Process
running in it's own COM thread. The problem is that the USB call returns a
status of "Device not found". A Jungo monitoring program shows no activity
on the USB connection when this takes place.

Since one of the USB setup parameters is the Main form hWdw (or whatever)
the problem may be that the separate Process is not under that hWdw. To get
help from Jungo is a problem as I let my subscription lapse ($1000+).

Galen

[Walter Wang [MSFT]]

Hi Galen,

When a COM component is registered in registry, a full path to it is saved.
If you move it around, you need to register it again to update the path to
it.

Regards,
Walter Wang (wa****@online. microsoft.com, remove 'online.')
Microsoft Online Community Support

=============== =============== =============== =====
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
=============== =============== =============== =====

This posting is provided "AS IS" with no warranties, and confers no rights.

[Galen Somerville]

However every time I run the program I get the same message. Even within the
same run, when I call for a different file to be processed, I get the same
message.

Again, this is with the ActiveX dll. I will look in RegEdit before, after
and during a run to see what changes.

Galen

"Walter Wang [MSFT]" <wa****@online. microsoft.comwr ote in message
news:RJ******** ******@TK2MSFTN GHUB02.phx.gbl. ..

Hi Galen,

When a COM component is registered in registry, a full path to it is
saved.
If you move it around, you need to register it again to update the path to
it.

Regards,
Walter Wang (wa****@online. microsoft.com, remove 'online.')
Microsoft Online Community Support

=============== =============== =============== =====
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
=============== =============== =============== =====

This posting is provided "AS IS" with no warranties, and confers no
rights.

[Walter Wang [MSFT]]

Hi Galen,

Do you mean the message that prompts you that the dll is registered? If
this is the case, you can use "/s" switch to "regsvr32.e xe" to let it
register the COM dll silently.
Regards,
Walter Wang (wa****@online. microsoft.com, remove 'online.')
Microsoft Online Community Support

=============== =============== =============== =====
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
=============== =============== =============== =====

This posting is provided "AS IS" with no warranties, and confers no rights.

[Branco Medeiros]

Galen Somerville wrote:

I have an app using a VB6 ActiveX.dll which I also have made as an exe. Both
the dll and exe have exactly the same code and start in Sub Main. There is
no form involved.

I start this activex as a Process like so:

Dim NewProcess As Process = New Process

Then I use one of these:

Process.Start(" D:\Test\VB6\dll \MyProg.dll", CStr(Arg1) & " " &
CStr(Arg2))

Process.Start(" D:\Test\VB6\MyP rog.exe", CStr(Arg1) & " " & CStr(Arg2))

If I start the exe version all goes well. But if I start the dll version a
MsgBox pops up (and screws up the timing) with this message

"Dll RegisterServer in D:\Test\VB6\dll \MyProg.dll succeeded"

<snip>

As others pointed out, you can't "execute" a dll. A dll is a just
library of functions (or classes, in the case of COM dlls). The fact
that you had a Sub Main somewhere in code when you compiled your VB6
project into a dll doesn't change the dll's nature: the Sub Main is
just ignored (for executing purposes.It is used for the dll
initialization, if I remember correctly).

As you may know, Process.Start is used to directly run executables as
well as to launch the appropriate application related to a given file
type. If you call, for instance, Process.Start(" Sometext.txt"), the
system will look for the application associated with .txt files
(usually Notepad) and will call this application passing "Sometext.t xt"
as a parameter, just as if you had typed on the command line:

Notepad.exe Sometext.txt

What happens in your case is that there's an application associated
with the ".dll" type in your computer. When you launch
Process.Start(" D:\Test\VB6\dll \MyProg.dll" ...), the system calls that
application (probably regsrv32.exe), passing
"D:\Test\VB6\dl l\MyProg.dll" as a parameter, just as if you had typed

regsrv32 D:\Test\VB6\dll \MyProg.dll

on the command line.

Now for why would you try to "run" the dll...

It seems that the VB6 executable exposes some class(es) that you want
to use from your VB.Net app. In this case, exposing the classes from a
dll instead of an exe may give you a performance advantage. That's
because the classes created from the dll would exist in the same
address space as the .Net app. To use them from the exe, on the other
hand, would require costly interop calls. There are many issues to
consider when changing an exe into a dll, mostly related to
initialization code, window management, data persistence, to name a
few. I suppose you considered these issues and dealt with them
accordingly... =)

Now, to use the classes from the dll, you must first create a .Net
compatible wrapper assembly and reference the wrapper from your .Net
app. From what I've been reading, you'll probably achieve this by
navigating to the dll from VS 2005 Project References COM tab, or
using tlbimp to generate the .Net wrapper assembly for you and adding a
reference to the generated assembly into your VB.Net project.

HTH.

Regards,

Branco.

[Galen Somerville]

"Branco Medeiros" <br************ *@gmail.comwrot e in message
news:11******** *************@v 33g2000cwv.goog legroups.com...

Galen Somerville wrote:

>I have an app using a VB6 ActiveX.dll which I also have made as an exe.
Both
the dll and exe have exactly the same code and start in Sub Main. There
is
no form involved.

I start this activex as a Process like so:

Dim NewProcess As Process = New Process

Then I use one of these:

Process.Start(" D:\Test\VB6\dll \MyProg.dll", CStr(Arg1) & " " &
CStr(Arg2))

Process.Start(" D:\Test\VB6\MyP rog.exe", CStr(Arg1) & " " & CStr(Arg2))

If I start the exe version all goes well. But if I start the dll version
a
MsgBox pops up (and screws up the timing) with this message

"Dll RegisterServer in D:\Test\VB6\dll \MyProg.dll succeeded"

<snip>

As others pointed out, you can't "execute" a dll. A dll is a just
library of functions (or classes, in the case of COM dlls). The fact
that you had a Sub Main somewhere in code when you compiled your VB6
project into a dll doesn't change the dll's nature: the Sub Main is
just ignored (for executing purposes.It is used for the dll
initialization, if I remember correctly).

As you may know, Process.Start is used to directly run executables as
well as to launch the appropriate application related to a given file
type. If you call, for instance, Process.Start(" Sometext.txt"), the
system will look for the application associated with .txt files
(usually Notepad) and will call this application passing "Sometext.t xt"
as a parameter, just as if you had typed on the command line:

Notepad.exe Sometext.txt

What happens in your case is that there's an application associated
with the ".dll" type in your computer. When you launch
Process.Start(" D:\Test\VB6\dll \MyProg.dll" ...), the system calls that
application (probably regsrv32.exe), passing
"D:\Test\VB6\dl l\MyProg.dll" as a parameter, just as if you had typed

regsrv32 D:\Test\VB6\dll \MyProg.dll

on the command line.

Now for why would you try to "run" the dll...

It seems that the VB6 executable exposes some class(es) that you want
to use from your VB.Net app. In this case, exposing the classes from a
dll instead of an exe may give you a performance advantage. That's
because the classes created from the dll would exist in the same
address space as the .Net app. To use them from the exe, on the other
hand, would require costly interop calls. There are many issues to
consider when changing an exe into a dll, mostly related to
initialization code, window management, data persistence, to name a
few. I suppose you considered these issues and dealt with them
accordingly... =)

Now, to use the classes from the dll, you must first create a .Net
compatible wrapper assembly and reference the wrapper from your .Net
app. From what I've been reading, you'll probably achieve this by
navigating to the dll from VS 2005 Project References COM tab, or
using tlbimp to generate the .Net wrapper assembly for you and adding a
reference to the generated assembly into your VB.Net project.

HTH.

Regards,

Branco.

Very clear now. Process.Start, as I was using it, cannot run the dll. Yes I
am using the VB6 exe for the performance. It is using memory mapping for
speed. I interface with a USB device (proprietary) which has 99% of the USB
calls in a dll referenced by VB2005.

There is one USB call that collects Real Time data in the VB6 exe. If I
place this call in net, with the other 99%, it is way too slow. My current
problem is that, apparently, the USB device isn't recognized because it's in
a separate thread.

I think I will have to move 100% of the USB stuff to this VB6 exe with a
hidden form. The USB initialization needs an hWdw reference.

Now if I can figure out how to copy the whole VB2005 to a new location, I
can try it out. VB6 was easy, just copy all files to a new folder and make a
minor change to the vbp file.

Galen

[Walter Wang [MSFT]]

Galen,

I'm not sure about your following question:

---------
Now if I can figure out how to copy the whole VB2005 to a new location, I
can try it out. VB6 was easy, just copy all files to a new folder and make
a
minor change to the vbp file.
---------

Would you please depict more? Thanks.

Regards,
Walter Wang (wa****@online. microsoft.com, remove 'online.')
Microsoft Online Community Support

=============== =============== =============== =====
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
=============== =============== =============== =====

This posting is provided "AS IS" with no warranties, and confers no rights.