Find ms build using setup config

[A9G-Data-Droid]

After trying the latest version mentioned in Issue #13 I was getting the error seen in Issue #17 . So I took a deep dive. I started out just fixing the code that attempts to find MSBuild.exe but I ended up finding some problems along the way. I apologize for the large PR but I got all tangled up, as I do when looking at a new source base.

When I was done I compiled a new release, installed it, and ran "Resolve Unused References" against the project itself. This both cleaned up unused references in this project but also proved out the new version. "Eat your own dog food."

Closes #12
Closes #13
Closes #17

NEW

• Add new method for finding MSBuild.exe
• Add new Unit Test for MSBuild.exe method so you can test if it works!
• Every time you delete something set attributes to normal to avoid read-only errors.

CHANGES

• Open solution in VS2019
• Update Framework to 4.7.2
• Add Constants path for "Current" version of MSBuild
• If the new method to find MSBuild fails, fall back to old ways
• Fix capitalization warnings
• Add test Project to prove the MSBuild methods
• Fix Namespace problems
• Fix naming conflict with VisualStudioPackage
• Migrate from legacy analysis (FxCop) to source analysis (FxCop analyzers)
• Resolve all FxCop Errors, Warnings, and Messages
• Resolve security warning about unsafe handling of XML reader
• Run "Resolve Unused References" against self #DogFooding
• ResolveUROptions are now properties
• Normalize line endings (Some files were not consistent)
• Make static when possible

[cYCL157]

I was hopeful that this build would resolve the issue i have with resolveur in vs2019 with a .net core 3.1 project, but i still have the same issues as #17 with a new build of the vsix on my machine and installed after removing the current gallery version.

To potentially make things easier to replicate, here is one of the repos that i tried to test this on (others being private repos):
https://github.com/cortside/cortside.webapistarter

@A9G-Data-Droid -- If there is something more I can do to test, i'd be happy to as I am interested in seeing this fixed.

Here are my msbuild.exe locations, if that is the issue:

C:\Program Files (x86) [nonprod]> cmd /c dir msbuild.exe /s
Volume in drive C is Windows
Volume Serial Number is 88BA-BDB2

Directory of C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin

10/03/2019 09:17 PM 319,032 MSBuild.exe
1 File(s) 319,032 bytes

Directory of C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\amd64

10/03/2019 09:17 PM 318,000 MSBuild.exe
1 File(s) 318,000 bytes

Directory of C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin

12/15/2020 08:22 PM 328,072 MSBuild.exe
1 File(s) 328,072 bytes

Directory of C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\amd64

12/15/2020 08:22 PM 327,552 MSBuild.exe
1 File(s) 327,552 bytes

Directory of C:\Program Files (x86)\MSBuild\14.0\Bin

07/06/2015 11:51 PM 326,304 MSBuild.exe
1 File(s) 326,304 bytes

Directory of C:\Program Files (x86)\MSBuild\14.0\Bin\amd64

07/06/2015 11:18 PM 322,208 MSBuild.exe
1 File(s) 322,208 bytes

[A9G-Data-Droid]

@cYCL157 The new method I added uses the last version of MSBuild found because on my system, this was the newest. On your system it looks like version 14 is the last one listed. Due to the way the msbuild path has changed over the years it can be difficult to locate the right one. The new method I added is what is recommended by Microsoft. I haven't found a way to detect the version of Visual Studio running and select that one. That is the missing code at this point to complete the MSBuild finder.

[cYCL157]

i would have to look closer at the code, but the msbuild.exe with the most current date is the one from the vs2019 enterprise directory, which is likely the one that needs to be used as opposed to last one in the list based on path name. i will see if i can find some time today to take a look.

[cYCL157]

@A9G-Data-Droid This change did it for me -- the order of the installations was vs2019 first and vs2017 second.

https://pastebin.com/xTgVuEUe

You can use that to recreate, i can commit somewhere, however you would like -- if you think that will solve the issue.

FYI -- the new test worked great in being able to figure that out!

[A9G-Data-Droid]

Thanks @cYCL157 ! Testing for the win. Using the latest version sounds like what I would want to do normally, but what happens when you open an older version of Visual Studio? Wouldn't you be using the 2019 build from 2017, for example? Seems like a dangerous situation. All the methods we have used so far have this problem, so I have no problem adding your code. Just that I don't think it's a complete solution to this problem. We are so close!

[A9G-Data-Droid]

NOTE: This is the version I have installed on my system as a daily driver because the one in Nuget doesn't work. It's been working fine on VS2019.

[cYCL157]

Yep -- same here, been using my own build of this branch and it has been working well since last december.