Namespace confusion

[tshad]

Using VS 2008, I have a project that uses the dll from another project.

The Namespace is MyFunctions, with a class of DbObject. The beginning of
the code is:
***************************
Imports System
Imports System.Data
Imports System.Data.SqlClient

Namespace MyFunctions

Public Class DbObject
**************************

The Project, class vb file, and dll are called MyFunctions.

In my code, I have to:

Imports MyFunctions.MyFunctions

To get this to work:

Dim myDbObject As New DbObject("a test")


Why don't I need:

Imports MyFunctions

How would I change the project to allow me to use only the Namespace?

Thanks,

Tom

 

[kimiraikkonen]

Using VS 2008, I have a project that uses the dll from another project.

The Namespace is MyFunctions, with a class of DbObject.  The beginning of
the code is:
***************************
Imports System
Imports System.Data
Imports System.Data.SqlClient

Namespace MyFunctions

  Public Class DbObject
**************************

The Project, class vb file, and dll are called MyFunctions.

In my code, I have to:

Imports MyFunctions.MyFunctions

To get this to work:

    Dim myDbObject As New DbObject("a test")

Why don't I need:

Imports MyFunctions

When you use "MyFunctions.MyFunctions", it sounds like you have 2
nested namespaces with the same name which is not necessary for
readablity. If DbObject is located under MyFunctions, you'd better
remove second MyFunctions namespace and revise your assembly as:

Imports MyFunctions

Dim myDbObject As New DbObject("a test")
'.....Here actually it's same with without "Imports"
' Dim myDbObject As New MyFunctions.DbObject("a test")

HTH,

Onur Güzel

 

[tshad]

When you use "MyFunctions.MyFunctions", it sounds like you have 2
nested namespaces with the same name which is not necessary for
readablity. If DbObject is located under MyFunctions, you'd better
remove second MyFunctions namespace and revise your assembly as:

I seem to have this but not sure why.

When I created the Class Library project, it created 2 folders :

MyFunctions <----Folder
Myfunctions <--- Folder
MyFunctions.sln
MyFunction.suo

VS puts the code files in the 2nd MyFunctions folder.

My files are set up as I show (with one namespace).

In my web site, I referenced the .dll from this project and it is the one
that thinks there are 2 namespaces. Imports MyFunctions won't work because
it thinks there are 2 namespaces.

Thanks,

Tom

 

[David Anton]

In your project properties, see what you have for 'Root namespace'. All
classes in your VB project are in this namespace. You'll find that it's
probably set to "MyFunctions". Either clear the root namespace or avoid
adding the namespace explicitly in your code files.
--
http://www.tangiblesoftwaresolutions.com
C++ to C#
C++ to VB
C++ to Java
VB & C# to Java
Java to VB & C#
Instant C#: VB to C#
Instant VB: C# to VB
Instant C++: VB, C#, or Java to C++/CLI

 

[tshad]

In your project properties, see what you have for 'Root namespace'.
All classes in your VB project are in this namespace. You'll find
that it's probably set to "MyFunctions". Either clear the root
namespace or avoid adding the namespace explicitly in your code files.

That was the problem.

But why would VS work this way?

I don't think I have seen anywhere where it says to do this.

You would normally set the namespace in your file as part of the code. Why
would the Project add another?

Thanks,

Tom

 

[Jack Jackson]

That was the problem.

But why would VS work this way?

I don't think I have seen anywhere where it says to do this.

You would normally set the namespace in your file as part of the code. Why
would the Project add another?

I would not normally add the Namespace in every file, I would have the
root NameSpace specified in the project so that I don't have to put it
in every file in the project.

 

[Cor Ligthert[MVP]]

Tom,

Why are you all the time calling the behaviour of Java developers (and
languages very much based on that) normal behaviour. Mostly I use in C# only
one namespace in a solution, not even a project, and it gives me only a lot
of time correcting those (by the way, there is as well a default namespace
in the project properties in C#, only it does not work as fine as in VB).

You consequently are debating that you want that the VB languages need as
much typing as languages direct derived from C, while you only are
referening to those languages without giving any other reason.

Don't forget that C# is a typical scholar languages. Where things need to be
easy to explain as you don't know the functions yet.

Just my opinion.

Cor

 

[James Hahn]

The root namespace is supposed to be something that makes the full name
unique - there could be many MyFunctions but probably only one
tshad.MyFunctions.

 

[tshad]

Tom,

Why are you all the time calling the behaviour of Java developers (and
languages very much based on that) normal behaviour.

Didn't realize I was. I assumed (and yes I know the problem with that )
that it was normal to do this. But that was because in my old job, I did
all my coding (VB and C#) in Dreamweaver so I had no project that would put
the namespace in it. This meant I would have to do this.

Also, many of the sample code I have seen on the net (VB or C#) had the
namespace in the source.

Mostly I use in C# only one namespace in a solution, not even a project,
and it gives me only a lot of time correcting those (by the way, there is
as well a default namespace in the project properties in C#, only it does
not work as fine as in VB).

You consequently are debating that you want that the VB languages need as
much typing as languages direct derived from C, while you only are
referening to those languages without giving any other reason.

I don't think I do that. I personally like both languages and the
differences tend not to be the languages themselves but the implementations
of the languages in VS.

I know that I did make this statement in another thread:
*********************************************

Option Strict On doesn't fix every quirk in VB.NET...

I agree.

and the same thing about C#. We have these discussions at work all the
time. Why doesn't C# to this like VB does or why doesn't VB do that like C#
does.
****************************************************

My point here was that at work the people that like VB are constantly
complaining when they have to work on C# projects that VB does this or that
better.

And when people that like C# are constantly complaining when they have to
work on VB projects that C# does this or that better.

I just think it is funny.

I happen to like the Case sensitivity of C# because it I can use the same
names for different things (camel case for memory variables, pascal case for
functions and upper case for constants for example). Others hate it.

Tom