All geek questions in one place

New computer calling "namespace of the type specified in the import does not contain any public member" in VB.NET

I got a new PC (Win 7) with VS 2010 (the same version as my old PC). I got a VB.NET solution from a source control that contains two projects. One of the projects is building perfectly. In another project, a check box is executed for each expression other than MS Imports, using:

The namespace or type specified in Imports & 1 does not contain any public items or cannot be found. Ensure that the namespace or type is defined and contains at least one public item. Make sure that the name of the imported item does not use any aliases.

The irony is that a working project within the same solution refers to all the same DLLs. I deleted and re-added the DLLs, so I know that they exist, and I can expand them in the Object Browser, so I know that they contain public methods.

I ran out of ideas about what to try. Can someone throw me a bone, plz?

+6
source share
5 answers

I had the same issue that I fixed by changing Project Properties-> Compile-> Advanced Compile Options-> Target Framework from .NET Client 4.0 to .NET Framework 4.0

+7
source

It happened to me. For me, the new DLL was targeting Dot Net 4.5, and the project he was referring to was targeting 4.0 only. Switching the new dll in accordance with the fixed problem.

+4
source

I had a similar problem as before. In my case, the problem was that the dlls were on a shared network drive (which showed up as q :) on my system, so when I referred to them, the file path was as follows: \ folder structure \ file.dll. When switching computers, my system no longer referred to this shared drive as q: \, but to a different drive letter, which caused my program to also fail.

In my case, I was able to fix this problem and prevent it from repeating by changing the way the DLL was referenced from the drive letter that it assigned by my local system to the network path (\ SERVER NAME \ Drive Letter \ file path \ file.dll).

+2
source

I had the same problem. The DLL I referenced was built in 3.5. The project that I referenced the DLL was built in version 2.0. I switched the project project to 3.5 and it built perfectly.

0
source

I had this problem with projects that referenced the same version of the framework. I solved this with the following steps.

  • Remove DLL Link
  • Clean and ReBuild DLL
  • Clean and ReBuild Project
  • Reference Information.
0
source

Source: https://habr.com/ru/post/944060/

More articles:


All Articles