[MonoDevelop] Moving to MSBuild

[Lluis Sanchez Gual]

El ds 17 de 05 del 2008 a les 19:54 +0200, en/na "Andrés G. Aragoneses"
va escriure:
> Hi, sorry for the late response...
> 
> Michael Hutchinson wrote:
> > On Thu, Mar 13, 2008 at 2:43 PM, Andres G. Aragoneses
> > <aaragoneses at novell.com> wrote:
> >>  I have a question about this: Will the MD file format be maintained
> >>  anyway (or not dropped at least)? If the answer is 'no', then I just
> > 
> > At the very least, we will certainly have importers...
> 
> How's the thing evolving? IMO this should be a combo box that lets you 
> select the file format when creating a project/solution, like image 
> manipulation programs do.

The changes will be committed soon. For now, you'll be able to select
the default file format in the MD preferences.

> 
> 
> >>  wanted to point out a number of reasons not to do this:
> >>  - There are several projects that already use it.
> >>  - There are some interesting things in the MD project file format that I
> >>  think are better than MSBuild:
> >>  1) Same file extension for any type of project regardless the language.
> > 
> > We want VS compatibility where possible, so we will use .csproj and
> > .vbproj etc.,  but apart from that I see no reason to invent lots of
> > new file extensions.
> 
> I wasn't advocating for inventing more extensions, but certainly was 
> worried about this strategy that MS/MSBuild/VS selected, which I guess 
> imposes how MD should behave in this matter (but what happens with 
> project file formats which use a language that VS cannot open? for 
> example, to mention the most uncommon, PHP.NET?).

There are two options. The first option is to create a new project type,
which means creating a GUID and an extension name (.xxxproj). The second
option is use a generic project type with .mdproj extension (in this
case the project type is determined by a class name, which is stored in
the project file).

> 
> >>  2) Solutions inside solutions support. (Even in Mono SVN this feature is
> >>  used.)
> > 
> > VS solutions aren't actually MSBuild files, even though MSBuild
> > understands them, and it would be possible to represent nested
> > solutions with MSBuild files, but VS would not be able to load them.
> 
> Then it's not worth doing it, right? Because of interoperability reasons.

VS will still be able to load individual solutions, so there is no
interoperability problem.

> 
> 
> > Solution folders (structuring of projects within a solution) partially
> > solve the problem. We will probably also have "workspaces" for
> > grouping solutions, but the solutions themselves will be VS solutions.
> 
> That's it, they partially solve the problem and is my main concern about 
> this project file format, which is why I though MD format should remain 
> always as a fallback IMHO.

Even if we keep the old format, you won't be able to use nested
solution, because the project model has changed and it doesn't allow
nested solutions. Nested solution will be shown as solution folders.

> 
> 
> >>  3) Support for unmanaged projects (well, I'm not sure if the MSBuild
> >>  counterpart of this either exists, or if it's supported in MD, or if its
> >>  support is planned)?
> > 
> > We will be doing this for C projects etc. MSBuild files are about as
> > flexible as makefiles. We just need to write the relevant build
> > targets. VS seems to invoke the targets through MSBuild to do the
> > actual builds, making it similar to our makefile integration.
> > 
> > VS C/C++ projects don't use the MSBuild format yet, but that is likely
> > to change in the future. TBH, we don't really care about unmanaged VS
> > projects ATM.
> 
> But in this case, which extension will these type of projects use?

Same answer as the php case above.

> 
> 
> >>  4) Use of not-win32ish stuff (for example \backslashes\ for paths).
> > 
> > Unfortunately, this would mean the projects would not be be buildable
> > with MSBuild on Windows, let alone be able to be opened in VS.
> 
> Yes, I'm not proposing to use normal slashes for MSBuild, just saying 
> that MD format is good because of its not-win32ish way of expressing the 
> paths (the future MD for Win32 won't have any problem building it if 
> it's prepared for replacing them at execution time with the native 
> counterpart...).
> 
> Regards,
> 
> 	Andres
>