MSBuild Project (.delphiproj) layout

Jun 14, 2007 at 4:22 AM
For the first version of Delphi for Visual Studio I propose that we do not store project properties of a Delphi build build for now other than targets .NET or Win32 for now. Since the Delphi project file (.DPR or .DPK) and its support files have all the file and build information we should only compile that main project file to start off. Then build move the build information (file version number, warning message settings conditional settings, etc) into the MSBuild project but maintain support for storing this information in supporting .RES, .CFG and .DOF file for backward compatibility with Delphi 7 and higher.

With that the project file should only have one Compile Item in the item group with the rest as Content items as follows...

<Compile Include="Project1.dpr">
<Content Include="Poject1.res">
<Content Include="Project1.dof">
<Content Include="Project1.cfg">

<Content Include="Unit1.pas"/>
<Content Include="Unit1.dfm">


There is a lot more to talk about here like references if Delphi For Visual Studio will support .NET targets. Since the compiler names for compiling Win32 and Delphi.NET are named DCC32 and DCCIL respectively I think a property named DCCCompiler should be added to the all conditions example...

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">

Jun 15, 2007 at 6:15 AM
Since we are more interested in Delphi.Net, my thoughts will be slightly weighted towards .net compatibility.

Here are my thoughts.

1. DOF files do not play any role for a successfull compilation. They were replaced for D2005 and above with the bdsproj files. Delphi has a very bad habit of updating the DOF/bdsproj files with all sort of crap. While not maintaining it might have some path/options related compilation issues when compiled from Delphi IDE, they can be easily fixed from the IDE.
2. I was going to suggest changing the pas files from compile to Content. Currently my build task is filtering out everything other than dpr and dpk from the compile items, but I like changing them to content better.
3. Since we do not have dof/bdsproj files available (or can rely on them) we will need another propertygroup that contain properties like namespace prefixes, paths, conditional defines and other delphi only options. I am still in the process of finding all the options that is required. Many of these options are target independent and need to be in a separate property group.
4. I would prefer adding the compiler option to be in target independent property group.
5. We are currently experimenting with a reference itemgroup to put all the references. This will work for .net, win32 is under investigation.

... Cont...
Jun 16, 2007 at 5:28 AM
I understand that your interested in Delphi.NET for this project and I want you to know it has been my goal of this project to make it as compatible with the Delphi IDE as possible. That included the possibility of support for Delphi.NET for this project.

I'm not sure if you have seen Delphi 2007's project file but it has every thing we need to compile both Win32 and Delphi.NET assembles.

Allow me to clarify if I change the way Delphi For Visual Studio loads the project file to support the way CodeGear has created there MSBuild project file format, then the end user of Delphi for Visual Studio will be able to press F5 to build and run there project with out us having to build a task DLL and MSBuild target files.


The end user will need both Delphi 2006 and 2007 installed on a system to build Delphi.NET assembles. However, I have looked at the MSBuild task in Reflector, it's not that complicated and we could duplicate it quickly enough. Keep in mind "not that complicated" is relative.

Now that I have had the time to think about it, I think we should follow the Delphi 2007's MSBuild project file format but keep the name *.DELPHIPROJ this way end users can rename the project file and BOOM it loads in Delphi 2007 for .NET or CodeGear Studio 2007 or what ever they are going to call it.

Let me know what you think about this, if you disagree please tell me why. I would like to know why it would be better to fork our file formats from CodeGear's Delphi IDE all together?

NOTE: The above question is a critical one for me. I feel it is a major shift in direction that should be debated. The main issue really is weather or not we will allow developers to use Delphi for Visual Studio projects in a team environment where others are using the Delphi IDE?

I want you to know I wanted to go the other way and fix the Delphi DPR project file so I am open to changing back but I need to feel good about it.

Mr Dee
Jun 16, 2007 at 6:23 AM
One reason why we slowed down on our VS addin project was the news that d2007 has an MSBuild project file format. However, looking from Delphi IDE's behavior of putting a lot of absolute paths in the project file hasnt been changed. This is a big pain when working in a team environment.

I dont think anybody who has both win32 and .net deliverables for a project will use D2007 before highlander. Atleast in our case, we have decided to postpone our upgrade to 2007 for next release cycle starting in early next year.

(btw, good news is that we were able to compile both win32 and .net projects created using this project, albeit after some manual adjustments with the project file.)

I havent downloaded my d2007 yet, i will try to do it during the weekend and look at the format. If we want to use other services from VS, like source control and TFS integration, we will need to add additional information in our project file. We will have to look at how robust Delphi's handling of project files are. I read an article that complains that Delphi.2007 always recreates the project file and thus remove any manually added item from it. This could be a major deterent.

I do agree that it will be ideal to keep the file formats close to that of D2007, and may be with some extensions. I am not very enthusiastic in making it available for Delphi IDE as well.

As for working in a team environment, we have to follow a strict policy of no check-in of bdsproj files as this almost always breaks each other mainly from absolute path references. This is another reason that I would like to keep the Delphi IDE and VS project files separate. I have to see how destructive d2007 is in this regard.

Jun 16, 2007 at 8:49 PM
Edited Jun 16, 2007 at 9:22 PM
Yes I agree absolute paths in the project file are wrong that is why we will correct them in our D2007 compatible MSBuild project file. If D2007 rejects the relative paths and can not make heads or tales of it then D2007 is broken not the our MSBuild project file.

As for anyone using D2007 before highlander for both win32 and .net targets I would have to agree with your assumption that the will not buy D2007 before highlander since I see no logical reason for an end user to do so as well.

You said...
(btw, good news is that we were able to compile both win32 and .net projects created using this project, albeit after some manual adjustments with the project file.)
Can I assume you mean your MSBuild project file NOT Delphi 2007's MSBuild project file? If so that is good news Can you send me a copy of your .PROJ file also once I've add and completed a work item of building a central MSBuild project class. Our TDelphiMSBuild class will be a central point to access project elements without the need to know how the project file is laid out. This class will have all options as properties and manage how they are saved to the MSBuild project file. This keeps our options open and provides other who join our group an easy way to read and write or add extended information to the project file.

We do not have to look too deeply at how Delphi 2007 handles project files as long as we do it correctly. If what we do breaks Delphi 2007 it is CodeGear's fault, we wrote the XML correctly and they should fix it. For example if they do not manage the .DFM files correctly when we add them in as content item group and they do not manage it correctly we ask them to fix it. If they do not we move on and let the community beat them up. As for deleting our file format we do not care as we will suggest for now end users copy our .delphiproj to .dproj but not the other way around.

That last paragraph I wrote really ended up convincing me to drop my idea of supporting Delphi 2007's MSBuild format.

Here is why..
  1. Delphi 2007 more than likely not like what we are doing in the MSBuild file.
  2. If I am supporting one way project file usage it will not help development teams.
  3. We should create our own format then build a tool that converts them between Delphi IDE and VS IDE
  4. I want our MSBuild project file to be better than theirs as I'm sure there will be frustrating issues in their format

Good I'm glad we discussed this it makes me feel good about the decision to create a new MSBuild file format.