Modern project system support

[clairernovotny]

VS 2017 has the CPS project system available, a fully managed replacement to the legacy project systems before. It's the one .NET Core and .NET Standard projects default to, and the ones that have the "ultralight" syntax. Virtually nothing needs to be in it since everything needed is provided by an "SDK" set of targets/props. The "project file" would essentially be mostly blank. The implicit properties would exclude the target, .vs, and other . directories as is common in VS -- not showing build artifacts in the IDE.

It would be really nice if Rust was supported in this way. I imagine that a set of Rust targets could be created that are mostly wrappers around cargo to do the build.

This would be different than the VS 2015 approach, but I believe is ultimately cleaner and faster.

I suspect that someone from @davkean's team could provide some guidance as to how to do this. The project system itself is open source: https://github.com/dotnet/project-system

[Boddlnagg]

Thank you for this suggestion! However, VisualRust is already based on the Common Project System since this PR. No new version has been released since then, though ...

Apart from the Common Project System, is the "dotnet project system" that you linked helpful for us? I would have assumed that it is rather specific to the .NET ecosystem.

[clairernovotny]

Didn't realize it was already CPS, that's great!

The other parts are not .NET specific. It's much more about orchestrating MSBuild (to the tiny extent it may invoke the cli commands you need. It also helps control what shows up in the solution explorer, since right now it appears that the "gunk" folders show up too.

It may be possible to show the crates as dependencies in the solution explorer as well, much like it shows NuGet packages for net.

[clairernovotny]

To add a bit more, I guess my idea, if it doesn't already exist here (and I didn't see it, so my apologies if it does), is to create an rsproj project type. That would use a Rust.SDK Sdk= type on the project file. Not much would need to be in that file, as the Sdk.props and Sdk.targets would have most of it as part of the tooling/VSIX.

That would enable msbuild /t:build of rust projects, just like it works for C#, F#, C++, TypeScript, etc. The targets would do essentially what you do now and invoke the right cli tools for building/linking a project and passing in the right parameters as appropriate.

This is not to say that Congo.toml is in any way replaced, this is just augmenting that with and msbuild wrapper. This opens up many scenarios where you'd have a solution with many projects that need to be built. One of those might be a rust library or executable that gets used by some other project (non-rust) in the solution. This would make that very easy for users to do.

Happy to discuss this further in whatever forum works for you.

[Boddlnagg]

I'm happy to discuss this here, but it's @vosen who leads the design of this project so I can't really make any decisions here.

I built the project system based on CSP when it was not final yet, and under the constraint that VS2015 should still work (in fact, VS2017 wasn't even released back then). I don't know what has changed since then in the CSP, and I'm not sure whether VS2015 compatibility is a requirement for us now.

An rsproj project type already exists, and it was modeled based on what RTVS does (or did when this was implemented). This includes an msbuild wrapper (see src/VisualRust.Build). Maybe you could link to some documentation of the Sdk= type, because I don't know what that is (maybe it didn't exist yet when I was doing this).

[clairernovotny]

Couple questions -- and I'll do some more digging -- how do I create a new rsproj file? I have the latest CI build from AppVeyor in 2017 (the build was from a couple months ago...?). I didn't see a Rust project type anywhere when I looked.

Based on what I see in files like https://github.com/PistonDevelopers/VisualRust/blob/master/src/VisualRust.Build/VisualRust.Rust.targets, making those into an "SDK" style project should be easy... those would go into a NuGet package effectively.

One key thing is that the VSIX/Editor support shouldn't be needed for builds; one example to look at is how the Microsoft VSTest SDK works: https://github.com/Microsoft/vstest/blob/rel/15.3-rtm/src/package/nuspec/Microsoft.NET.Test.Sdk.nuspec

The difference in what an SDK is, just that SDK is shipped in another location, like C:\Program Files\dotnet\sdk\2.0.0-preview2-006497\Sdks. I'll follow-up with what the search paths for that are, but it's not dependent on NuGet or .NET. It's about simplifying the project system.

I also think it'd be possible to update the VisualRust.Build to work with .NET Core build as well, so the project would work with dotnet build. dotnet build would run the msbuild tasks, which would then invoke Rust, etc.

[Boddlnagg]

If nothing has changed since I've implemented these things, whenever you open a Cargo.toml file the corresponding rsproj file should be generated in the same directory. I haven't tested this myself for a while, though.

Not needing to install the VSIX for builds and also supporting .NET Core builds sounds like things that we should aim for ... so it sounds like a good idea overall!

[Boddlnagg]

@MaulingMonkey Maybe you want to chime in, you have worked with the code more recently 😉

[MaulingMonkey]

It may be possible to show the crates as dependencies in the solution explorer as well, much like it shows NuGet packages for net.

Tracked by #3 AFAIK - still needs implementation.

how do I create a new rsproj file?

Latest official appveyor master branch builds are missing the project and item templates AFAIK. There is a build of my unofficial, pending review pull request, which adds the project and item templates back into the vsix. I haven't tried auto-creating them via opening Cargo.toml - wasn't aware that was an option.

https://ci.appveyor.com/project/MaulingMonkey/visualrust/build/job/bgfigmcko2211nin/artifacts (same link as the other issue - if you do want to try it out, you'll want to uninstall the previous version (twice! via Visual Studio's "Extensions and Updates", and then via Windows's "Programs and Features") before installing mine.)

One key thing is that the VSIX/Editor support shouldn't be needed for builds;

I know the msbuild integration is part of the installer, not the vsix. I haven't actually tried building via the command line, but I have the vaguest of recollections (possibly imagined) about building with the vsix manually uninstalled. If there are issues, it might just be a matter of things being bundled into the wrong binary currently?

I'm a novice when it comes to visual studio extension and don't quite follow your suggestion. Are we talking about moving the msbuild integration into a .nupkg instead of requiring an installer? Does that work when the .rsproj presumably needs to be parsed to pick up nuget dependencies?

I also think it'd be possible to update the VisualRust.Build to work with .NET Core build as well

That certainly sounds reasonable enough - I haven't touched .NET Core though, I'm in a poor position to make those changes myself (wouldn't know how to properly test.)

[clairernovotny]

I've been digging more and it looks like the FileMirroring bits of the project system were based on some older ProjectK/Cordova stuff. A lot of that code can be removed in favor of using a UseFileGlobs capability and declaring the globs in a props file. Those capabilities came later and are VS 2017+.

The globs have to be in a props file and not a targets to work correctly. This may help address the issues many people have reported around having to "Show all files", etc.

Docs on the globbing support are here: https://github.com/Microsoft/VSProjectSystem/blob/cf4e91a6304ca19b76ef1798574cbe5e305ac298/doc/overview/globbing_behavior.md

[MaulingMonkey]

Interesting. Could certainly get rid of a lot of code if/when we ditch VS2015 support. I've used globs as far back as VS2012, but the lack of proper VS support was... problematic. Suffice it to say I learned new and interesting ways to crash Visual Studio, which at the time were WONTFIXed.

[clairernovotny]

It's certainly not my call, but given the current state of the VS integration and how much better things are going forward, I would strongly suggest a quick divorce from VS 2015. VS 2017 is a free upgrade for most people (or just free with the Community edition). Why hamstring yourself to support older versions when you can make a really solid Rust VS integration using the current tooling?

Just my thoughts though.

[clairernovotny]

It also looks like we can properly deploy an SDK to the right SDK directory within VS to make this seamless. From a snippet someone sent me:

<ItemGroup>
    <VSIXSourceItem Include="{PathToDirectoryContainingProps}\**\*.props">
      <InstallRoot>MSBuild</InstallRoot>
      <VSIXSubPath>{MSBuildSubDirectoryToInstallTo}</VSIXSubPath>
    </VSIXSourceItem>
    <VSIXSourceItem Include="{PathToDirectoryContainingTargets}\**\*.targets">
      <InstallRoot>MSBuild</InstallRoot>
      <VSIXSubPath>{MSBuildSubDirectoryToInstallTo}</VSIXSubPath>
    </VSIXSourceItem>
  </ItemGroup>

The idea here is that we could create a Rust.SDK structure of props/targets/tasks and then the VSIX would put them in the right place.

The rsproj would look something like this:

<Project Sdk="Rust.SDK">
  
</Project>

The props are auto imported before the project and the targets after. No need for anything else if the right implicit stuff is present.