VB Namespace...VB is going to kill me!

[bri189a]

I really miss C#.

 

In C# if I have:

 

Image i = new Image()

 

and I have the following at the top of the file:

 

using System;

using System.Web.UI.HtmlControls

 

There is no question whether I am using a System.Web.UI.HtmlControl.HtmlImage or a System.Drawing.Image object because I can just look up at my using statements.... not in VB!!!

 

In VB the Namespace isn't shown. If you want to know what you are 'using' you have to look at the project properties... which is just retarted. What happens when I move a file from one project to another where the project properties aren't the same? Or what happens when VB's namespace conventions don't match with the company you are working for (see below)

 

Can you turn off a default so every page (code behind) will have:

 

Namespace System

Namespace System.Web

etc.

 

Because it is really screwing me up since I have a WebPage called Index and a WebControl in a folder called controls called Index. Because of VB's ignorant so-called dummy proof features it wants to give me compile errors. So I put the Namespace in myself, but then it screws up my code behind. I'm about to turn every so-called 'smart' feature off because it's just slowing me down because I have to undo what was working that it changed!

 

Also on that note the same can be said for OptionStrict and OptionExplicit... what if I move a file that was created with OptionStrict off into a project that has OptionStrict on... well know I got to go re-work the file and update the source.

 

Sorry.... just venting.... any C# programmer who has had the joy of working in VB knows what I'm talking about...

[Coen]

Imports :confused:

[bri189a]

Um...yes, that's obvious... the thing is that VB automatically 'Imports' in the project options. I want Imports to be on the top of each .vb file and not to have to type it in myself.

[Iceplug]

Well, go to your project in the Solution Explorer window, right click on your project and go to properties. Go to the Imports tab and remove all of those imports. Now, you will have to put Imports statements at the top of your VB code. :)

[Mike_R]

Also on that note the same can be said for OptionStrict and OptionExplicit... what if I move a file that was created with OptionStrict off into a project that has OptionStrict on... well know I got to go re-work the file and update the source.

Just curious here... How does it work in C#.Net? I would hope that the default assumption is the equivalent of 'Option Strict On'? I couldn't imagine working with 'Option Strict Off', although, I realize one is forced to with Late Binding.

 

How does it work in C#?

[divil]

I don't think it's "retarted" at all. VB just happens to support one more layer than C# in terms of project-wide imports instead of having to declare them all in every file. Personally I think this is pretty useful, but like you said it can potentially cause problems when moving files between projects.

 

For example in a large presentation layer it would be great to always import System.Windows.Forms, System.Drawing, System.ComponentModel without having to specify them every time like you do at the moment with C#.

 

Mike_R: There is no such thing as having option strict off in C#. One of the reasons I like it :)

[Mike_R]

Mike_R: There is no such thing as having option strict off in C#. One of the reasons I like it :)

Ah, ok! Very good to hear! :)

 

But, then, how does one do Late Binding, where the compiler cannot possibly know ahead of time which VTable to use... :(

[PlausiblyDamp]

You could always use reflection and InvokeMember to do Late Binding in C#, but wherever possible I would try to avoid late binding completely.