devenv from command line doesn't add project references...

[Christopher Bohn]

(repost under MSDN account)

When building a solution that consists of one managed C++ project with
a project reference to a C# project in the same solution, there is a
bug when trying to build from the command line. The /FU arguments that
should be present for the project's references appear in the IDE's
buildlog.htm but they do not appear when built from the command line.
Everything builds just fine from the IDE. We are running on XP SP2
with VS2003 7.1.3088. This seems to be a very obvious bug. Has anyone else
encountered it? Is a fix planned for it? If so, when?

A workaround we have found is to include #using directives in the C++
code and set the correct "resolve #using references" in the project.
These command line arguments don't appear to get lost when built from
the command line.

Another solution appears to using a real reference to the dlls instead
of using project references.

 

[Kevin Yu [MSFT]]

Hi Chris,

First of all, I would like to confirm my understanding of your issue. From
your description, I understand that the devenv solution build at command
prompt doesn't take care of references added in solution explorer. If there
is any misunderstanding, please feel free to let me know.

Based on my research, this is a known issue. This is because the project
reference resolution code is assuming that the IDE is interactive while it
is not. This issue will be fixed in next version of VS.NET. Sorry for the
inconvenience.

HTH.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

 

[Christopher Bohn]

For confirmation: Your summary of the problem is not quite as specific as we
have seen, meaning that in some cases it actually does work, and it is only
when the assembly being compiled is Managed C++ that the references aren't
properly included.

Also, the second workaround to this problem was to add an Assembly Reference
to the dll instead of a project reference; however, this doesn't appear to
work when the referenced dll is built as Managed C++ instead of C#. In this
case, the same problem occurs - the /FU arguments do not appear as part of the
build command line. In this case, the first workaround must be used instead.

The next version of VS.NET isn't scheduled for some time; is there any plans
for a service pack or hotfix that will address this problem?

Chris

 

[Kevin Yu [MSFT]]

Hi Chris,

I'm not quite sure if it will be fixed in service packs or hotfixes. For a
hotfix, you can try to contact Microsoft Product Support Services. You can
contact Microsoft Product Support directly to discuss additional support
options you may have available, by contacting us at 1-(800)936-5800 or by
choosing one of the options listed at
http://support.microsoft.com/default.aspx?scid=sz;en-us;top. If they have
confirmed this a bug, they will help you out free of charge. Thanks!

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

 

[Christopher Bohn]

The only additional bit of information that we have found is that the ability
to compile the solution from the command line is controlled by the existence
of a single Managed C++ project. If this project has already been compiled
once from the IDE, then the solution will continue to compile properly from
the command line (and the /FU are properly used). On the other hand, if this
project's compiled DLL does not exist, then once again the /FU arguments are
left off and the solution does not compile. We haven't been able to figure
out what's unique about this one project - it is a Managed C++ project.
Originally it was at the top of the dependency chain for Managed C++ projects
- it depended on other MC++ projects, but no other MC++ project depended on
it. Now, however, there is one other MC++ project that depends on this
project, yet the devenv behavior hasn't appeared to change. Even copying the
project's final DLL from one computer to another will fix the problem.

Is this the same problem to which you were referring earlier, or does this
sound like something different/new? Are there any ways to fix or work around
this problem?

thanks
Chris

 

[Kevin Yu [MSFT]]

Hi Chris,

According to the description, I think this is the same problem as I
mentioned. You can try to get a hotfix from Microsoft PSS as I gave in my
last post or pick up from the following link:

http://support.microsoft.com/common/international.aspx?rdpath=gp;en-us;offer
prophone

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

 

[Eric Strennen]

Kevin,

Like Christopher I am having similar problems building Managed C++
solutions from the command line. As you stated, the build fails if it
uses project references instead of assembly (DLL) references. I've
changed my projects to not use project references so that I can run
command line builds. It 'only' took 2-3 days to figure this out...

First question is when is the next version of .NET coming out? Is there
any chance that a service pack for .NET 2003 to be released beforehand?

Second, someone should complain LOUDLY to the .NET development team
that this type of bug is completely unacceptable. Anyone who is
developing software for a living is almost certainly using an automated
build system that requires the compiler to be run from the command
line. Obviously, whoever setup the matrix of possible solution
configurations to perform regression testing fell down on the job.
Additionally, I won't even begin to start in on other intermittent
crashes of the .NET development environment.

Please pass these comments along to the appropriate people, thanks.

Regards,
Eric Strennen
Senior Software Engineer
Imago Scientific Instruments