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.
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.
So I have a fairly simple application that i found originally in C# I converted it to VB and everything is working perfectly find all the system references are working fine but this one DLL (gameserverinfo.dll) is not being found. I have re-added the reference in Project > Add reference and I have also changed the location of the dll and still no go. I'm not sure why it is having an issue as i have referenced it in other projects and had no issues. And thoughts?
You are probably missing a namespace. Try importing the namespace at the beginning of the file, fully qualifying any method/classes, or adding a global import statement from the reference page of the project properties.
I am a .NET Developer. I have a good understanding of how references work in .NET i.e. if you want to use AssemblyA.ClassA.MethodA in AssemblyB.classB.MethodB then you add a reference in Assembly A to Assembly B.
I am looking at a VB6 app and I get an error when I open it i.e. Errors during load. Refer to frmMain.log. I open frmMain.log and it says: "2142: Class MSComDlg.CommonDialog of control CommonDialog1 was not a loaded control class.". I have used WinMerge to compare the source code in the faulty project to a previous version of the project (which does not have the problem). The only difference is that the faulty project contains the following line in the client.vdp file:
Reference=*\G{08DBEFD7-6A19-4DCE-A533-5BDBB93683C8}#1.2#0#..\..\..\..\..\Windows\SysWOW64\Comdlg32.oca#Microsoft Common Dialog Control 6.0 (SP3)
Removing this line seems to resolve the problem. Why does this resolve the problem?
I have used Winmerge to compare yesterdays revision of the project (which does not have the problem) to todays revision of the project (which does have the problem). The only difference is the reference in the original post in the VBP file.
I would assume that someone installed the development version of this control on a different machine and then set a reference to it. When you try to open the project on your machine the reference fails. Or the control was uninstalled. It seems that the project was not using the reference and that it can be safely removed as it will still compile without the reference.
However, I have seen vb6 actually remove non-licensed controls from the form in question in this situation. So it may be that you can now compile because the form is missing a component that was there previously. Have you checked that frmMain has not changed, both the .frm and .frx files?
I just got a new PC (Win 7) with VS 2010 (same version as my old PC). I got a VB.NET solution from source control that contains two projects. One of the projects builds fine. The other project flags every non-MS Imports statement with:
Namespace or type specified in the Imports &1 doesn't contain any public members 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.
The ironic thing is that the working project within the same solution references all the same DLL's. I've removed and re-added the DLL's so I know they're there, and I can expand them in Object Browser, so I know they contain public methods.
I've ran out of ideas of things to try. Can someone throw me a bone, plz?
I had the same problem which I fixed by changing the Project Properties->Compile->Advanced Compile Options->Target Framework value from .Net Framework 4.0 Client Profile to .Net Framework 4.0
I had this happen. For me, the new DLL was targeting Dot Net 4.5, while the project which referenced it was only targeting 4.0. Switching the new dll to match fixed the issue.
I've had a similar issue as this before. In my case the problem was that the dll's were located on a network share drive (which in my system showed as q:) so when I referenced them the file path was q:\folder structure\file.dll. Upon switching machines, my system no longer referenced that share drive as q:\ but by another drive letter, causing my program to error out similarly.
In my case, I was able to correct this issue and prevent it from happening again by changing the way I referenced the dll from the drive letter it was assigned by my local system to the network path (\SERVER NAME\Drive Letter\file path\file.dll).
I was experiencing the same issue. The DLL I was referencing was built in framework 3.5. The project I was referencing the DLL was being built in 2.0. I switched the referring project to 3.5 and it built perfectly.
I had this problem with projects which were referencing the same version of the framework. I solved it with the following steps.
Remove reference to DLL
Clean and ReBuild DLL
Clean and ReBuild Project
ReAdd Reference.
This happened to me in a Visual Studio 2019 VB project with System.Data.SqlClient . Since the Import of System.Data.SqlClient was failing, all of my Sql classes used in declarations on the page -- SqlConnection, SqlCommand, SqlDataReader -- were undefined.
To fix it, I just had to use a full reference to System.Data.SqlClient.SqlConnection when declaring my very first variable for one of those classes on the page:
Using conn As System.Data.SqlClient.SqlConnection = New SqlConnection(GetConnectionString())
By changing just that first declaration on the page, it fixed the compilation error on the Imports line and all subsequent declarations on the page. (Even stranger, after building the project once like that, I was able to revert the declaration back to just referencing SqlConnection, and the Import worked and the page is compiling fine. So it may have been a temporary issue unrelated to my temporary fix)
I had already fixed this problem once I got to the point of googling this, and all I had to do was delete and re-add the reference in the solution explorer
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!