None Update ignored in F# projects

[cartermp]

Create a console app similar to this:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp3.1</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <None Update="test.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
    <Compile Include="Program.fs" />
  </ItemGroup>

</Project>

then build it.

Note that under the bin folder, test.json is not included. In a C# project, it is included. This doesn't require VS to reproduce, so it's likely us.

[cartermp]

This results in some problems when using Azure stuff like Functions: Azure/Azure-Functions#1177

[abelbraaksma]

I've a bunch of these in my projects, I use it for test data files for instance, but AFAIK, they still work (my VS is one or two months behind), so this may be a recent regression.

[0x53A]

I think F# does not have the default includes, so you need <None Include=. Update only works if the thing is already included, otherwise it's a no op.

C# does includes all files in the project folder, so you can update them.

[abelbraaksma]

You're right, I have None Include. My bad.

[pihai]

Is there any chance that F# gets default includes for this? If not then the Azure Functions Project template should simply be changed to use <None Include=>.

Azure Functions Project Template

[aaronpowell]

@pihai - I've opened a PR today for this: Azure/azure-functions-templates#954

[vjraitila]

Is having explicit includes for individual files really the best approach? This causes a problem for files where the need to include them is situational e.g. local.settings.json for Azure Functions - you want it during local development, but said file is not available during a CI build, for example.

To me there seems to be two conflicting goals of both keeping the project definition terse - hence the default includes - as well as wanting to be explicit. While far from being an expert on this matter, I sort of understand the compilation order aspect when it comes to F# (source files), but I'm not entirely convinced the same principle should be applied to other project artifacts as well.

[cartermp]

@KevinRansom any thoughts on this? It's definitely in our camp since this can reproduce outside of VS. It means that F#-defined azure functions bundle up files that shouldn't be required for a deployment.

[KevinRansom]

I will take a look.