Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestion: Allow solution (project) global properties to be controlled via AnalyzerManager #52

Closed
IanKemp opened this issue Jun 1, 2018 · 4 comments · Fixed by #59
Closed

Comments

@IanKemp
Copy link

IanKemp commented Jun 1, 2018

I have a situation in which I'm loading a Web Application project using .NET Core. The following lines in that project type are problematic:

<VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>

<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />

Since VSToolsPath is undefined and MSBuildExtensionsPath32 is set to C:\Program Files\dotnet\sdk\<version>, MSBuild ends up trying to load C:\Program Files\dotnet\sdk\<version>\Microsoft\VisualStudio\v$(VisualStudioVersion)\WebApplications\Microsoft.WebApplication.targets, which obviously doesn't exist (that file resides in the Visual Studio install directory). This causes AnalyzerManager.GetWorkspace() to blow up.

I've (very nastily) worked around this by calling Environment.SetEnvironmentVariable("VSToolsPath", <path_to_necessary_directory>), but the issue would be totally avoided if I could somehow pass these values to AnalyzerManager when constructing it or calling GetWorkspace(). Unfortunately, Buildalyzer currently doesn't expose the global/environment variables it sets to allow for mutation, so that's not an option - but I propose it should be! :)

@daveaglick
Copy link
Collaborator

This is a great idea for the general case.

I wonder if in this specific case we should be setting VSToolsPath for everyone though?

@IanKemp
Copy link
Author

IanKemp commented Jun 1, 2018

I thought about that, but this is a very special edge case (loading a Framework project in Core) - I feel that setting any property to reference the Visual Studio directory for a Core run is likely going to trip someone else up at a later stage. Hence, the more general request.

@daveaglick
Copy link
Collaborator

Gotcha, makes sense. I'll add the ability to specify additional environment variables and MSBuild properties in the next release (not sure when that'll be though).

@dfederm
Copy link
Contributor

dfederm commented Jun 23, 2018

@IanKemp Note that ProjectAnalyzer does already have a SetGlobalProperty method you can call before calling Load or Compile. Does that help?

I still think it may be worthwhile to have this at the AnalyzerManager level as well though. IE, use AnalyzerManager.SetGlobalProperty to set it for all future projects, and use ProjectAnalyzer.SetGlobalProperty to set it for one specific project.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants