This issue is in the open design phase and is a part of the project.json -> csproj conversion effort.
Can we remove:
Open Issues
Note: there is much improvement to be done in the default template for MSBuild projects that does not involve Core MSBuild changes.
Another thing we can do here is demote this message
Project file contains ToolsVersion="". This toolset may be unknown or missing, in which case you may be able to resolve this by installing the appropriate version of MSBuild, or the build may have been forced to a particular ToolsVersion for policy reasons. Treating the project as if it had ToolsVersion="15.0". For
more information, please see http://go.microsoft.com/fwlink/?LinkId=293424.
To a much lower verbosity.
Or remove the ToolsVersion warning entirely.
What point is the ToolsVersion warning, when you ignore it now?
Yeah, I'm convinced that we should get rid of it entirely.
@AndyGerlicher thoughts? ^
Just a quick 2垄 on this issue: I highly suggest _not_ removing the XML namespace, as that is what enables Visual Studio鈥檚 excellent XML IntelliSense support. Whenever I hand-edit MSBuild, I rely on this IntelliSense to keep me sane and highly productive. (Hard-coding *.csproj et al in VS to enable this IntelliSense is also a bad idea, by the way, because MSBuild files don鈥檛 always have a "recognized" extension, or even follow the *.*proj naming convention.)
Just a quick 2垄 on this issue: I highly suggest _not_ removing the XML namespace, as that is what enables Visual Studio鈥檚 excellent XML IntelliSense support. Whenever I hand-edit MSBuild, I rely on this IntelliSense to keep me sane and highly productive. (Hard-coding
*.csprojet al in VS to enable this IntelliSense is also a bad idea, by the way, because MSBuild files don鈥檛 always have a "recognized" extension, or even follow the*.*projnaming convention.)
@davkean, can you comment on what the intellisense experience will be like if you open an MSBuild file that doesn't have the XML namespace in it in Visual Studio?
FWIW, I'm not sure I've ever found the IntelliSense with the XSD to be useful as it only works for the elements defined in the XSD, which is a pretty tiny subset of what's actually available, and very rarely what I need.
I actually ended up writing my own code completion engine for Xamarin Studio :)
If I open page with xmlns: http://schemas.microsoft.com/developer/msbuild/2003 I get error: The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.
@mhutch True, but it鈥檚 better than nothing. Interestingly, the MSBuild schema is split over three files (the "core" MSBuild items, the items provided by in-box VS extensions, and a third that is mostly empty). This mostly empty schema is there so you can add your own properties/items and have them picked up by Visual Studio. Unfortunately, this file is machine-global and requires Administrator privileges to edit (not to mention it could be overwritten at any time by a VS update), so it鈥檚 not an ideal solution. I suppose if you add the MSBuild schemas from this repo locally, you could edit them without any problems, but Visual Studio might give you grief regarding which schema to use (the one in the solution or the one installed by VS).
@mfilippov That is to be expected. XML namespaces very rarely point to actual Web resources, even though they almost always look like they would. There is a file installed by Visual Studio that maps XML namespace strings to the XSD schema files that define the valid syntax for that namespace.
Right, but the best way is to scan the targets and build completion from that :)

The JSON editor in Visual Studio provides a pretty reasonable approach to mapping schemas to instance documents without namespaces.

It seems to sniff the document and detect the schema and if it can't, you can pick from a list of schemas VS knows about.
MSBuild should arguably have support in a class of it's own either way. That's something that's been lacking for a while.
We planning on addressing this so that you can still get IntelliSense, https://github.com/dotnet/roslyn-project-system/issues/516 is tracking it.
Most helpful comment
Right, but the best way is to scan the targets and build completion from that :)