Open mrexodia opened 6 years ago
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 - https://github.com/3F/MvsSln/issues/4#issuecomment-393169746
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!
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 https://github.com/3F/MvsSln/issues/5#issuecomment-398203439, or mute the thread https://github.com/notifications/unsubscribe-auth/ADGJ_bv2HF0zau9SaROCwNYmN_hRk8K_ks5t-B0egaJpZM4UsaCI.
@mrexodia I've checked this problem through other version - Microsoft.Build.dll v15.7.179
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.
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
Set AutoGenerateBindingRedirects property for host project because of different Microsoft.Build.dll:
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
Use MvsSln as before.
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...
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.
@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)
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 💯
@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.
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:
Exception: