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

MSBuild support #202

Closed
davidfowl opened this issue May 1, 2015 · 4 comments
Closed

MSBuild support #202

davidfowl opened this issue May 1, 2015 · 4 comments

Comments

@davidfowl
Copy link
Member

Our msbuild project file support is shaky at best, This is an item to keep track of the pending work and challenges involved.

The problems:

  • Differences between xbuild and msbuild (maybe we can get the oss msbuild building and running on mono to replace xbuild)
  • Using the "right" version of msbuild
  • Modifying the project file in a way that round trips with VS
    • Adding references

Hard/Impossible to fix:

  • SDKs that aren't installed
  • Customizations made to project files that require context (properties). Maybe we can solve this with configuration?

Brain dump from conversation with msbuild expert:

  • VS 2012 and earlier (4.X): Uses the project ToolsVersion unless that ToolsVersion does not exist, in which case it falls back to 4.0
  • VS 2013 and later (12.0+): Uses the "current" ToolsVersion (same as the engine, so 12.0 on msbuild 12, 14.0 on msbuild 14)
  • The engine and tasks both have to run against the same version of the framework (*Microsoft.Build.Framework.dll, that is')
  • The Tasks and Utilities assemblies are versioned in the file name, but that doesn't really matter as long as the version of M.B.Framework matches
@AndersNS
Copy link

AndersNS commented May 8, 2015

Detecting the correct target platform needs to be done too. Omnisharp-roslyn seems to default to x86 for me. I worked around this by adding { "Platform", "AnyCPU"} the properties dictionary used by omnisharp-roslyn when creating a ProjectCollection.

Without this I got this error:

[ERROR:OmniSharp.MSBuild.MSBuildProjectSystem] The OutputPath property is not set for ? project 'NameSpace.CoolProject.csproj'. Please check to make sure that you have specified a valid combination of Configuration and Platform for this project. Configuration='Debug' Platform='x86'.

@nanoant
Copy link

nanoant commented May 12, 2017

I was today struggling with getting our MSBuild (VS 2015) projects to work with OmniSharp-roslyn, basically because it somehow defaults to $(Configuration)=Debug and $(Platform)=AnyCPU, but such platform does not exist neither in solution or project.

I have managed to get rid of the error simply settings the platform in ProjectFileInfo::Create to { "Platform", "x64" }, but this is really hackish way.

Is there any other, more elegant, probably via config.json way to set the platform?

@DustinCampbell
Copy link
Contributor

Most MSBuild files default to $(Configuration)=Debug and $(Platform)=AnyCPU if they're not specified. I think we need a way for an OmniSharp host to change a project's Configuration and Platform dynamically (maybe some endpoint). This is also needed to set TargetFramework for multi-targeting projects.

nanoant pushed a commit to nanoant/omnisharp-roslyn that referenced this issue May 15, 2017
This allows choosing other (than default) MsBuild configuration, e.g.
MsBuild:Configuration=Release MsBuild:Platform=x64, especially usable
for projects that are not using default (AnyCPU) platforms.

This relates to OmniSharp#202.
jmbeach pushed a commit to jmbeach/omnisharp-roslyn that referenced this issue Dec 17, 2017
@filipw
Copy link
Member

filipw commented May 13, 2020

I will close this issue as outdated. The msbuild support is much better since and many of the issues here have been addressed. There is a comprehensive look up process (bundled msbuild, mono msbuild, VS msbuild etc.). xbuild support has been dropped and there is a config setting to provide custom msbuild if needed. Nuget SDK resolver support has been added too giving support for Arcade, QDK and other custom SDK.

For the persisting problems, we have individual issues open.

@filipw filipw closed this as completed May 13, 2020
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

No branches or pull requests

5 participants