Describe the bug
In this line, base file is deleted after passing to the merge service. This can cause problem as the editor provides features such as compare with base file. Actually clicking compare with base file in IDL Merge would show dialog saying the base file doesn't exists.

To Reproduce
Steps to reproduce the behavior:

1. Right click any idle file and click update header file
2. Click compare -> compare with base file
3. See error dialog.

Expected behavior
Can compare with base, no error dialog shown.

Screenshots

Additional context
Suggest the extension just leave the temp file alone, and purge 3-days-old files regularly. A solution to mitigate file bloat is to use the same file name as the idl so that repeatedly updating header file only generates one temporary.

Describe the bug
Support A.idl depends on B.idl, clicking generate header file for A would cause cppwinrt to complain in build log B is not found.

To Reproduce
Steps to reproduce the behavior:

1. Add an idl file A.idl
2. Add another idl file B.idl
3. Add import "B.idl" in A.idl
4. Click generate header in A.idl
5. Observe failure message in status bar

Expected behavior
Header file for A.idl can be generated

Screenshots
N/A

Additional context
N/A

Describe the bug
Right clicking on an idl file in solution explorer and clicking on "Update Header File..." produces the error "Error generating header file. Make sure project builds"
My project builds fine.

Opening the developer command prompt, I can execute cppwinrt. Version displayed in the cmd prompt is : C++/WinRT v2.0.201201.7

Are there any logs perhaps that could help with debugging this issue?

Namespaces shouldn't highlighted in light blue for consistency with C++. It should be just in black.

MIDL 3 supports structs to define WinRT PODs. Currently, the extension doesn't highlight "struct" as a keyword, nor the type name.

Is your feature request related to a problem? Please describe.
As titled. ARM toolchain is going to be ready soon and we should be proactive in supporting that as well.

Describe the solution you'd like
Add ARM64 support.

Describe alternatives you've considered
N/A

Additional context
Noticed it when playing around with the extension manifest

Add support for renaming types defined in IDL eg: a runtime class. While you could use the rename option in the C++ header file, you can't do that in an IDL file when this extension is installed. Includes for the generated files (Class.g.h and Class.g.cpp) should also automatically be updated to reflect the name change.

Describe the bug
As titled.

To Reproduce
Steps to reproduce the behavior:

1. Check out the repo with newline using LF.
2. Run tests
3. Observe lines is just 1

Expected behavior
lines isn't 1

Screenshots

Additional context
N/A

Is your feature request related to a problem? Please describe.
While the update header file approach is great, the git diff editor is a bit overkill. A common workflow of idl editing is just adding a property or two, and it'd be a visual and tooling overhead for user to have to stare at the diff window to look for the properties he wanted.

Describe the solution you'd like
Adding a contextual "Copy $midl-enity to clipboard" command eliminates this overhead completely. Typical user story is that the user just edit the idl -> right click the entity -> click the command -> wait for idl to compile -> see success status -> go back to header file -> paste.

In the long run, it'd be ideal if the extension can understand text selection and copy more than 1 properties/events/class/enum/any midl entities. For now, even just the ability to copy a single entity's definition would suffice.

Describe alternatives you've considered
N/A

Additional context
Since this extension is midl tool, not specifically for C++, ideally the context menu should be able to detect current language, and provide C++ or, say. rust suggestion. As a fallback when the extension could not detect the language, a sub menu in the context menu should always be present and provide a list of supported language for users to choose from.

Implementing this feature with languages other than C++ in mind could potentially help even more people in the future.

I'm currently employing a pattern where there's no header file for a Windows Runtime class - only an IDL and .cpp file. This works as long as you don't need access to the implementation type from another source file. The update header file option can't be used in this situation, it only recognises header files.

Describe the bug
If you indent using tabs instead of spaces, keywords and types aren't highlighted. This issue doesn't exist if the keyword isn't indented.

To Reproduce
Steps to reproduce the behavior:

1. Open an IDL file.
2. Change to tabs mode.
3. See the issue.

Expected behavior
Keywords should be highlighted correctly.

Screenshots

With tabs

With spaces

Additional context
Extension version: 1.0.44.
Visual Studio version: 17.4.0 Preview 5.0 (ARM 64-bit)

Is your feature request related to a problem? Please describe.
One area where the idl editing experience is lacking is formatting. I always have to manually insert space between {get;set;}. The extension now provides smart indent, which is nice, but it'd be more holistic to have a complete formatting tool and use that to implement IDE features.

Having a standalone cli means style can be enforced in CI as well, further completing the idl development experience story.

Describe the solution you'd like

1. Create cli tool midl-format. Whatever features the extension wants to support, must be supported/implemented by the cli.
2. Implement IDE commands via the cli tool.
3. Test formatting features via cli tool.

Describe alternatives you've considered
This is how every other formatter/styler works: Xaml Styler has XamlStyler.Console, prettier extension in vs code uses the prettier cli, there is clang format and dotnet format for C++ and C# respectively.

Additional context
Add any other context or screenshots about the feature request here.

Describe the bug
Update header file log error when success is false and there is output, or when there is an exception. However, there is no error log during the reproduction of e.g. #6.

To Reproduce
Steps to reproduce the behavior:

1. Reproduce any of the update header bugs, e.g. #6
2. Observe no error log in output

Expected behavior
There is error log.

Screenshots
N/A

Additional context
Suggest the code change the error handling/early exit branch to just throw, and the logging code to the throw block.

Is your feature request related to a problem? Please describe.
Right now, the tool assumes usage with C++. While it makes sense, rust/WinRT is a thing and it might be adopted in the future. It doesn't hurt to prepare in advance for such scenarios such that the core infrastructure of this extension doesn't assume the output is always C++.

Describe the solution you'd like
Refactor the code such that the core logic (compile -> parse output -> lookup midl entity to pass to clipboard/pass the whole file to merge tool) is language agnostic. Or at least, can be easily modified to support other languages.

Describe alternatives you've considered
Having one extension with divergent code base with different level of feature support and bugs. E.g. XAML compiler for C++ and XAML compile for C#. It'd be repeating the history if we have midl extension for C++ and midl extension for rust. The goal should be to have one midl extension to rule them all.

Additional context
N/A

First, I'll say that this makes editing MIDL 3.0 much less of a chore. Thank you. I'm still fighting how Visual Studio wants to indent MIDL, but this took a lot of the sting out of it.

Now, for the bug:
Parser has Uint8 instead of UInt8 in the regex. So it fails to highlight the type.

(from a quick look, it also appears to be missing the Char16 type, but I haven't used that type)

Pete

Describe the bug
There are several symptoms for this bugs. Including window tab would switch to IDL Merge but the content doesn't change, unable to close header file that had just been diff-ed, IDL Merge's save confirmation prompt sometimes doesn't show up. These can all be reproduced with the following steps intermittently.

To Reproduce
Steps to reproduce the behavior:

1. Open the header file for the idl
2. Right click the idl in solution explorer and click update header file
3. See git tool shows
4. Close git tool, click don't save (sometimes the save prompt doesn't even show up)
5. See result still saved to the header file, and the file cannot be closed anymore. A dialog would show saying operation failed, unspecified error

Expected behavior

1. IDL Merge window is reliable
2. Can close the header file
3. IDL Merge window would show confirmation dialog always

Screenshots
IDL Merge Window shows up without content
https://user-images.githubusercontent.com/16918354/197330072-1f5c76bb-217e-4f70-afae-dd8c97245817.mp4

Cannot close header file, no save prompt
https://user-images.githubusercontent.com/16918354/197330094-e4238654-a7e8-4731-9a0b-849c8dcea833.mp4
Note - in the last couple seconds I was dragging the VS error dialog saying there was unspecified error, but game bar couldn't capture it.

Additional context
Digging the code and comparing it with the real merge editor workflow, I think the error is in this line: https://github.com/madskristensen/MIDL/blob/master/src/MIDL/Commands/UpdateHeaderFile.cs#L97

Specifically, the project file is passed as left file directly to the merge service. In the merge editor invoked by real merge conflict, it seems the left file is a temporary. As shown in the following screenshots:

Editor invoked by merge conflict, the result file content is out right different from the actual header file

Editor invoked by merge conflict, the file name in save confirmation prompt is a temporary one

IDL Merge editor, save confirmation prompt uses the real file name

The C++/WinRT Visual Studio extension is largely unmaintained and they're not taking in new changes. Meanwhile, there's still a lot to do in terms of improving the developer experience.

Right now, I want to see an extension with the following:

• Clean XAML templates that are truly blank: microsoft/cppwinrt#924.
• Build Metadata option: microsoft/cppwinrt#1266.

I would like to add these to this project instead of making my own as this extension is named "WinRT Tools for C++" and not something like "Syntax Highlighting for MIDL". Will you be willing to take in these features in your project?

Describe the bug
Clicking generate header always rebuild all .idl. This degrades the UX as it's very slow to rebuild everything if the project contains lots of .idl files.

To Reproduce
Steps to reproduce the behavior:

1. Click generate header file.
2. Close merge editor, click do not save.
3. Go to %TEMP%\VSIXIDL\WinReddiT\VSIX_Metadata_Folder\Unmerged to observe winmd's timestamp.
4. Click generate header file again.
5. Observe timestamp of all winmd files at (3) are different.

Expected behavior
At (5), timestamps don't change. IOW, incremental build should work.

Screenshots
N/A

Additional context
N/A

MIDL 3 still requires semicolon after closing brace for a struct or an enum, but not necessary for runtime classes and interfaces. Sounds stupid but this is due to MIDL's legacy. When this extension isn't installed, writing struct or enum with a brace automatically adds the semicolon, but that doesn't happen when is extension is installed.

Describe the bug
The syntax highlighting uses the predefined "Symbol Definition" classification for all Types in the MIDL file. This should be PredefinedClassificationTypeNames.Type instead.

To Reproduce
Steps to reproduce the behavior:

1. Create a MIDL3 file with a runtime class
2. Observe the coloring of the class name (as well as the type of any properties etc...)

Expected behavior
The color of a type matches the default Type.

Additional context
I was not able to find the actual setting in the fonts and colors dialog. I had to actually dig into the source here on GItHub to find it was using an unexpected classification and then update that to match the existing settings for Type.

Describe the bug
When user clicks update header file, sometimes the error says "Error generating header file. Make sure the project builds". This UX degrades the experience significantly.

To Reproduce
Steps to reproduce the behavior:

1. Create a blank C++/WinRT project blank app project.
2. In MainPage.idl, randomly type something to produce compile error (e.g. insert gg at the end of the file).
3. Right click App.idl, click update header file.
4. See error "Error generating header file. Make sure the project builds".

Expected behavior
At (4), App.idl is able to build as the error in MainPage.idl shouldn't affect App.idl. There is no dependency at play here.

Screenshots
N/A

Additional context
N/A

Possible Solution
Could the extension execute the "Compile" command in right click context menu of idl files? In my testing, clicking compile for App.idl at (3) could build App.idl successfully.

Describe the bug
As titled

To Reproduce
Steps to reproduce the behavior:

1. Create idl file.
2. Add /**/ comment. Inside the comment, type string.
3. Observe the string has squiggle, while the file compiles just fine.

Expected behavior
The string at (3) doesn't have squiggle.

Screenshots

Additional context
N/A