Closed jpobst closed 4 months ago
@jpobst controlling the properties shown for custom item types in the properties pane is done via "browse objects". Your project system should provide browse object rules that define the screens for such properties. You can find examples and documentation in this repo. I'm on a phone right now but can provide more details if needed when at a computer next.
"browse objects" seems to imply that we would need a custom Project System Extension? Ideally this would be built-in to CPS (?) so that AvailableItemName
users could provide this feature without needing to produce a full VS extension.
To make this an extension point via MSBuild data would be a feature request of CPS, which is not this repo. Could you open a suggestion ticket (in VS: Help | Send Feedback | Suggest a Feature) and describe the request there? If you share the link here I can ensure it's routed to the correct team.
Bear in mind that display strings need to be localised, values are typed (int/string/bool/etc), and there's a fair number of options in how properties are bound to the project. I'm not sure MSBuild metadata is up to the task of that unfortunately.
Summary
In .NET Android, we use
AvailableItemName
to allow our custom items to show up in the Solution Explorer node. We also use "default items" so these files are automatically added to the project when placed in the project folder.For example, adding
tink-android-1.9.0.jar
to the project directory automatically adds it as an<AndroidLibrary>
:However there are commonly used MSBuild metadata attributes that users need to control how these files are processed, like
Bind
andPack
. Users often fail when they try to set these values.Their first attempt is to try to find some way to set these values in the IDE, as traditionally users have not been encouraged to edit the
.csproj
manually.Their second attempt is generally to add it to their project as an
Include
:This fails because there is already the "default item" version imported from our import globs.
The user must instead do:
Alternatively they can use:
<EnableDefaultItems>false</EnableDefaultItems>
<AndroidLibrary Remove="..."/>
and<AndroidLibrary Include="..." />
User Impact
Unfortunately, this leads to many users failing to accomplish their goal (because they used
Include
) and resorting to filing issues that theBind
orPack
metadata is not working.It would be nice if we could instead nudge them to success by providing a UI to set these values.
Potential Solution
One solution would be to expand the
AvailableItemName
to support specifying the available metadata values for the item:With this information, the Properties window could be populated with choices for the user:
Setting these properties would automatically add the
<AndroidLibrary Update="..." />
items if needed.