WebAssembly <NativeFileReference> isn't included in VS's fast up-to-date check

[SteveSandersonMS]

If you have, for example:

<NativeFileReference Include="somefile.a" />

... then you can call it via [DllImport("somefile")]. That's all great. But if you then do something to modify somefile.a, for example rebuild it from sources, then simply running Ctrl+F5 from VS again will not be enough to see your changes. That's because VS will consider the .NET project already up-to-date, assuming you didn't edit any .NET files. You have to artificially touch one of your .cs files (or similar) to make it rebuild.

How to fix it

See info at https://github.com/dotnet/project-system/blob/main/docs/up-to-date-check.md#up-to-date-check for how the MSBuild targets should tell VS about the native input/output files and include them in its up-to-date check.

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

---

If you have, for example:

<NativeFileReference Include="somefile.a" />

... then you can call it via [DllImport("somefile")]. That's all great. But if you then do something to modify somefile.a, for example rebuild it from sources, then simply running Ctrl+F5 from VS again will not be enough to see your changes. That's because VS will consider the .NET project already up-to-date, assuming you didn't edit any .NET files. You have to artificially touch one of your .cs files or similar, to make it rebuild.

How to fix it

See info at https://github.com/dotnet/project-system/blob/main/docs/up-to-date-check.md#up-to-date-check for how the MSBuild targets should tell VS about the native input/output files and include them in its up-to-date check.

Author:	SteveSandersonMS
Assignees:	-
Labels:	arch-wasm
Milestone:	-

Tagging subscribers to this area:
See info in area-owners.md if you want to be subscribed.

Issue Details

---

If you have, for example:

<NativeFileReference Include="somefile.a" />

... then you can call it via [DllImport("somefile")]. That's all great. But if you then do something to modify somefile.a, for example rebuild it from sources, then simply running Ctrl+F5 from VS again will not be enough to see your changes. That's because VS will consider the .NET project already up-to-date, assuming you didn't edit any .NET files. You have to artificially touch one of your .cs files (or similar) to make it rebuild.

How to fix it

See info at https://github.com/dotnet/project-system/blob/main/docs/up-to-date-check.md#up-to-date-check for how the MSBuild targets should tell VS about the native input/output files and include them in its up-to-date check.

Author:	SteveSandersonMS
Assignees:	-
Labels:	arch-wasm, untriaged, area-VM-meta-mono
Milestone:	-

[radical]

@SteveSandersonMS I'm adding @(NativeFileReference). Are there any other files that you can think of? Or any other incremental build cases affected by this?

[SteveSandersonMS]

Nope, I don't immediately know of any others. Thanks for resolving this!