Answered by:

Question

Up to now, we've been building our Winforms VS2005/.NET 3.0/ELB 3.1 app by launching devenv from a .bat file to build our solution file. But I decided to give msbuild a try...

When msbuild is run against our solution file, one of the (11) projects gets an error saying that it is missing a reference: "C:\Projects\USM DEVL\BusinessRules\ProjectBusinessRules.vb(3231): error BC30652: Reference required to assembly 'Microsoft.SqlServer.Smo, Version=9.0.242.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' containing the type 'Microsoft.SqlServer.Management.Smo.Server'. Add one to your project."

Aside from the fact that we don't get this error when we build the same solution via devenv, the line # shown in the error message is NOT referencing an SMO class. It it instead referencing a method that's in one of the 10 other assemblies built within this solution (and that referenced assembly does have a reference to the SMO assembly, and that reference is resolved OK).

So why does msbuild fail while devenv builds the same solution OK? I thought that project and solution files were supposed to be interchangeable between VS and msbuild. Is there a secret msbuild command line option that tells it not to generate erroneous error messages ? ;-)

Answers

Hi, firstly thanks for trying MSBuild. Yes, we try to produce exactly the same build as devenv/VS does. There are a few known irregularities at present despite our best efforts. One of them is that the VB compiler that is used inside VS (the inproc compiler) treats several references as implicit; the vbc.exe command line compiler requires almost all references to be explicitly supplied. This may be one of those. Another issue is that sometimes the inproc VB compiler considers all projects' references to be available to all other projects. vbc.exe cannnot do this as it only has visibility into a single project.

Can you firstly build on higher verbosity (eg., /vetailed) and grab the vbc.exe command line that's leading to this BC error (which is from vbc). Then run that directly, from the folder of the appropriate project. Presumably that will produce the same error. Then try adding the reference to this assembly. If that compiles then add it to the project. I can't guess why vbc wants it if as you say it isn't actually consumed by the code.

These irregularities have been brought to the attention of the VB compiler team, but feel free to open a product feedback center issue to make them aware there's customers that encounter them.

All replies

Hi, firstly thanks for trying MSBuild. Yes, we try to produce exactly the same build as devenv/VS does. There are a few known irregularities at present despite our best efforts. One of them is that the VB compiler that is used inside VS (the inproc compiler) treats several references as implicit; the vbc.exe command line compiler requires almost all references to be explicitly supplied. This may be one of those. Another issue is that sometimes the inproc VB compiler considers all projects' references to be available to all other projects. vbc.exe cannnot do this as it only has visibility into a single project.

Can you firstly build on higher verbosity (eg., /vetailed) and grab the vbc.exe command line that's leading to this BC error (which is from vbc). Then run that directly, from the folder of the appropriate project. Presumably that will produce the same error. Then try adding the reference to this assembly. If that compiles then add it to the project. I can't guess why vbc wants it if as you say it isn't actually consumed by the code.

These irregularities have been brought to the attention of the VB compiler team, but feel free to open a product feedback center issue to make them aware there's customers that encounter them.

After reading other posts on this and other forums, I believe the problem I'm seeing is caused by the fact that MSBUILD does not resolve what I call "transitive" references.

That is, project A invokes a method that's defined in project B and project B invokes a method that's defined in project C. And while project A has an explicit reference to project B, and project B has an explicit reference to project C, there is no explicit reference from project A to project C.

Visual Studio appears to resolve the implicit reference of A=>C, but MSBUILD doesn't.

I solved the problem by manually adding a reference from project A to project C (although if another developer later uses the "remove un-needed references" feature, that reference will disappear from project A).