search

microsoft / MSBuildLocator

An API to locate MSBuild assemblies from an installed Visual Studio location. Use this to ensure that calling the MSBuild API will use the same toolset that a build from Visual Studio or msbuild.exe would.
Other
220 stars 83 forks source link

Fix VS update to 15.6.1 case #19

Closed vicancy closed 6 years ago

vicancy commented 6 years ago

Fix #17

vicancy commented 6 years ago

Thanks @heaths, could you share where to get the formatted error log? Is it ISetupInstance2.GetErrors()? It only contains GetFailedPackages however no error messages in there.

heaths commented 6 years ago

QI on ISetupErrorState returned from GetErrors for for ISetupErrorState2 and you can call GetErrorLogFilePath.

vicancy commented 6 years ago

Thanks @heaths It looks working although the log does not exist in my local machine, probably got cleaned up.. Is there any additional error code to indicate if the failure is a fatal one or not?

Hi @rainersigwald , what's your opinion? Looks like I ran into this state because some packages failed to install, It CAN be packages with minor features that does not affect VS running, it can also be packages that affects the core feature of VS. In my case, it is some minor feature that fails. Do you think it is more accurate to return the instance if it is Registered and meanwhile return the error message? image

heaths commented 6 years ago

If the failure if vital failure (failure in a vital package, for which there are few) the Registered state should not be present.

heaths commented 6 years ago

The path - apart from having the version number in it despite now being part of Visual Studio - is fixed. It hasn't changed structure in many years. Did you take a look at my sample on the vswhere wiki? You could codify that.

rainersigwald commented 6 years ago

@heaths I meant that this assembly/repo exists to make it easier to use this than to keep manually constructing environment variables hard-coded to C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin that screw up all your hard work on the setup side. Since that is extremely permissive with respect to VS install state, I think we should be too--it's still strictly better this way.

heaths commented 6 years ago

I wasn't arguing against this repo. I'm saying that I don't think constructing the path based on a fixed directory structure is naïve. I was referencing this example as an approach to constructing paths, though I realize (now that I'm typing from my phone) it wasn't the sample I was thinking of. I wrote one once (maybe it was in an email) that basically took the major version component of the InstallationVersion of the found instance and used it in the path, e.g. "MSBuild\.0\Bin\MSBuild.exe". MSBuild has used that directory structure for many years and I doubt would change based on internal conversation on this very topic.