Cannot load UWP projects #5

mrexodia · 2018-06-18T20:17:06Z

Thanks a lot for your great library! When going over a rather big solution I found a problem related to UWP project. I worked around the issue by simply ignoring the UWP projects for now.

Project:

https://github.com/mrexodia/ClangPowerToolsUwpTest

Code:

using net.r_eg.MvsSln;
using System;

namespace VsProjectStuff
{
    class Program
    {
        static void Main(string[] args)
        {
            using (var sln = new Sln(@"c:\CodeBlocks\ClangPowerToolsUwpTest\UwpTest.sln", SlnItems.All))
                foreach (var project in sln.Result.ProjectItems)
                    Console.WriteLine($"guid: {project.pGuid}, path: {project.path}");
        }
    }
}

Exception:

Invalid static method invocation syntax: "[Microsoft.Build.Utilities.ToolLocationHelper]::GetPlatformSDKDisplayName($(SDKIdentifier), $(SDKVersion))". Method 'Microsoft.Build.Utilities.ToolLocationHelper.GetPlatformSDKDisplayName' not found. Static method invocation should be of the form: $([FullTypeName]::Method()), e.g. $([System.IO.Path]::Combine(`a`, `b`)). 

   at Microsoft.Build.Shared.ProjectErrorUtilities.ThrowInvalidProject(String errorSubCategoryResourceName, IElementLocation elementLocation, String resourceName, Object[] args)
   at Microsoft.Build.Shared.ProjectErrorUtilities.ThrowInvalidProject(IElementLocation elementLocation, String resourceName, Object arg0, Object arg1)
   at Microsoft.Build.Evaluation.Expander`2.Function`1.Execute(Object objectInstance, IPropertyProvider`1 properties, ExpanderOptions options, IElementLocation elementLocation)
   at Microsoft.Build.Evaluation.Expander`2.PropertyExpander`1.ExpandPropertyBody(String propertyBody, Object propertyValue, IPropertyProvider`1 properties, ExpanderOptions options, IElementLocation elementLocation, UsedUninitializedProperties usedUninitializedProperties)
   at Microsoft.Build.Evaluation.Expander`2.PropertyExpander`1.ExpandPropertiesLeaveTypedAndEscaped(String expression, IPropertyProvider`1 properties, ExpanderOptions options, IElementLocation elementLocation, UsedUninitializedProperties usedUninitializedProperties)
   at Microsoft.Build.Evaluation.Expander`2.PropertyExpander`1.ExpandPropertiesLeaveEscaped(String expression, IPropertyProvider`1 properties, ExpanderOptions options, IElementLocation elementLocation, UsedUninitializedProperties usedUninitializedProperties)
   at Microsoft.Build.Evaluation.Expander`2.ExpandIntoStringLeaveEscaped(String expression, ExpanderOptions options, IElementLocation elementLocation)
   at Microsoft.Build.Evaluation.Evaluator`4.EvaluatePropertyElement(ProjectPropertyElement propertyElement)
   at Microsoft.Build.Evaluation.Evaluator`4.EvaluatePropertyGroupElement(ProjectPropertyGroupElement propertyGroupElement)
   at Microsoft.Build.Evaluation.Evaluator`4.PerformDepthFirstPass(ProjectRootElement currentProjectOrImport)
   at Microsoft.Build.Evaluation.Evaluator`4.EvaluateImportElement(String directoryOfImportingFile, ProjectImportElement importElement)
   at Microsoft.Build.Evaluation.Evaluator`4.PerformDepthFirstPass(ProjectRootElement currentProjectOrImport)
   at Microsoft.Build.Evaluation.Evaluator`4.EvaluateImportElement(String directoryOfImportingFile, ProjectImportElement importElement)
   at Microsoft.Build.Evaluation.Evaluator`4.PerformDepthFirstPass(ProjectRootElement currentProjectOrImport)
   at Microsoft.Build.Evaluation.Evaluator`4.EvaluateImportElement(String directoryOfImportingFile, ProjectImportElement importElement)
   at Microsoft.Build.Evaluation.Evaluator`4.PerformDepthFirstPass(ProjectRootElement currentProjectOrImport)
   at Microsoft.Build.Evaluation.Evaluator`4.EvaluateImportElement(String directoryOfImportingFile, ProjectImportElement importElement)
   at Microsoft.Build.Evaluation.Evaluator`4.PerformDepthFirstPass(ProjectRootElement currentProjectOrImport)
   at Microsoft.Build.Evaluation.Evaluator`4.EvaluateImportElement(String directoryOfImportingFile, ProjectImportElement importElement)
   at Microsoft.Build.Evaluation.Evaluator`4.PerformDepthFirstPass(ProjectRootElement currentProjectOrImport)
   at Microsoft.Build.Evaluation.Evaluator`4.Evaluate()
   at Microsoft.Build.Evaluation.Evaluator`4.Evaluate(IEvaluatorData`4 data, ProjectRootElement root, ProjectLoadSettings loadSettings, Int32 maxNodeCount, PropertyDictionary`1 environmentProperties, ILoggingService loggingService, IItemFactory`2 itemFactory, IToolsetProvider toolsetProvider, ProjectRootElementCache projectRootElementCache, BuildEventContext buildEventContext, ProjectInstance projectInstanceIfAnyForDebuggerOnly)
   at Microsoft.Build.Evaluation.Project.ReevaluateIfNecessary(ILoggingService loggingServiceForEvaluation)
   at Microsoft.Build.Evaluation.Project.Initialize(IDictionary`2 globalProperties, String toolsVersion, String subToolsetVersion, ProjectLoadSettings loadSettings)
   at Microsoft.Build.Evaluation.Project..ctor(String projectFile, IDictionary`2 globalProperties, String toolsVersion, String subToolsetVersion, ProjectCollection projectCollection, ProjectLoadSettings loadSettings)
   at net.r_eg.MvsSln.Core.IsolatedEnv.Load(String path, IDictionary`2 properties) in D:\prg\projects\MvsSln\MvsSln\MvsSln\Core\IsolatedEnv.cs:line 335
   at net.r_eg.MvsSln.Core.IsolatedEnv.GetOrLoadProject(ProjectItem pItem, IDictionary`2 properties) in D:\prg\projects\MvsSln\MvsSln\MvsSln\Core\IsolatedEnv.cs:line 210
   at net.r_eg.MvsSln.Core.IsolatedEnv.Load(IEnumerable`1 pItems) in D:\prg\projects\MvsSln\MvsSln\MvsSln\Core\IsolatedEnv.cs:line 312
   at net.r_eg.MvsSln.Core.IsolatedEnv.LoadProjects(IEnumerable`1 pItems) in D:\prg\projects\MvsSln\MvsSln\MvsSln\Core\IsolatedEnv.cs:line 266
   at net.r_eg.MvsSln.Core.SlnParser.Parse(StreamReader reader, SlnItems type) in D:\prg\projects\MvsSln\MvsSln\MvsSln\Core\SlnParser.cs:line 154
   at net.r_eg.MvsSln.Core.SlnParser.Parse(String sln, SlnItems type) in D:\prg\projects\MvsSln\MvsSln\MvsSln\Core\SlnParser.cs:line 103
   at net.r_eg.MvsSln.Sln..ctor(String file, SlnItems type) in D:\prg\projects\MvsSln\MvsSln\MvsSln\Sln.cs:line 54
   at VsProjectStuff.Program.Main(String[] args) in C:\Users\Admin\Documents\Visual Studio 2017\Projects\VsProjectStuff\VsProjectStuff\Program.cs:line 14

The text was updated successfully, but these errors were encountered:

3F · 2018-06-18T21:32:34Z

Thanks for the report. Temporarily, you can try to use flag:

SlnItems.All &~ SlnItems.LoadDefaultData

this probably will help to get $"guid: {project.pGuid}, path: {project.path}" for your case.

About exception, looks like problem from internal MS logic. I'll check this later to be sure.
You can also try solution with overriding - #4 (comment)

mrexodia · 2018-06-18T21:35:26Z

Hi,

That code was just a minimal example I tested, the actual code also used sln.Result.Env.Projects unfortunately...

It turned out that for my use case UWP needed special treatment anyway (converting a big solution from AdditionalLinkLibraries to references). Thanks for the advice though!

3F · 2018-06-18T22:34:09Z

special treatment anyway I see :) just a note: Today's MvsSln provides own implementation of parser only for .sln files. For project files, it only wraps MS libraries with some additions and related features for our projects like vsSolutionBuildEvent, DllExport, and so on. But today I'm also seeing a lot of problems with backward compatibility for their internal logic (after global restructuring starting together with VS2017 and other same directions, you know...) Thus, in v2.0 I specially isolated this place as an trivial virtual method, that I mentioned early. So you can try to solve this problem yourself while I'm trying to understand the future of this way at all <_< I'll try to prepare reports about all this bugs for MS when I'll have time. I need to check this in details anyway. Any related info about MS libraries is very welcomed. Thanks for using, 19.06.2018 0:35, Duncan Ogilvie:

…

Hi, That code was just a minimal example I tested, the actual code also used sln.Result.Env.Projects unfortunately... It turned out that for my use case UWP needed special treatment anyway (converting a big solution from AdditionalLinkLibraries to references). Thanks for the advice though! — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#5 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADGJ_bv2HF0zau9SaROCwNYmN_hRk8K_ks5t-B0egaJpZM4UsaCI>.

3F · 2018-08-04T17:23:19Z

@mrexodia I've checked this problem through other version - Microsoft.Build.dll v15.7.179

https://www.nuget.org/packages/Microsoft.Build/
- https://www.nuget.org/packages/Microsoft.Build.Utilities.Core/ required by ToolLocationHelper

Seems it solves most of our other related issues! But unfortunately this requires .netfx 4.6 (4.5 for latest v14.x) and ...

Looks like most of updated MS libraries, today, only for .netfx 4.6+ <_<

For .netfx 4.0 it still uses obsolete logic, and fully don't understand some global changes starting with 15.0

I don't know, ... I really don't want to change platform version for this project.

As for temp solution

Try overriding, as I said before, with this custom build from nuget packages.

Works for me:

Just add an updated Microsoft.Build.dll for your project.
Override loading, for example: https://github.com/3F/MvsSln/wiki/Examples-override-MS-Project
- Let me know, if you can't apply this examples for your case.
Set AutoGenerateBindingRedirects property for host project because of different Microsoft.Build.dll:

<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>

Use MvsSln as before.

mrexodia · 2018-08-04T21:10:04Z

Hey, thanks for the follow up! For my project I just copied your project to my repository and made the changes required to make it work for me.

Generally I see that lots of projects have multiple targets in their nuget packages. Perhaps you could include a 4.0 target with the old library and a 4.6 target with the updated library. Probably not the best solution, but at least you keep some support for 4.0...

3F · 2018-08-04T21:53:24Z

Perhaps you could include a 4.0 target with the old library and a 4.6 target with the updated library.

That is, this problems* will be anyway for those who will use 4.0 :)
the all from this tracker at this time, btw :p

I also raised new issue into msbuild project, let's see what they advise.

3F · 2019-04-07T22:47:23Z

@mrexodia What do you think about dynamic referencing to the new Microsoft.Build.dll implementations? (from GAC, official NuGet packages, custom paths)

I think this is more right way for our case because these problems are directly related to specific MS implementation. I mean, there is not because of target platforms. (mainly)

Unfortunately, they implements Project 'as is' without any abstraction layer. But my idea is still to use an Project type from GAC just for an runtime binding. However, with leaving options for loading new implementation at runtime and without hard class inheritance.

Something similar I was already implementing in my old vssbe projects, but there was through common interface as basic abstraction for all their components.

Also, I did not test this way, but seems the main problem probably will be for an compatibilities of specific Project's implementation (I remember some incompatible changes with their methods from different dlls). But more probably it will help better. Hmm,

tl;dr for end users the question is related to optional requirements for definition path to custom Microsoft.Build.dll (+ all its dependencies).

Probably some of this can be also encapsulated to search from GAC by version, for example from latest netfx 4.7.2 and so on. But mainly, this will require additional user logic for including something other (from nuget, or GAC etc)

mrexodia · 2019-04-08T13:26:24Z

Hey,

For me it doesn't matter too much anymore to be honest... I wouldn't be opposed to updating the target framework version, since this stuff is all running on whatever environment I want anyway. However, recently we dropped UWP support so I guess it won't be an issue anymore going forward...

Thanks for the follow up though, your library has been (and is) tremendously useful for us and I will try to get some appreciative donation in your direction 💯

3F · 2019-04-08T14:57:48Z

@mrexodia I see, thanks for the info. I'm also glad that's still helpful tool :)

Well anyway, I'll consider new way later for future .net core distr etc.

3F added bug 3rd-party labels Aug 4, 2018

This was referenced Aug 4, 2018

C++ projects and their initialization via Microsoft.Build.Evaluation #1

Closed

Support SDK-based projects #2

Open

Microsoft.Build.dll for .netfx 4.0 dotnet/msbuild#3581

Closed

Unable to load Xamarin Project... #4

Open

3F mentioned this issue May 14, 2019

Please support .NET Core #11

Closed

This was referenced Oct 11, 2019

SDK-based project with new target platforms #21

Merged

Drop MSBuild #23

Open

3F added this to the 3.0 milestone Nov 6, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Cannot load UWP projects #5

Cannot load UWP projects #5

mrexodia commented Jun 18, 2018

3F commented Jun 18, 2018

mrexodia commented Jun 18, 2018

3F commented Jun 18, 2018 via email

3F commented Aug 4, 2018 •

edited

Loading

mrexodia commented Aug 4, 2018

3F commented Aug 4, 2018

3F commented Apr 7, 2019 •

edited

Loading

mrexodia commented Apr 8, 2019

3F commented Apr 8, 2019

Cannot load UWP projects #5

Cannot load UWP projects #5

Comments

mrexodia commented Jun 18, 2018

3F commented Jun 18, 2018

mrexodia commented Jun 18, 2018

3F commented Jun 18, 2018 via email

3F commented Aug 4, 2018 • edited Loading

As for temp solution

mrexodia commented Aug 4, 2018

3F commented Aug 4, 2018

3F commented Apr 7, 2019 • edited Loading

mrexodia commented Apr 8, 2019

3F commented Apr 8, 2019

3F commented Aug 4, 2018 •

edited

Loading

3F commented Apr 7, 2019 •

edited

Loading