Consider documenting <WasmBuildNative>true</WasmBuildNative>

[markarnolditpro]

It was necessary for me in VS2022 / .Net6 to add the following to the csproj. May want to consider documenting on this page:

<PropertyGroup>
    <WasmBuildNative>true</WasmBuildNative>
</PropertyGroup>

Thanks

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 119b7711-dc49-4525-199a-c75bee9c43b5
• Version Independent ID: 119b7711-dc49-4525-199a-c75bee9c43b5
• Content: ASP.NET Core Blazor WebAssembly native dependencies
• Content Source: aspnetcore/blazor/webassembly-native-dependencies.md
• Product: aspnet-core
• Technology: aspnetcore-blazor
• GitHub Login: @guardrex
• Microsoft Alias: riande

[guardrex]

🍂 OOF for the holidays 🍂

This issue has been marked for triage on the Blazor.Docs project, and I'll respond as soon as I return in 2022. I'll be back working on issues around Wednesday, Jan. 5. It will take a little while to dig out ⛰️⛏️ from holiday issues. I'll get back to you ASAP 🏃.

We only work on documentation on this repo. If you need product support, close this issue and seek assistance through one or more of the following support channels:

• Stack Overflow (tagged: blazor)
• General ASP.NET Core Slack Team
• Blazor Gitter

If you think that you found a potential bug in the framework or have product feedback, close this issue and open a new issue for the ASP.NET Core product unit at dotnet/aspnetcore issues. Bug reports require a clear explanation of the problem, usually including a minimal repro project placed on GitHub for the product unit engineers to download and run. If you determine with the product unit that it isn't a bug but merely requires documentation, please re-open this docs issue and place a cross-link to your engineering issue discussion. I'll take it up with you when I return from vacation.

For problems or feedback on Visual Studio or Visual Studio for Mac, close this issue and use the Report a Problem or Suggest a Feature processes from within VS, which open internal issues for VS teams. For more information, see Visual Studio Feedback or How to report a problem in Visual Studio for Mac.

For problems with Visual Studio Code, close this issue and ask for support on community support forums. For bug reports and product feedback, open an issue on the microsoft/vscode GitHub repo.

💃🕺🥳 Happy New Year! 🎈🎆🍾🥂🎉 See you in 2022!

[guardrex]

Hello @markarnolditpro ... Could you try a test for me? ... Remove that property from the project file and build in the "Release" configuration. I think the SDK sets it to true automatically for Release config. If that's correct, I'll update the doc.

WRT documentation of all of the properties, we're going to try and let the SDK doc handle it per dotnet/docs#27395 and cross-link to that. I have a tracking item for this, so we'll take action here right after they work that issue.

[guardrex]

As a related matter (a note to myself so that I don't forget to assess this further). The section at ...

https://docs.microsoft.com/en-us/aspnet/core/blazor/host-and-deploy/webassembly?view=aspnetcore-6.0#runtime-relinking

... says ...

With the .NET WebAssembly build tools installed, runtime relinking is performed automatically when an app is published.

... 🤔 ... mmmmmmmmmm "published" ... I think we're going to flesh that out. I actually think that it's directly because when the app is published the Release configuration is used.

I'll need to research this a bit further. We will end up making an update to clarify the behavior, even if it's only to say when the app is built in the Release config.

Yes, could you try again without the property in the project file and setting the app to build for Release? If it works that way, then we know that that's the critical clarification that we need to make.

WRT documenting all of these MSBuild properties, we'll leave that to the .NET Core docs and cross-link this topic (and probably these other sections in this doc set) to their upcoming coverage. There are a TON 🐘🐘 of these to cover. What I might do in the meantime is cross-link to ...

https://github.com/dotnet/runtime/blob/main/src/mono/wasm/build/WasmApp.targets

... just to tide us over until the new coverage appears.

[markarnolditpro]

Hi Luke. I'd love to help, but struggling to recreate. After I removed the <WasmBuildNative> property from the project file, I was still able to build successfully in Debug mode. So I restarted VS and created a brand new project only to find that it builds fine in Debug with a native dependency (sqlite) right out of the gate, never having added the <WasmBuildNative> at all.

It's as though adding the property once and building cleared something across my install of VS. In case relevant, I'm using VS 2022 Ent, x64, v17.0.0 on Win 11 Pro.

[guardrex]

Interesting ... ok. Let's hold this open until everyone gets back from the holiday break. I'd like to explore this a bit further with the product unit. My memory of it is more along those lines: I didn't add the property during my testing when working with the doc guidance, but I didn't recall outside of runtime relinking if it was required for publish (i.e., I was in Release config for runtime relinking, so that worked fine in that scenario). This scenario ... native deps ... yes ... I seem to recall that I did not add the property and things worked fine. I just can't say if I tested both configurations (and I don't recall if I was on the .NET CLI or VS ... I think actually that I was using the CLI).

So ... on the plate for possible work at this point ...

• Clarify with the PU that the property is not required for native deps.
• Cross-link to the MS build properties .targets file temporarily until the .NET Core docs place all of the properties into their docs. We'll change the .targets file link to link to their doc later.
• Clarify for runtime relinking that it's not directly "publish" that does it ... it's actually Release config ... and that's the config for publishing by default ... just clarify that over there. It's not related to native deps, per se, but it's something that we probably want to call out accurately if it's correct.

Stand-by for a couple of weeks. Everyone is 🥳 and 🏖️ for the New Year 🎉. They won't be back working until perhaps the 2nd week in January ... then may need a bit more time to dig out ⛏️⛰️. Leave this issue open ... it will automatically close when a PR is merged later. Thanks for raising this subject 🙇. All of these bits are new, and the feedback and discussion is great for improving it as we go forward.

[markarnolditpro]

In case helpful, unfortunately I can't remember the exact build Warning I received originally, however I do recall this much:
nativefilereference is not empty but the native references won't be linked in.

That error was coming from line 133-ish in some sort of targetmanifest? file that I can't find now, populated with various variables and conditions. Line 133 was an evaluation of $(wasmbuildnative) and the AOT flag: one or the other had to be true for the native dependency to link successfully. It's from this that I decided to try adding <WasmBuildNative>true</WasmBuildNative> to the csproj.

[guardrex]

For something like that ... with exact reproducible steps ... it would need to go directly to the product unit at ...

https://github.com/dotnet/aspnetcore/issues

... and they might move the issue over to the runtime/Mono team from there. We just work on docs here, and they just work on ASP.NET Core there. You can open such an issue if you wish, but please do give them exact repro steps so that they can see it in their own testing.

[markarnolditpro]

Just sharing the build warning I received that necessitated adding the property in the first place.

[guardrex]

You may have stumbled on a real 🐛. This is often how it happens. Someone gets a 😈 in a build ... the PU investigates ... and sure enough it's a problem that they need to fix. If you can't repro that error message tho, it's probably not worth mentioning to them. With so many devs using the new bits, they'll likely hear about it from someone.