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\MyProg.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-us/shellcc/platform/shell/programmersg
uide/shell_basics/shell_basics_extending/fileassociations/fa_verbs.asp?frame
=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\MyProg.exe " & CStr(Arg1) & " " & CStr(Arg2))


To know whether the registration is successful or not, wait it to exit and
read its ExitCode:

NewProcess.WaitForExit()
if NewProcess.ExitCode = 0 then
Console.WriteLine("Registration successful")
else
Console.WriteLine("Registration failed")
end if


Hope this helps.


Sincerely,
Walter Wang ([email protected], remove 'online.')
Microsoft Online Community Support

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.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/subscriptions/support/default.aspx.
==================================================

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

 

[Herfried K. Wagner [MVP]]

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\MyProg.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.exe" for use with VB6 and "regasm.exe" for use within .NET-based
applications.

 

[Galen Somerville]

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.exe" for use with VB6 and "regasm.exe" for use within .NET-based
applications.

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 ([email protected], 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]]

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.exe" to let it
register the COM dll silently.


Regards,
Walter Wang ([email protected], 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]

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\MyProg.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.txt"
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\dll\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]

<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.txt"
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\dll\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 ([email protected], 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]

Walter

Say I have a folder named CARDIO. In this folder are a number of .frm, .bas,
..gif, etc, files. Among them are the Cardio80.vbp and Cardio80.vbw files.

I can copy the whole mess of files to a new folder named CARDIOX. In this
folder I would rename the Cardio80.xxx to Cardio90.xxx and take Cardio90.vbp
into an editor and make those same name changes.

Now I have a new project as far as the System and IDE are concerned.

There may be other common files in other folders that both use. Obviously I
cannot change those files.

Question. If I want to send data from the DataReceiver to the
DataTransmitter do I use the same methods of putting/getting data through
the memory mapping? In other words, the same way I do it for Transmitter to
Reciever.

Galen

 

[Walter Wang [MSFT]]

Galen,

Unless you're use linked source files within your VB.NET 2005 project,
normally source files are under the base folder or sub folders of the
project file. Therefore you could easily copy the entire folder around and
use it freely. I'm not sure if I've misunderstood anything, please feel
free to reply here if I did.

For your second question, yes previously we discussed one-way communication
from the Transmitter to the Receiver. I think it's easier to just create
another pair of Transmitter and Receiver and use different channel (file
mapping name) to communicate, just the opposite direction.

Hope this helps.

Regards,
Walter Wang ([email protected], 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]

Okay, so I can copy the entire VB2005 project folders to a new location. The
current project is named Cardio80. Is there an easy way to change the name
at the new location to something like Cardio90 ? It appears that I could
open the proj file in a text editor and make the changes.

I will experiment on transmitting from Reciever to Transmitter.

Galen

 

[Galen Somerville]

Following up on file mapping.

I changed the mapping from SECTION_MAP_READ as follows

m_SharedMem = MapViewOfFile(m_SharedFile, SECTION_MAP_WRITE, 0, 0,
MaxDataSize + 4)

It appears that I will have to set MaxDataSize to a large amount like 15,000
as that's the maximum I will be using. What the heck, it's only RAM and
nowadays everybody's got plenty of RAM

Then I write to Transmitter as follows

For i = 0 To 3
j = CShort(i)
Marshal.WriteByte(New IntPtr(m_SharedMem.ToInt32() + i + 4), bytAry(j))
Next

Works fine in my test program so I do not need to set up any further
mapping.

Galen

 

[Walter Wang [MSFT]]

You should be able to rename the project in Visual Studio 2005: in the
Solution Explorer, right-click on your project and select "Rename".


Regards,
Walter Wang ([email protected], 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]

Thanks

Galen