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.
Related
Is there a consensus within the C# development community on the .cs filename in which global using statements are declared?
I was going to adopt the filename GlobalUsings.cs but then found that a hidden file called MyProject.GlobalUsings.g.cs is created behind the scenes by the VS2022 toolchain. This is to support the related new C# 10 feature called Implicit global using directives.
Blazor has supported a similar feature for .razor files and the Blazor solution template automatically creates a file called _Imports.razor. That name is derived from the Razor syntax to declare a using reference.
Short Answer
Usings.cs or maybe GlobalUsings.cs.
More Info
There are actually 2 new features. They seem really simple at first, but the more you read about it, the more complicated it becomes.
Global using directives. You can use global in front of any using directive in any file to make it global in the project.
Implicit usings. This automatically adds a set of common global using directives depending on the project type. You can enable this in a project that is upgraded to .NET 6 buy putting this in the project csproj file: <PropertyGroup><ImplicitUsings>enable</ImplicitUsings>...
Implicit usings is enabled by default on new .NET 6 projects, so it sounds like the convention is:
Use implicit usings.
You may still need a file to store global usings that are not implicit. I like your idea of GlobalUsings.cs. It's self-documenting.
In fact, this naming is recommended by the Welcome to C# 10 Blog. I highly recommend reading it; it was really helpful to me.
EDIT:
This seems to keep changing. .NET 6 project templates are now including a Usings.cs file.
How can one programmatically determine which type libraries (GUID and version) a given native, VB6-generated DLL/OCX depends on?
For background: The VB6 IDE chokes when opening a project where one of the referenced type libraries can't load one of its dependencies, but it's not so helpful as to say which dependency can't be met--or even which reference has the dependency that can't be met. This is a common occurrence out my company, so I'm trying to supplement the VB6 IDE's poor troubleshooting information.
Relevant details/attempts:
I do have the VB source code. That tells me the GUIDs and versions as of a particular revision in the repo, but when analyzing a DLL/OCX/TLB file I don't know which version of the repo (if any--could be from a branch or might never have been committed to a branch) a given DLL/OCX corresponds to.
I've tried using tlbinf32.dll, but it doesn't appear to be able to list imports.
I don't know much about PE, but I popped open one of the DLLs in a PE viewer and it only shows MSVBVM60.dll in the imports section. This appears to be a special quirk of VB6-produced type libraries: they link only to MSVBVM60 but have some sort of delay-loading mechanism for the rest of the dependencies.
Even most of the existing tools I've tried don't give the information--e.g., depends.exe only finds MSVBVM60.dll.
However: OLEView, a utility that used to ship with Visual Studio, somehow produces an IDL file, which includes the importlib directives. Given that VB doesn't use IDL files, it's clearly generating the information somehow. So it's possible--I just have no idea how.
Really, if OLEView didn't do it I'd have given it up by now as impossible. Any thoughts on how to accomplish this?
It turns out that I was conflating basic DLL functionality and COM. (Not all DLLs are COM DLLs.)
For basic DLLs, the Portable Executable format includes a section describing its imports. The Optional Header's directory 1 is about the DLL's imports. Its structure is given by IMAGE_IMPORT_DESCRIPTOR. This is a starting point for learning about that.
COM DLLs don't seem to have an equivalent as such, but you can discover which other COM components its public interface needs: for each exposed interface, list out the types of their properties and their method arguments, and then use the Registry to look up where those types come from. tlbinf32.dll provides some of the basic functionality for listing members, etc. Here's and intro to that.
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'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?
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