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
218 stars 83 forks source link

dotnetcore behaviour #91

Closed VistianOpenSource closed 1 year ago

VistianOpenSource commented 4 years ago

I'm currently trying to use Rosyln to analyze projects (in this case Xamarin Android) as a console app ,but if my solution to do this is based on dotnetcore it doesn't appear to function correctly.

When I compare the behaviour of getting the VisualStudioInstance to RegisterInstance , I am seeing differing values returned from QueryVisualStudioInstances. The net48 solution correctly returns:

{Microsoft.Build.Locator.VisualStudioInstance} DiscoveryType: VisualStudioSetup MSBuildPath: "C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\MSBuild\Current\Bin" Name: "Visual Studio Enterprise 2019" Version: {16.7.30310.162} VisualStudioRootPath: "C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview"

the dotnetcore base solution however returns

{Microsoft.Build.Locator.VisualStudioInstance} DiscoveryType: DotNetSdk MSBuildPath: "C:\Program Files\dotnet\sdk\3.1.400-preview-015203\" Name: ".NET Core SDK" Version: {3.1.400} VisualStudioRootPath: "C:\Program Files\dotnet\sdk\3.1.400-preview-015203\"

Now, whilst this may be a question/issue for the Roslyn tools, when I try and use the correct MSBuildPath by calling RegisterMSBuildPath for the dotnetcore solution, I then get an error when I try and Emit the result of a compilation which says

Could not load file or assembly 'System.Configuration.ConfigurationManager, Version=4.0.3.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. The system cannot find the file specified.

As far as I can see, this type isn't available for dotnetcore applications.

rainersigwald commented 4 years ago

Those results look fine to me. What are you expecting to be different?

when I try and use the correct MSBuildPath by calling RegisterMSBuildPath for the dotnetcore solution

When you say this, what do you mean exactly?

VistianOpenSource commented 4 years ago

Hi, perhaps I should have been a bit clearer, so let me try again.

Looking at the the single VisualStudioInstance I get back from calling QueryVisualStudioInstances, I get the differing results I've shown above if the application performing the calls is targeting net48 or dotnetcore.

If I then try and register either this VisualStudioInstance with RegisterInstance before then using MSBuildWorkspace.Creare to get a workspace to then open a project and then compile it, i get different behaviour between the net48 target and the dotnetcore target.

the net48 target works correctly and the compilation is emitted correctly. For the dotnetcore app it fails with an exception around System.Configuration.ConfigurationManager not being able to load.

Now it may well be that the values shown for the VisualStudioInstances above are both fine (I'm pretty sure though that visual studio isn't in the dotnet\sdk... folder) , but unfortunately I don't have a dotnetcore solution that works for the analysis of a xamarin android project, whereas the same app compiled targeting net48 works fine.

SingleAccretion commented 3 years ago

I am also hitting this exact issue. MSBuildLocator.RegisterInstance(instance) where is instance a .NET Core SDK fails to load the relevant assemblies. The workaround is quite simple (load them manually), but I am not sure how robust it is.

YuliiaKovalova commented 1 year ago

Hi @VistianOpenSource,

Is this ticket still relevant for you?

VistianOpenSource commented 1 year ago

Hi, no, its not relevant to me anymore.

YuliiaKovalova commented 1 year ago

Thank you for letting us know.