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
Related
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.
I am trying to use the generic DbSet class. I have tried adding the following references so far to my solution because the MSDN documentation states that DbSet lives inside System.Data.Entity:
However, as shown below I still cannot add a reference to System.Data.Entity, the only suggestion intellisense has is EntityClient which does not contain DbSet:
Resharper/Intellisense is not giving me any other suggestions of namespaces I could possibly add.
I have tried cleaning and rebuilding my solution, and I am using the .Net Framework 4 full version (not the client version).
I have tried using NuGet to search for EntityFramework and have found one result which I have added to no avail as is show below:
What DLL file do I need to add to my solution to add a reference to System.Data.Entity and use the DbSet class?
Thanks
The same MSDN reference page that you mention says that you need to reference EntityFramework.dll in your project.
Note that namespaces and assemblies are not the same thing. The following statement is a little over-simplified, but you can think of namespaces as residing inside (or becoming available by referencing) an assembly.
So, once you've referenced the assembly, you will still need the using System.Data.Entity; directive.
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!
I have a VB file that imports System.IO, but only uses it is a couple of places. My co-workers and I were wondering if there is a small performance boost if we just use System.IO explicitly were we need it (IE., System.IO.MemoryStream) instead of importing it.
No. There's no difference. The compiler produces exactly the same IL in either case.
You can prove it by compiling it both ways, and then using Reflector to disassemble the assembly and observe the IL produced.
Robert is exactly correct. I'll add that the purpose of importing namespaces (VB.NET is Imports; C# is using) is to avoid having to type the fully-qualified name of every class that you intend to consume. The compiled IL code still uses the fully qualified name, so importing the namespace is just there to simplify some of your work as a developer.
One drawback with importing namespaces is that if someone gives you code to use, but doesn't share with you the top of their code file with the namespace imports, you have to figure out for yourself what namespace to add.
I'm using LINQ to SQL as my data access layer for a new project. I have added my database tables to the designer and all is well.
Whenever I use one of these classes in a function, Visual Studio warns me that 'Type xxxx is not CLS-compliant' or that 'Return type of function xxxx is not CLS-compliant'
Is this a problem with the classes that LINQ to SQL generates? Does it matters? Can I disable these warnings anywhere? My VS error list is clogged up with these warnings making it hard to see anything else.
EDIT:
Sorry, I should have mentioned these are VB.NET projects. :)
I found this link on MSDN Connect:
When adding inheritance relations
between classes in the O/R designer,
the acess level on the generated
backing store member of the Id
attribute, "_Id", is changed from
private to protected, causing the CLS
rule violation. The Id property is
used in an association between the
classes.
If you want to get rid of the warnings, you can use:
#pragma warning disable 3021
Or, if you want to disable them project-wide, add 3021 to the "Suppress warnings" field in the Build tab of your project's properties in Visual Studio.
Ben M has the right idea on the problem.
The quickest way to solve this on a VB.Net project is to make the assembly not CLSCompliant and hence avoid those warnings. Adding the following line to any of your files will do the trick
<Assembly: CLSCompliant(False)>
Best file to add it into is AssemblyInfo.vb inside of the "My Project" folder.
It ultimately depends on what types are being returned by your database and what the names of those types are.
One issue regarding CLS compliance is a type that has two publicly exposed members which differ in name only by case, e.g. MyField and myField.
Here's an article that should help you determine where your CSS compliance issues are occuring and deal with the issues. If you need more help, pose some code and we'll see what we can do.
I usually see that error when I'm consuming types from one assembly which does not have the CLSCompliant attribute in another assembly which does.
That is, are your Linq to SQL classes in a different project than the functions you're writing? Have you specified [assembly: CLSCompliant(true)] in some but not all of the projects in your solution?