App.Path??

[Bryan]

What is the VB.NET equivilant to App.Path in VB6?

[Bucky]

You have to pass the Application.ExecutablePath (path to the exe

with the exe filename itself) to the GetDirectoryName method

in the IO.Path class. I like to use this nifty little function:

 

Private Function AppPath() As String
 Return IO.Path.GetDirectoryName(Application.ExecutablePath) & "\"
End Function

[Bryan]

thanks a lot man I appreciate it.

[Bryan]

hey, thanks Becky, it worked great. I really appreciate it.

[divil]

Bucky, not Becky!

[Derek Stone]

Man... woman... dog... what's the difference... ;)

[Bucky]

Bah, I don't need to put up with this crap. ;)

 

And you're welcome, Bryan. :D

 

* Bucky glares at Derek

[Bryan]

oops, sorry about calling you Becky and not Bucky.

[Guest kmdnyc]

jeez vb.net cant have a simple app.path!

[Derek Stone]

I know... Application.ExecutablePath is sooo much longer.

[Vitaly]

looks like VB6.GetPath() is also correct

[Bucky]

Vitaly: What are you talking about? This is a VB.NET forum, by the way.

[Vitaly]

Bucky, I mean

Microsoft.VisualBasic.Compatibility.VB6 NameSpace,

which has a GetPath() method, and it looks like retyurns correct value.

[Bucky]

We try to stress use of the .NET framework, rather than the old,

yucky Compatability namespace. Using it is just taking a step

backwards in VB evolution and not harnessing any of the new

power in the Framework.

 

Your way will work, but it is much more appropriate to use the

way mentioned above.

[Vitaly]

Bucky, I agree, .NET Framework is a lot more powerful then

VB6, but probably the best would be to combine all good that was in VB6 and all other previous versions with what new one has to offer. It would be also easier for people not to forget everything they did before.

[Robby]

From what I've read so far (from MS) is that they will not ensure the future of the Compatability namespace.

[Derek Stone]

They shouldn't have put it there in the first place.

[wyrd]

So.. new folks to .NET should avoid referencing Microsoft.VisualBasic.Compatibility.* Namespaces at all costs? Are these the only Namespaces that use legacy VB6 code rather then .NET? I just want to make sure that I'm using pure .NET when I program my applications. :)

[divil]

They don't use legacy code, rather, they offer methods of doing things syntactically similar to the older VB6 ways. The namespace is only there to help the VB6 Project Upgrade Wizard upgrade those old projects without changing too much code.

 

DON'T USE THEM! :)

[Wakane]

They don't use legacy code, rather, they offer methods of doing things syntactically similar to the older VB6 ways. The namespace is only there to help the VB6 Project Upgrade Wizard upgrade those old projects without changing too much code.

 

DON'T USE THEM! :)

 

I agree. MS gives the compatibility code there just so that it's easier for VB6 to get familiar with VB.net (sort of like an easy learning curve, a stepping stone).

 

Once you get used to the .net framework, you are ready to use the real thing (everything's there is a real thing, but you know what I mean :) )

[Guest makai]

now I am confused - If you use VB .Net I would think you have to use the .Net Framework - I have seen nothing compatible in any way whatsoever to VB6 - what is a Namespace? how is it compatible?

[wyrd]

A Namespace is a group of related classes. There's a compatibility Namespace which allows you to use commands that are in VB6.

 

As you learn more about object oriented programming it'll make more sense. For now just be aware that it's there and that you should stay away from it. :)

[Guest makai]

OK - I agree - I was thinking I could be using that VB6 compatible namespace without knowing it -

 

Is it correct then that I would have to include a definition line somewhere in order to be using it in my code? So that if I do not specifically do this then I am not using it ...