Referencing DLLs/projects

[Oenone]

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

[m.posseth]

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

[Chris Dunaway]

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?

[Chris Dunaway]

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

[M. Posseth]

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?