You never end learning something new, I taught I have seen enough when dealing with solutions with C# and VB.NET mixed projects, today working on a legacy system I found the following scenario:

Project A - VB project, defines a set of base classes

Project B - C# project, uses the base classes and defines a set of controls

Project C - VB project, main application module, uses both classes defined in project A and B

All the reference were made to the corresponding projects selecting the projects via the standard Visual Studio add reference dialog box.

When we compiled the solution the compiler kept telling us:

BC30007: Reference required to assembly ‘Project A’ containing the base class ‘XXX’. Add one to your project.

The funny thing is that the reference is already there; I tried to build a test ‘Project C’ project using C# instead of VB and it all worked well...this seems to me like a bug in the compiler.

Surfing around I wasn’t able to find a lot of info but a single reply to a post that says something like:

This is a known bug in the VB compiler -- there's a problem whereby the
compiler doesn't recognize that the "Project 1" that "Project 2" refers
to is the same "Project 1" that you've got open in the IDE. The
workaround is to do this: delete the references from Project 3 and
Project 4 to Project 4 and re-add them as file references. That is,
instead of making a reference from the Project tab of the references
dialog, go the .NET tab and Browse for the actual DLL built by Project
1. This should make the error go away and workaround the problem until
there is a fixed compiler.’

And actually I cannot remind the source nor the author, I’m sorry I cannot give the credits for this but I copied and paste the text in a blob document while I was gathering information and I wasn’t able to find it again...but I tried to use the workaround he proposed and it worked.

But making a reference to the file instead to the project you have to be very careful about the compilation order of the assemblies, especially if you change something in the ‘Project A’ assembly.

To completely fix the situation and let Visual Studio to handle the right compilation order for projects you have to follow a series of steps:

1. Go to ‘Project A’ properties and make sure that each configuration build places the final output files in the same directory (this is important cause we make reference to the compiled assembly instead of the project)
   
2. Then we have to look for any reference made to ‘Project A’ inside the solution and change it to a file reference; point the reference to the compiled assembly inside the project bin folder
3. To let Visual Studio handle the correct order of projects compilation we need to explicitly inform the project that it depends from another project in the solution. So after changing the reference right click on the project and from the context menu select ‘Project dependencies...’
   
   In this dialog box place a check-mark on your ‘Project A’.
   In this way when you recompile the projects or the solution you will always be sure that ‘Project A’ is compiled (or recompiled) before the ones that use it; the right compilation order is respected in the same way as we have used a project reference.

I don’t know if this problem is present in Visual Studio 2005 and 2008, I didn’t had the chance to test it yet; if someone has more information or suggestions about the whole thing, please write a comment here or contact me directly.

Related Content

• NUnitit: Visual Studio Addin to support NUnit and some customizations to it (26/08/2015)
• Resharper and the OutOfMemoryException problem (26/08/2015)
• Spot Hidden Exceptions using IntelliTrace (26/08/2015)
• Visual Studio 2010 designer error: Value cannot be null. Parameter name: objectType (26/08/2015)
• VS2008 SP1 + PowerCommands = Toolbox AddItems...Crash! (26/08/2015)
• More related document (10)