Skip to content

Conversation

@DevTKSS
Copy link
Contributor

@DevTKSS DevTKSS commented Jul 26, 2025

GitHub Issue (If applicable): #1661

PR Type

What kind of change does this PR introduce?

  • Documentation content changes

What is the current behavior?

Just setting the Property of Content, but without the two others the Chefs App uses its hard to understand the Enhancement to evaluate for our Projects and Solution that this can provide to us, against from using Resource Element for this for example.

What is the new behavior?

It's a great to know detail, that this will make those Files and even more Folders showing up in your Solution Explorer and keep those in sync! I would like to have this included and tell the User about this option.

Also added a small Tree View diagram to help more Visual thinking People like me get a better idea of the Endresult this will provide 🚀

PR Checklist

Please check if your PR fulfills the following requirements:

  • Tested code with current supported SDKs (Tested with adding this In-Line Variant in my own Project and this worked like a charm 👍
  • Docs have been added/updated which fit documentation template. (for bug fixes / features)
  • Unit Tests and/or UI Tests for the changes have been added (for bug fixes / features) (if applicable)
  • Wasm UI Tests are not showing unexpected any differences. Validate PR Screenshots Compare Test Run results.
  • Contains NO breaking changes
  • Associated with an issue (GitHub or internal)
    With those Information, it gets more clearer to me, what this is doing and what the difference is, we are getting.

Other information

I would still be interested to know, why we do not use ContentSource via IOptions for this instead of that StorageFile way to do which seems to be a Windows Specifics🤔 maybe because of the Details added on this issue?

Maybe someone could check and improve this in any point in the future 💡

Internal Issue (If applicable):

…efs App csproj files

It's a great to know detail, that this will make those Files and even more Folders showing up in your Solution Explorer and keep those in sync. We should tell the User about this option.
Copilot AI review requested due to automatic review settings July 26, 2025 18:41
Copy link

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR enhances the documentation for the AppData section by adding detailed guidance on using the LinkBase property in MSBuild Content elements for Uno Platform projects. The changes explain how to better organize data files in multi-project solutions while keeping them visible and editable in the Solution Explorer.

Key changes:

  • Enhanced explanation of CopyToOutputDirectory property usage
  • Detailed documentation of the LinkBase property and its benefits
  • Added visual tree diagram showing how linked files appear in Solution Explorer

Comment on lines +23 to +59
- If you want to not just have these files in your app's output directory with latest changes, then also have your IDE showing them in your **Solution Explorer** and enable you editing them easily as if those would be directly nested in your specific project, you may want to also set another property on the xml element we just added: `LinkBase="AppData"` (or any other Name you want it to show to you as folder name).

So this will make the full Content Element look like this:

```xml
<ItemGroup>
<Content Include="AppData\*.json" CopyToOutputDirectory="PreserveNewest" LinkBase="AppData" />
</ItemGroup>
```

And in your Solution Explorer, this will show up like with the below shown grey text (VS Code) or with a Link Arrow like you may know it from .ink files on your Desktop (Visual Studio 2022).

```markdown
root
|-AppData
| |-yourDataContainingFile.json
|-ClientApp/
| |-ClientApp.csproj
| |-AppData/ *(Linked File)*
| |-yourDataContainingFile.json *(Linked File)*
|-ClientApp.Api/
| |-ClientApp.Api.csproj
| |-AppData/ *(Linked File)*
| |-yourDataContainingFile.json *(Linked File)*
|-ClientApp.IntegrationTests/...
|-ClientApp.UITests/...
|-ClientApp.UnitTests/...
```

> [!TIP]
> Another advantage of setting the LinkBase Property like shown above is, that you can do this on every project in your Solution you like to, without being required to:
>
> - duplicate the Folder or Files
> - if you edit a file in there, its state will always be synced
> [!TIP]
> If you may not want to have those files in your output directory of the Project, but showing up in your Solution Explorer, you can set the `CopyToOutputDirectory` property shown before, to **Never**.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wouldn't spend too much detail surrounding explaining this as it is not specific to Uno or the StorageFile properties. This is something coming from MSBuild and we can offload all of this explanation to their docs on the subject: https://learn.microsoft.com/en-us/dotnet/core/project-sdk/msbuild-props#linkbase

@DevTKSS
Copy link
Contributor Author

DevTKSS commented Nov 21, 2025

@kazo0 I noticed that the sample uses Windows.StorageFileHelper but I couldn’t find in the docs why this is chosen over Uno.Extensions.Storage (IStorage.ReadPackageFileAsync(...) with typed deserialization).

The only difference I’m aware of is that the Windows API exposes Roaming/Local/LocalLow folders. I might be mistaken, but my understanding is that IStorage mainly adds the serialization layer and may not access those folders — though I’m not sure this is the actual reason here.

A short note explaining the choice could help readers decide which option to use. Would it make sense to add that?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants