[MonoDevelop] Moving to MSBuild

["Andrés G. Aragoneses"]

Thanks Mike, now all is much clearer. Just two more (simple) questions: 
- Will VS be able to open a C# project file if MD is developed in such a 
way that uses ".proj" instead of ".csproj" (for simplicity)?
- Does MSBuild contain an standard (different than the .sln format, 
which you said was not part of it) for solutions? It's not clear to me 
yet why this type of files are not XML-based yet...

	Andres


Michael Hutchinson wrote:
> On Sat, May 17, 2008 at 1:54 PM, "Andrés G. Aragoneses"
> <knocte at gmail.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.
> 
> There's no reason to allow people to create new mds/mdp solutions and
> projects, as it's essentially a deprecated format. If people really
> need it for some strange reason, they can use the project exporter.
> Eventually we will drop mds/mdp support.
> 
> ...
>>> 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?).
> 
> We can easily add new formats. *MSBuild*'s strategy is to use .proj
> for all projects.
> 
> Visual Studio's .csproj/vsproj I assume were for some kind of
> backwards-compatibility (maybe it was just so the names looked
> familiar to users!). Note also that .sln isn't actually an MSBuild
> format either, it's legacy VS (though MSBuild and MD understand it).
> 
> Since VS2005+ uses MSBuild as its build engine, it will be able to
> build any new MSBuild-format files we create, even if VS itself does
> not understand them.
> 
> ...
>>> 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.
> 
> Correct. Well, we could support it, and allow VS to understand only a
> subset of our solutions, but that would only confuse 95% of users IMO.
> 
>>> 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.
> 
> We will have "workspaces" that can contain multiple solutions. VS will
> understand the solutions, but only MD will understand the workspaces.
> However, the workspaces will still be MSBuild format, and hence
> buildable on windows.
> 
> There are actually very few use cases where nested solutions are
> needed, and I believe that those are solved *better* by the
> workspaces.
> 
> Consider:
> * A solution is an environment for resolving project references
> * These projects are not intended to be developed or distributed
> separately -- if this is not the case, they should be referenced as
> pkgconfig libraries, not projects.
> * Therefore, you only need *one* solution to contain all the projects
> for your current solution.
> 
> Many of the "solutions" in the MonoDevelop solution tree, for
> examples, are not "solutions" in any meaningful sense of the word, as
> they depend on projects that are children of other solutions.
> 
> The main use case for workspaces is:
> * Consider our "extras" directory
> * Each solution is intended to be distributed separately from MD; it
> builds against the *system* Monodevelop, i.e. references pkgconfig
> monodevelop packages
> * The only reason they are included within the MonoDevelop solution
> tree is so that they can be built against the unstable/development
> MonoDevelop
> * In summary, workspaces are an environment for resolving pkgconfig references.
> 
> This use case doesn't work right now. Our solutions are arbitarily
> nestable, with no thought to the actual consequences of doing so.
> Nested solutions are going to die, even in the mds format.
> 
> ...
>>> 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?
> 
> .proj
> 
>>>>  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...).
> 
> What advantage does that give? If MD assumes that paths in MSBuild
> files are Win32 format, and converts them to/from the native format
> when loading/saving, then it will work fine everywhere.
> 
> Think of the MSBuild files as makefiles. VS only supports a subset of
> the features, but we do not have to let this limit us. The only real
> argument you have made for keeping mds files is for nested solutions.
> These can be expressed in MSBuild format (though nested solutions can
> too), and hence although it's not VS-compatible, it will still be
> buildable by MSBuild, AND VS will be able to open the child solutions.
> Note that every argument I have made for VS applies to SharpDevelop
> too.
> 
> Ultimately, we will replace the MD build engine with MSBuild. It's not
> just going to be the format in which we load/save the projects, it'll
> be much more fundmental than that.
>