0

So I have an ASP.NET VB website that references several other projects (their DLLS are just put in the site's bin folder). I need to update a small piece of code in one of the projects, which I have done and it builds fine. However, when I copy over the new DLL to the website's bin folder it fails to build, and all the Imports statements say "BC40056: Namespace or type specified in the Imports xxx doesn't contain any public member or cannot be found", which results in a ton of errors like "is not defined" . There is no reference to the updated DLL in the website project's properties, but if I put the old version back it's all fine.

The project was copied from a server and the vbproj file contained references to other DLLs, but the HintPaths were a mixture of mapped drives and ..\..\..\. I've updated these so that they're all the full server location path, but this has made no difference. I tried adding the project to the same solution as the website and added a reference to the project instead, but this also made no difference.

I've done plenty of Googling but have yet to find a solution. Any help would be very welcome!

AlanPartridge
  • 63
  • 1
  • 9
  • 1) Right click on `Solution` then select `Clean Solution`. Then try `Rebuilding` the whole solution. 2) Navigate to `bin` folder in file explorer delete all data resides in `bin` folder. Then `Rebuild` the solution again. – Abdul Haseeb Aug 11 '20 at 16:05
  • @AbdulHaseeb Thanks, but it's a website, not a web application so there's no clean option. – AlanPartridge Aug 11 '20 at 16:11
  • Consider running your own private nuget server for all these dependent components; it's a simple task to set one up and makes the management / referencing these modules in your other projects much easier – Caius Jard Aug 11 '20 at 16:19
  • @AlanPartridge then go to `bin` folder in file explorer and delete all files resides inside it. Then `Rebuild` the solution/project again. – Abdul Haseeb Aug 11 '20 at 17:24

2 Answers2

0

A few things You don't want to just "place" the .dll's in the bin folder. One big reason is that when you do a "clean" project, the bin folder is deleted. So, anytime you do a clean project, what is in the bin folder is cleaned out. And a developer will often do a clean project if some kind of problem is occuring.

I would place those files in some folder in the project. (create a folder, or if its only one or two .dll's, then place them in the root of the project). At compile time, the .dll's will be copied to the bin folder. And if you using web deployment, then you can choose to have the .dll's all combined into one .dll. So, once again, you can see it makes little sense to place the .dll's in the bin folder, since during a build, they will not be required, and as noted, the resulting bin folder can and will as a "regular" development process be re-created (emptied out). I seen a good number of projects in which the developer did place the .dll in the bin folder (because they did not know where else to place the .dll's, and that was seemly the only place that the application worked. But, during a web build + deployment to the production server, those .dll's can be left behind - they not be copied to the final "deployment" build. (I'm basic saying don't do this!!).

You can also consider just creating folder called "packages" in the root. This is where all the nuget packages are placed. So, some folder for those .dll's is the idea here.

The other big issue? Well, just dropping some .dll's in some place does NOT give you the developer all the methods and properties of those .dll's when writing code (we are assuming these are managed code - not win x32 .dll's).

So, without adding a reference to that assembly, then I can't see how the project will even compile correctly, and how syntax checking, and general use of the assembly will ever work during the development process (so VERY perplexed that you don't have references to those .dll's - that as a general rule can't work).

Now, to use the assemblies? Yes, you want to add the .dll as a reference to the project.

So, in references, add the .dll as a reference.

And then in the property sheet for the refence? Make sure you have the "copy local" set = true. eg this:

enter image description here

So, above is GhostScript.net reference. (a open source library to manipulate pdf's).

Note the long path name for the .dll location. But, MOST important is the copy local setting = true. This means during a compile and build (which as noted can clean out the bin folder), then the .dll will be output to the final build in the bin folder.

So, I can't see how you can compile anything without an actual reference to the .dll. That is quite much assumed and a given - else I see no way how your project can compile under any circumstances.

So, referance the .dll, and that should allow use of the class(s) and objects, and enable your code to compile. And make sure the copy local = true, as that is the process that will copy + place the .dll in the final output (bin) folder when you compile.

Albert D. Kallal
  • 42,205
  • 3
  • 34
  • 51
  • Thanks for your very detailed answer. One thing I forgot to mention is that even when adding a reference to the DLL it never appears in the list of references, yet it adds it to the bin folder, which I never seen before. It's fine with the other referenced DLLs. Also, I don't see all the detailed info about my references, e.g. Copy Local etc, probably because it a website project and not an application. – AlanPartridge Aug 12 '20 at 06:57
0

So it turns out that the project for the DLL I was trying to reference had the Target CPU set to x64. Changing this this to 'AnyCPU' then allowed me to reference it.

This post gave me the answer: Could not load file or assembly ... An attempt was made to load a program with an incorrect format (System.BadImageFormatException)

AlanPartridge
  • 63
  • 1
  • 9