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

Referencing DLLs/projects

P: n/a
Another VB6 feature that I'm missing in VB.NET is with regard to referencing
projects vs. referencing DLLs.

In VB6 I can reference my support library, Support.dll, and call its
functions.

If I encounter a problem, I may decide to add the Support project to my
project group. The reference automatically updates itself to point to the
Support.vbp instead of Support.dll.

Now in VB.NET I can of course reference the DLL or alternatively add the
project to the solution and reference that. But VB.NET doesn't automatically
switch between the two like VB6 did.

In reality, I have an application that uses about 6 support DLLs with
interdependencies between one another. Each time I want to debug one of
these, I therefore have to delete and re-add all the references to all the
projects so that they each refer to one another as projects rather than
referring to the compiled DLLs. If I need to switch back to running the host
on its own, I then have to delete all the references once again and
re-reference all the compiled DLLs.

If there an easier way to manage references than this?

--

(O)enone
Nov 21 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
I know what you mean ,,,, i`ve been there too ;-)

Thing that made me dissapointed is that here is no way to create a COM like
out of process server ( VB6 ActiveX executable ) i need to write a proxy
now in good old VB6 ( MS VB.Net dev team shame on you ! )

regards

Michel Posseth

"Oenone" <oe****@nowhere.com> wrote in message
news:ey**************@TK2MSFTNGP12.phx.gbl...
Another VB6 feature that I'm missing in VB.NET is with regard to
referencing projects vs. referencing DLLs.

In VB6 I can reference my support library, Support.dll, and call its
functions.

If I encounter a problem, I may decide to add the Support project to my
project group. The reference automatically updates itself to point to the
Support.vbp instead of Support.dll.

Now in VB.NET I can of course reference the DLL or alternatively add the
project to the solution and reference that. But VB.NET doesn't
automatically switch between the two like VB6 did.

In reality, I have an application that uses about 6 support DLLs with
interdependencies between one another. Each time I want to debug one of
these, I therefore have to delete and re-add all the references to all the
projects so that they each refer to one another as projects rather than
referring to the compiled DLLs. If I need to switch back to running the
host on its own, I then have to delete all the references once again and
re-reference all the compiled DLLs.

If there an easier way to manage references than this?

--

(O)enone

Nov 21 '05 #2

P: n/a

m.posseth wrote:
I know what you mean ,,,, i`ve been there too ;-)

Thing that made me dissapointed is that here is no way to create a COM like
out of process server ( VB6 ActiveX executable ) i need to write a proxy
now in good old VB6 ( MS VB.Net dev team shame on you ! )


You can use remoting for that! Why do you need it to be an executable?
I'm not sure what advantage an ActiveX EXE gives you that you cannot
get in VB.Net?

Nov 21 '05 #3

P: n/a
Oenone wrote:
Now in VB.NET I can of course reference the DLL or alternatively add the
project to the solution and reference that. But VB.NET doesn't automatically
switch between the two like VB6 did.


Microsoft recommends using project references wherever possible so that
the version references can be updated correctly.

Check out this link:

http://msdn.microsoft.com/library/de...ml/tdlg_rm.asp

Nov 21 '05 #4

P: n/a
Well i use remoting a lot , however it is not the same as a VB6 Com
executable

why do i need it to be an executable ??

well what did you think about out of process state information and then i
talk also about the GUI interface that can be passed over with a VB6
executable to other win 32 applications ,,, this is my biggest problem at the
moment

"Chris Dunaway" wrote:

m.posseth wrote:
I know what you mean ,,,, i`ve been there too ;-)

Thing that made me dissapointed is that here is no way to create a COM like
out of process server ( VB6 ActiveX executable ) i need to write a proxy
now in good old VB6 ( MS VB.Net dev team shame on you ! )


You can use remoting for that! Why do you need it to be an executable?
I'm not sure what advantage an ActiveX EXE gives you that you cannot
get in VB.Net?

Nov 21 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.