Alex Kipman wrote:
We will support building C++ projects. C++ projects are
not going to be in MSBuild format in the Whidbey timeframe (though they
will be in the Longhorn timeframe), however MSBuild will understand and
build both sln files as well as vsproj files directly. We will be doing
this through a task called VCBuild which will be available for anyone to
use. So for MSBuild projects we'll use the MSBuild task, and for C++
projects we'll use the VCBuild task. A solution file when fed to
MSBuild is translated into an in-memory MSBuild project, and each
project listed in the SLN is fed to the appropriate task based on its
type.
Will the output of the .sln be at different log levels so that errors can be distinguished from warn from chitchat, and will that output be streamed? Today when you run msdev against a solution you get a silence and then 'exec failed with error code 1', leaving you a large log file to search through to find out what borke.
1. I have some specific requests for ildasm; we cant control its behaviour properly. Can you send them on to the relevant person.
Ok. See the comments on
http://ant.apache.org/manual-1.6beta/OptionalTasks/ildasm.html to get a hint of the problem
1. if ildasm fails, it still creates a .il file containing the error text.
2. No way to control the name of any generated .res stub.
3. no way to control the location of any generated .res stub
4. gratuitous warning message // WARNING: Created Win32 resource file ...
(1), (2) and (3) really make dependency analysis tricky.
Also, for ILASM, why do I need to know that the
Source file is ANSI
or
Operation completed successfully.finall, for vbc, why use a different separator for referenced libraries than csc? He have excessive hoop jumping there and need to add some more to get things fully working.
I'll think of more later, no doubt.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
