ProjectSection(ProjectDependencies) is missing in .sln

[3F]

When at least VS 16.5.4. Reported here https://developercommunity.visualstudio.com/content/problem/996183/projectsectionprojectdependencies-is-missing-in-sl.html

For MvsSln the problem affects ISlnPDManager ProjectDependencies feature (part of LProjectDependencies handler)

More like we need to add a compatible alternative to ProjectReference because actually it may be a new official behavior. Not sure, I'm waiting a reply, and moreover...

But anyway:

Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "SlnTest1", "SlnTest1\SlnTest1.csproj", "{142CCFC4-AB0B-4680-9254-D22A669C337E}" EndProject Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "ClassLibrary1", "ClassLibrary1\ClassLibrary1.csproj", "{34EB954A-7FC0-4463-865D-8B353395B595}" EndProject

While project file:

<ProjectReference Include="..\SlnTest1\SlnTest1.csproj">
  <Project>{142ccfc4-ab0b-4680-9254-d22a669c337e}</Project>
  <Name>SlnTest1</Name>
</ProjectReference>

Does anyone know anything about it?

[3F]

ProjectDependencies is most important feature since it helps easily calculate the build order, or provide solution dependencies entirely. Some of my other projects requires exactly this.

ProjectReference is part of msbuild world and it will be problematic since #23 is not started yet (but I hope soon).

Anyway, more like we need to support both ways :( Any info/suggestions are welcomed.

[3F]

Finally I received the official information regarding VS logic, this is it,

Project Dependencies	Project Reference	.sln
✔	✔	✔
✔	❌	✔
❌	✔	❌
❌	❌	❌

copy-paste

I thought MSBuild operates this section for ALL cases when initializes its environment. That is, only this sections defines the order when evaluating nodes.

Seems like MvsSln will try to eliminate these miscellaneous units between VS and msbuild world.

[3F]

Since MvsSln already implements ProjectReferences that provides features for project references in ISlnPDManager manner, I just added activation for existing ProjectDependencies (shallow copy) through new flag:

https://github.com/3F/MvsSln/blob/9c3949825db5bc2a8863ab103d87c4a181a1a514/MvsSln/SlnItems.cs#L119-L125

That is, we can use like:

SlnItems.ProjectDependenciesXml | SlnItems.LoadMinimalDefaultData

or

SlnItems.ProjectDependenciesXml | SlnItems.LoadDefaultData

For this flag, the actual logic:

Project Dependencies	Project Reference	.sln
✔	✔	✔
✔	❌	✔
❌	✔	✔
❌	❌	❌

See new tests for details.

FYI: Of course if we'll use related handler with writer for updating .sln. For other cases we can just safely use a unified logic between msbuild and VS.

[Str1ker17]

Seems that this type of data breaks creation of an empty solution programmatically

i.e. to create an empty solution, I have to exclude

net.r_eg.MvsSln.Sln sln = new Sln(SlnItems.All & ~SlnItems.ProjectDependenciesXml, String.Empty);

[3F]

@Str1ker17 Looks like a bug. Could you please open a new issue regarding this behavior? Thanks