I am writing my first VB.net app and want to include Debug.Assert functions.
When I do this,
Debug.Assert(LBound(arry) = 0)
I get the error
BC30451: Debug is not declared. It may be inaccessible due to its protection level.
I know that Debug is supposed to be in the namespace "System.Diagnostics", and in C# I can use it if I include "Using System.Diagnostics;" at the top of the source file.
In VB.Net, there is no similar Using statement that I can find, so I think I need to add System.Diagnostics to References.
However, in the Reference Manager, System.Diagnostics is not listed. I enabled similar sounding references, such as System.Diagnostics.Tracing, but they do not define a Debug object.
What should I do if System.Diagnostics is not available in RefernceManager and I need to reference that namespace?
I'm good for now.
This article explains more about importing namespaces in VBA.
How to: Add or remove imported namespaces (Visual Basic)
I learned that that you can use the Imports statement in VB.Net to import a namespace on a per file basis and how to get more control over project imported namespaces by double-clicking on My Project and linking References. From user1792293 I learned that one should always say "import a namespace" instead of "reference a namespace." Thank you for that.
Related
I have a project with a custom control overriding a default control from the system.windows.forms namespace. This works fine, but I discovered I needed to modify a DLL this project depends on with some code that needs to know about the existence of this custom class; this code uses the class name of the control to do various things.
As the project depends on the DLL, and circular dependencies are not-a-good-idea, I moved the custom class to a third DLL which is a new project by cut-and-paste, and set the project and library to depend on this new lib, and set this new library to be built first, before the two other projects, and added an assembly reference.
So far so good; I can now import this new namespace and use it in my code. But, now the existing uses of the custom control are broken in any 'designer' based code, as they still point to the default namespace. I've tried adding a reference under Project Properties > Imported namespaces, yet this is insufficient: the code likely needs to contain the explicit line imports <myNamespace>. And while this is no-problem for regular files, when you have a designer file it's important to not manually modify it.
What's the easiest proper way of informing visual studio that any custom control named say X should now be accessed as myNamespace.X?
The procedure as done in the question is correct, with one caveat: Check the .NET version, and if different set the target version to the lowest common denominator. If you use a newer Visual Studio than the original that was used to make the solution, it's likely there's a newer .NET out as well. By default, the latest .NET will be used for new projects. Visual studio will also happily attempt to build the projects with disparate .NET versions, and complain that it can't find references, then surreptitiously hide the version mismatch as a "Warning", even though linking assemblies with different targets is by default impossible.
The designer will then happily accept the custom class even if it's defined in another project.
After a major overhaul of our solution many namespaces were changed. However, in the Application.g.vb file of one of our WPF applications an Imports to a namespace that no longer exists keeps showing up and generates a warning. If I delete it, it returns, so there must be somewhere a piece of hidden code that still knows about this namespace.
The application does not hold a reference anymore to the dll that once contained this namespace and I cannot find the reference to it in the Project's xml file.
Where can this Imports statement come from? Visula Studio 2013.
There turned out to be a xmlns: reference to the namespace in the Application.xaml file. Curiously a previous solution wide scan for it failed to find it.
When I add an 3party Library (Gibraltar.Agent) to a VB.NET project I get namespaces which interfere with my current code.
For example the namespace Gibraltar.Agent.IS makes the following code invalid:
Assert.That("bla", [Is].EqualTo("bla"))
as a solution i have to fully qualify [Is]
Assert.That("bla", Nunity.Frameworks.Is.EqualTo("bla"))
Also annoying is the "I" namespace, which makes the following invalid:
For i = 0 to 10 'valid without referencing Gibraltar.Agent
For i as Integer = 0 to 10 'needed change after adding Gibraltar.Agent
How can i hide the unwanted 3Party namespaces?
EDIT
I did not add any Gibraltar namespaces.
The following does not help either:
Imports [Is] = NUnit.Framework.Is
You could create a new Class Library and create wrappers around the Gibraltar.Agent functionality you use, then just reference this class library instead of Gibraltar.Agent from your other projects.
See also the Adapter pattern.
These odd namespaces are created by an obfuscation library used by an older version of VistaDB which is ILMerged into the Gibraltar Agent. The obfuscator substitutes two-character symbols for VistaDB namespaces to conserve space.
We acquired VistaDB last year and now have a free hand to rework its internal structure and build process. This issue with namespaces leaking through will be resolved in Gibraltar 3.0.
Jay Cincotta
Founder
Gibraltar Software
Just don’t Import that namespace in your files. You may need to change the project settings if you have at some time in the past activated that namespace for inclusion in your project settings.
But according to the documentation the objectionable names don’t even exist.
I have a solution that contains many projects all using the same root namespace. No code files explicitly name a namespace. So lets say the root namespace is ExampleRootNamespace.
Now a problem comes into play when I want to add an explicitly named namespace to one of the code files I am working on. I want to be able to isolate this code from the rest of the assembly to be able to run FxCop against it. So I add something like Namespace Interfaces.CSV to the code file.
This causes any code that references this assembly to need to say Imports ExampleRootNamespace.Interfaces.CSV. So far so good. I can even run FxCop against the assembly. The problem now is that in other assemblies I cannot say any longer things like:
Public class frmInputBoolean Inherits
ExampleRootNameSpace.frmFormTemplate
Visual Studio is now asking me to rename the namespace to:
Public class frmInputBoolean Inherits
Global.ExampleRootNameSpace.frmFormTemplate
There are hundreds of errors related to this. So my questions are:
1) Why would basically naming a namespace under the root for the first time cause issues with the program?
2) Are there any workarounds to this issue without renaming?
I also want to add that with regards to ExampleRootNamespace.Interfaces.CSV I am not referencing this anywhere in the codebase. I'm currently just referencing it from a unit test project. So I don't see why adding this namespace causes an issue.
In C# try utilizing the USING operator with your namespace.
using ExampleRootNamespace = newExampleRootNamespace;
On the ones that have the global issue.
sadly, I do not believe an easy solution exists for you in VB.NET
Well, it appears this may be a bug in Visual Studio 2008. As the code has not changed but the problem with the required Global prefix is no longer there.
I say this because I checked out one of the offending code files and tried to add (as Meakins suggested):
Imports ExampleRootNamespace = Global.ExampleRootNamespace
When I did this two things happened.
1) The error highlighting and error correction suggestions were removed and ExampleRootNamespace was recognized by Visual Studio. Also the code now compiles.
2) Imports ExampleRootNamespace = Global.ExampleRootNamespace is not valid because of the use of Global in the imports statement. Visual studio says: "'Global' not allowed in this context; identifier expected." This Means that this line of code will not compile. So I removed it all together. Oddly enough despite it not being there (and thus the code returning to as before) there are no more errors.
I also restarted visual studio (but after doing the above). This is quite odd if you ask me!
There is Aliases feature in C# that allows to work with different assemblies, containing equally named entities (classes, structures, enums). It is activated when you choose an assembly an referenced assemblies list. But I can't see any similar in VB.NET project. Is there such a feature in VB.NET? If no, why?
Imports Data = System.Data
Will allow you to use:
Data.SqlClient
Similar to what you've seen in C#. Here is a blog post that discusses the usage. Here is an older one that laments another feature C# has that VB.NET doesn't (didn't?)
I think you are talking about the /reference:alias=filename option accepted by the C# compiler. That allows you to rename the root namespace of the assembly. Very handy when you need to reference both an old and a new version of an assembly that otherwise contain classes with the same namespace and class names. Without that option, you'd always get an ambiguous identifier compile error. The namespace alias feature can't fix that.
No, VB.NET doesn't have that. Why? Ask at connect.microsoft.com.
This is an example for how to do it, in both C# and VB.NET