Closed DannyAllegrezza closed 4 years ago
I'll try it out if I can, after figuring out where to even obtain Visual Studio 2019.
Ah, let me downgrade it back to 2017.
Seems like everything is still working in 2017 at the moment - I'm installing 2019 right now.
Just realized the same thing, 2017 seems to open it fine. Can you let me know if the 1 unit test I added (which asserts nothing, I know) works? You should be able to add a break point on the unit test, then right click and Debug to step through the code.
I don't know what happens when I click Debug Test(s)
but it doesn't look like it works properly
testhost.x86.exe just exists with code 0
, and no breakpoints are triggered
Try to click on "Test" and then "Show Test Explorer" to bring the Test Explorer window. From here, you should be able to at least run it. You might not be stepping into (F10) the actual method.
This might be sorta helpful?
EDIT: If that doesn't work I can change the test project to NUnit or a different test runner.
Also, this does not help
For reference, I'm testing using Office 365 ProPlus
{System.Diagnostics.FileVersionInfo}
Comments: ""
CompanyName: "Microsoft Corporation"
FileBuildPart: 12026
FileDescription: "Microsoft Word"
FileMajorPart: 16
FileMinorPart: 0
FileName: "C:\Program Files\Microsoft Office\root\Office16\WINWORD.EXE"
FilePrivatePart: 20344
FileVersion: "16.0.12026.20344"
InternalName: "WinWord"
IsDebug: False
IsPatched: False
IsPrivateBuild: False
IsPreRelease: False
IsSpecialBuild: False
Language: "Language Neutral"
LegalCopyright: ""
LegalTrademarks: ""
OriginalFilename: "WinWord.exe"
PrivateBuild: ""
ProductBuildPart: 12026
ProductMajorPart: 16
ProductMinorPart: 0
ProductName: "Microsoft Office"
ProductPrivatePart: 20344
ProductVersion: "16.0.12026.20344"
SpecialBuild: ""
That's a bummer. If I had Office installed I'd be glad to help debug further. Just curious, when you ran my branch what did it show in Discord? I'm guessing it finds 16
and so it would now return 2016
?
It didnt find anything so it just selected 2016 as before
Bummer. I guess I'll close this for now.
This commit is an idea for a temporary workaround the weird path location from Office apps.
Since I do not have any actual Office exe's installed, I can't really test this stuff out. I've added a new unit test project so this repo can have some unit tests. This makes it a lot easier to debug and exercise the
Shared
class.A couple of other thoughts:
PascalCasing
instead ofcamelCasing
. I renamed one method to follow the standard convention.GetVersion()
is currently pretty much impossible to test because it reaches out to grab dependencies on theProcess
object. You might want to consider having this knowledge encapsulated to each class lib, then refactorGetVersion
to take in this lib specific knowledge as a parameter and then it could figure things out. But having the Process.GetCurrentProcess() inside of this method makes it very hard to test. For example, when I debugged it, it gave me the version of Visual Studio running 💯https://docs.microsoft.com/en-us/office/troubleshoot/office-developer/find-office-installation-path
https://docs.microsoft.com/en-us/office/troubleshoot/reference/numbering-scheme-for-product-guid