I knew from here that we have to do the explicit imports for child namespace because imports will not include the child namespace.
But my question is that if I do "imports System" whether it will include all the classes/methods inside that namespace in the IL/native code or only referred ( used inside the application) will be included in the IL/native code.
Importing a namespace doesn't mean that anything is included in the code. It only means that the compiler recognises identifiers from that namespace.
The references in your project are what really decides which libraries the application is using. Still, the libraries are loaded when needed, they are not included in your executable file.
Related
It took me a while to even understand the problem I'm about to describe, so please let me know if the description is confusing...
I have an object called "cProp" that defines a number of sub-classes. To refer to these classes in other files in the project, I have to do something like...
Dim cp = New cProp.InflationRow()
I understand why this is; since the InflationRow is "inside" the cProp, I need to tell it where to find it. Fine.
But this, of course, gets tedious, so sometimes you want to fix it...
Imports cProp
Why doesn't that work? Why do I have to...
Imports ProjectName.cProp
You might wonder why I care, but these files are used in numerous projects with different names. So if I use Imports I have to change the project name in a bunch of places. I am aware that Namespace is likely the solution I want, right?
My confusion stems from the fact that the compiler can figure out just fine which cProp (which is the only one) I'm referring to in the code, so why not in the Imports? I think I'm missing something fundamental here.
It's because your project has a root namespace - you can see this in your project properties. You can delete this in the project properties - this will result in allowing you to simply use the class name from another project. However, namespaces are a good way to organize your classes. In VB, the project defaults to having a root namespace, which you don't see in your code files.
Within your project, since it seems to be all within the same root namespace, you don't have to qualify with the root namespace for code within the root namespace. The "Imports" statements are not within a namespace (only types can be within namespaces) - that's why you have to provide the full qualification there.
Good day,
I have used dll imports for "user32.dll" in the past.
However, I am trying to import a class library into my application which has some namespaces which come into conflict with namespaces which are already imported and referenced from other class libraries.
How can I reference this dll and only use the namespaces contained in it, or override the other namespaces imported from other class libraries in one class without it affecting the rest of the application.
I am still pretty new, this may not be possible.
Thank you.
To summarize the relevant issues:
In VB.NET one can use the Declare statement to call win32 functions in DLL's with typical EntryPoint constructs.
.NET Assemblies do not provide classical Win32 type EntryPoints (as such they cannot be 'declared')
If one needs to reference a .NET Assembly [or COM] you need to add a reference to the target library when compiling (usually done in the VS IDE or with the /r: switch)
In some cases Namespaces of such referenced Assemblies may collide with others. (i.E. referencing the same Assembly in different versions)
In that case one needs to import the required (conflicting) Namespaces with an Alias
For example:
Assuming you have an assembly with a root namespace Net that could collide with System.Net use:
Imports System
Imports ExtNet = SomeNetworkAssembly
Then in this case to access members of that assembly use ExtNet instead of Net
Note you can name the ExtNet part as you wish.
In C# one can do it via the using keyword instead.
When I try to Imports System.Web.Script.Serialization, I get an error in VB 2010 that says:
Warning: Namespace or type specified in the Imports System.Web.Script.Serialization doesn't contain any public member or cannot be found. Make sure the namespace or the type is defined and contains at least one public member. Make sure the imported element name doesn't use any aliases.
Not sure why I can't import it.
You might be missing an assembly reference to System.Web.Extensions.dll. Add this reference to your project, then try again.
Generally speaking, when you encounter this issue, go to the .NET API reference page of the type you want to use — for instance, JavaScriptConverter — and look out for the Namespace and Assembly hints (make sure you're looking at the page for the .NET framework version that you are using):
Namespace: tells you what to put in the Imports directive.
Assembly: tells you what assembly you need to reference in your project (e.g. go to Solution Explorer, locate References, and select Add Reference… from the context menu).
Also make sure to check the "Target Framework" in the project properties. If you are targeting a "Client Profile" framework then the assembly System.Web.Extensions.dll will not be available to add as a reference to your project.
I've googled for creation of namespaces and found some very useful examples, what these examples didn't have is how do I compile and implement my created namespace on my system so I can include it from my various applications.
So for example, if I create a namespace to load a config file from my application path and insert it to an array, Do i need to include the namespace on any project I use or is there a way to make it part of my environment?
You're thinking of Class Library (DLL) projects.
When you start up a new Visual Studio project, select Class Library rather than Windows Form project. This will compile your namespaces as a DLL (exposing your public classes), which can be referenced in other projects.
If you want to include a namespace that you created you have to add a reference to your project first. If you have compiled your code into a .dll file, then simply add the reference to the .dll file to your project and then at the top of your classes put the "Imports [Namespace]". If you haven't compiled your namespace, add the project (with the namespace that you created) to your solution, add the reference to it (under the Projects tab), and then use the Imports statement.
You are confusing the concept of a namespace with the concept of a project, especially of a class library project.
A class exists within a namespace. If no namespace is defined, then the class still exists within the global namespace (the one with no name).
In any case, it's classes that do the work. Namespaces are only so that you can have a class named Book, and I can have a class named Book, and so that TriDat.Book can exist at the same time as JohnSaunders.Book.
I'm getting a compiler error saying that "Acme.Business.User" is not defined.
I have a class library project called "Acme.Business" that has "Acme.Business" as the assembly name and root namespace as well. None of the classes use the "Namespace" keyword, so they all should exist in the namespace "Acme.Business".
I also have a class library project called "Acme.Web" that has a project reference to "Acme.Business". Again "Acme.Web" is the project name, assembly name, and root namespace.
Here's the weird part. If I add a class to "Acme.Web" I can type "Imports Acme." at the top and see both namespaces appear in intellisense like you'd expect, but if I try to do "Dim x as New Acme.Business.User" then "Business" doesn't show up in intellisense and I get an error saying "Acme.Business.User" is not defined.
I can't see what I'm doing wrong! Please help. Thanks.
I think you may be misunderstanding how project default namespaces work. The default namespace is a project file setting that simply tells Visual Studio what namespace to add to each file when you add a new class file to the project. If you have removed all of these namespaces from the code files then your types do not exist in that namespace.
This means that all of your types in the Acme.Business assembly live in the global namespace which is probably not what you want. In order to get the desired behavior you will need to add the namespaces back into your code files as that is the only way the compiler will create type names with that namespace.
OK, I figured out that the behavior I was seeing was because I was declaring namespaces within the code in Acme.Web the way I was used to in C# which is to fully qualify it, ie. Namespace Acme.Web.UI.WebControls. I didn't realize that in VB.NET it's building on top of what was specified for the root namespace. I removed the portion that was specified in the "root namespace" setting of my project and it started working. So my namespaces in code for Acme.Web now look like Namespace UI.WebControls.