ProjectSection(ProjectDependencies) is missing in .sln #25
Comments
|
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.
Anyway, more like we need to support both ways :( Any info/suggestions are welcomed. |
|
Finally I received the official information regarding VS logic, this is it,
copy-paste
Seems like MvsSln will try to eliminate these miscellaneous units between VS and msbuild world. |
|
Since MvsSln already implements ProjectReferences that provides features for project references in ISlnPDManager manner, Lines 119 to 125 in 9c39498 That is, we can use like: SlnItems.ProjectDependenciesXml | SlnItems.LoadMinimalDefaultDataor SlnItems.ProjectDependenciesXml | SlnItems.LoadDefaultDataFor this flag, the actual logic:
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. |
* NEW: Activating ProjectReferences for existing ProjectDependencies (shallow copy) through new flag.
Issue #25.
```
ProjectDependenciesXml = 0x0800 | ProjectDependencies | Env,
```
Covers ProjectDependencies (SLN) logic using data from project files (XML).
Helps eliminate miscellaneous units between VS and msbuild world:
#25 (comment)
Requires Env with loaded projects (LoadMinimalDefaultData or LoadDefaultData).
A core feature in .NET DllExport Post-processing:
3F/DllExport#148
* NEW: `ProjectReference` support without obsolete projectguid. Issue #26.
* NEW: IXProject methods:
```
+IXProject.GetFullPath(string relative)
```
* FIXED: Fixed possible empty records in SlnParser.SetProjectItemsConfigs.
* FIXED: Fixed `The given key was not present...` when different case for keys in Item.Metadata.
* FIXED: Fixed protected XProject GetProjectGuid() + GetProjectName() when empty property.
* CHANGED: Compatible signature update for `ForEach<T>` extension method:
```
IEnumerable<T> ForEach<T>(this IEnumerable<T> items, Action<T> act)
```
* CHANGED: Updated Microsoft.CSharp 4.7.0 (Only for: netstandard2.0 + netcoreapp2.1)
* CHANGED: Updated Microsoft.Build 16.5.0 (Only for: netcoreapp2.1)
* MvsSln up to rev `9c39498` due to 3F/MvsSln#25 Part of #144 * Post-Processing #148: Implemented backend logic with configurable environment: Format: $(SolutionPath);$(MSBuildThisFileFullPath);...populated property names...;.... ``` <Target Name="DllExportPostProc"> <!-- Now we can access the following properties and items: $(DllExport) - version $(DllExportSln) - full path to .sln which controls current project $(DllExportPrj) - full path to current project where processed .NET DllExport @(DllExportDirX64) - $(TargetDir)x64\*.* @(DllExportDirX86) - $(TargetDir)x86\*.* @(DllExportDirBefore) - $(TargetDir)Before\*.* @(DllExportDirAfter) - $(TargetDir)After\*.* @(DllExportDependents + populated property name) - each populated properties from DllExportInvokedPoint, e.g. DllExportDependentsTargetDir @(DllExportDependencies + populated property name) - each populated properties from DllExportInvokedPoint, e.g. DllExportDependenciesTargetDir --> </Target> ``` * Post-Proc. Added support of external .net.dllexport.targets * PostProc usage has been moved into ExportTaskImplementation * Fixed MSB4094 when using the same properties +Checking the existence of our entry point * `DllExportInvokedPoint` renamed as `DllExportProcEnv` * Basic GUI support for predefined options in Post-Proc feature That is, *! Some Post-Proc features are not yet available in GUI. But you can already configure it with msbuild. * cleanup * Updated data in SimpleConfFormater.Parse() +PostProc +PreProc * MvsSln up to rev `838fab00dd` /? #148 (comment) * MvsSln up to rev `e07c5806dd`: +`ProjectReference` support without obsolete projectguid * Updated MvsSln 2.5.2 * Added multiple destination support via derivative targets: #148 (comment) * +`DllExportSeqDependents...` Includes sequential referencing through other projects
|
Seems that this type of data breaks creation of an empty solution programmatically i.e. to create an empty solution, I have to exclude |
|
@Str1ker17 |
* FIXED: Fixed CalculateHashCode() Extension.
Internally affects many objects due to broken GetHashCode().
* FIXED: Fixed SlnItems.ProjectDependenciesXml when empty input:
Report #25 (comment)
* NEW: packages.config support PR #30. Related issues #27, #28.
To activate it, use the following flags:
* PackagesConfig, PackagesConfigSolution, PackagesConfigLegacy.
For example,
```
using Sln l = new("Input.sln", SlnItems.AllNoLoad | SlnItems.PackagesConfig);
IPackageInfo found = l.Result.PackagesConfigs
.SelectMany(s => s.Packages)
.FirstOrDefault(p => p.Id.StartsWith("Microsoft."));
// found.MetaTFM ...
Version v = l.Result.PackagesConfigs.First().GetPackage("LX4Cnh")?.VersionParsed;
```
Including GetNuTool compatible packages, format:
https://github.com/3F/GetNuTool#format-of-packages-list
* NEW: Added HasValue and HasNothing properties in PropertyItem.
* NEW: Added SlnItems.AllMinimal and SlnItems.AllNoLoad in addition to SlnItems.All.
* NEW: Added IXProject.GetPackageReferences().
* CHANGED: ConfigItem.Format() marked as obsolete.
Use `ToString()` and `IConfPlatform.Formatted` instead.
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
ProjectReferencebecause actually it may be a new official behavior. Not sure, I'm waiting a reply, and moreover...But anyway:
While project file:
Does anyone know anything about it?
The text was updated successfully, but these errors were encountered: