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 integration #306

Closed
bdbai opened this issue Aug 6, 2020 · 3 comments
Closed

MSBuild integration #306

bdbai opened this issue Aug 6, 2020 · 3 comments
Labels
question Further information is requested

Comments

@bdbai
Copy link
Contributor

bdbai commented Aug 6, 2020

This project brings the capability for interop between Windows Runtime and Rust, where most of the tasks are done through Rust-native features and Cargo. However in some cases, Visual Studio, or MSBuild precisely, must be used. Consider some scenarios:

  • XAML compilation. I did a quick search, and it turned out the internal processor is tightly coupled with languages. It seems non-trivial to workaround in a Rust Cargo project. The only thing I can do is to create a new C# or C++/WinRT UWP application with Visual Studio and extract generated *.xbf files.
  • Application packaging and signing. These tasks could be achieved by executing command line tools, but in a complicated and error-prone way.
  • Inside a Solution. Since MSBuild is unaware of Rust Cargo projects, it could be confusing when someone Cleans and Rebuild the whole Solution but Rust projects remains unchanged.

Actually I am not sure whether this issue is directly related here or Visual Studio, or both. Are there any plans or roadmaps regarding this issue on winrt-rs side?

@bdbai bdbai changed the title MSBuilt intergration MSBuild intergration Aug 6, 2020
@bdbai bdbai changed the title MSBuild intergration MSBuild integration Aug 6, 2020
@rylev rylev added the question Further information is requested label Aug 6, 2020
@kennykerr
Copy link
Collaborator

@bdbai these are good questions.

Regarding the Xaml compiler, I have been told that the Xaml compiler was recently refactored to be a standalone tool that is not directly tired to msbuild. Of course, the Xaml compiler hardcodes knowledge of supported languages like C# and C++ and would not be useful to Rust developers without substantial investment. I have been in discussions with the Xaml team and we are hopeful that we can come up with a solution that is native and familiar to Rust developers that does not involve the Xaml compiler directly. Rich Xaml support would be provided directly by the winrt crate (this project).

Regarding packaging and signing, the command line tools may be complicated but not nearly as complicated as adding Rust support to msbuild or adding msbuild support to Rust. I believe we can provide build tools that wrap these tasks up in a convenient way for Rust developers. This will likely be a part of the cargo winrt tool's expanded role in future.

I am strongly apposed to getting involved with msbuild as that technology is squarely focused on .NET and has very poor support for other languages including C++.

Regarding Visual Studio solutions, this is not really something that is specific to this project. The Visual Studio team may eventually decide to add support for Rust projects, but I haven't heard any such announcement so we are continuing on the assumption that VS Code is the preferred way to manage Rust projects. Even if they do eventually add some level of support, it would only be in the way of adding IDE support for things like Cargo build/check/test/etc. and not an alternative to the to the Rust toolchain.

Hope this helps.

@bdbai
Copy link
Contributor Author

bdbai commented Aug 6, 2020

@kennykerr thanks for the inspiring answer. It will be cool to use cargo alone through cargo winrt for UWP application development.
Besides, will Xaml hot reload ever be possible in VS Code with this project? Probably a VS Code extension is necessary to compensate for the functionalities provided in VS?

@kennykerr
Copy link
Collaborator

Hot reload is an important feature for a modern UI stack so I imagine that will be a part of the story, but it's a little early to speculate on exactly what that might look like. Right now I'm focused on #81, which is a large prerequisite for all of these features.

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

No branches or pull requests

3 participants