Azure-functions-vs-build-sdk: .NET Core 3.0 SDK publishes a FunctionsV2 project differently/incorrectly compared to 2.2 SDK

[AtOMiCNebula]

With the new .NET Core 3.0 SDK installed, my Azure Function v2 project (still targeting netcoreapp2.2, not netcoreapp3.0) does not publish correctly. I've resolved it by adding a global.json that locks me to a v2.2.40x version of the SDK, after which publishing is once more successful.

Unsure if related to #262 or not.

v2.2 SDK published folder structure:

• (folders for each function)
• bin
  
  
  
  • (folders for languages)
  
  
  • runtimes
  
  

v3.0 SDK published folder structure:

• (folders for each function)
• bin
• (folders for languages)
• runtimes

Essentially, runtimes and per-language DLLs have moved up to be sibling folders of bin, instead of child folders of bin, which breaks some assembly loading. In my case, my project relies on the presence of function.json to find some DLLs (System.Private.SystemModel junk), and those loads fail.

[jeffputz]

It doesn't even build in a Core v3 project for me, in the event that I reference another Core v3 library project, because the various build targets aren't there.

[chassq]

Yep ran into this today. Right after installing the 3.0 sdk all my function publications to azure failed. Created a global.json targetting latest 2.2 sdk in the solution folder and it seemed to start working again.

To note, since our azure function projects reference shared libs with other web UX based projects we cannot move forward it seems with 3.0 until azure function support is added to the 3.0 SDK and azure functions support net standard 2.1. For example a shared SQL lib that wants to use EF Core 3.0 requires net standard 2.1 so azure function projects cannot load those assemblies yet it seems. Kinda makes me wonder if anyone thought of this pretty big hole to migrating to 3.0 prior to release..

[jeffputz]

@chassq I don't think the problem is Azure itself, it's the hard references in the SDK.

[chassq]

Its not in azure. It is the SDK but it breaks the deployments. Also I can update the function project to use net core 30, have the SDK set to ver 3.0.100 and reference all my net standard 2.1 libs. In this case I can get a good compile but its only when we try to deploy we see the error.

[AtOMiCNebula]

@fabiocav with the announcement of preview availability of Functions 3.0 this week, can you please comment on this? I haven't even tried updating my projects to .NET Core 3.0, but just having the 3.0 SDK installed and having Visual Studio use it produces a bad published package, and I have to force things back to the 2.2 SDK.

[IGx89]

Just ran into this ourselves. Quite a few teams at my company are going to be annoyed with having to suddenly add a global.json to all their function apps just to keep them from breaking due to our build servers having the 3.0 SDK installed on them.

[IGx89]

This appears to affect Functions v3 as well

[fabiocav]

@AtOMiCNebula apologies for the delayed response on this. Flagging this as triaged so we can assign this to the next sprint. Will provide an update as soon as we have more information on a fix.

[fabiocav]

/cc @brettsam @soninaren - this needs to be tracked as part of the preview.

[AtOMiCNebula]

FWIW, I finally got tired of this limitation yesterday and dug into the Functions MSBuild logic, and found a workaround that doesn't require global.json'ing your way back to the .NET Core 2.2 SDK (which means I can have 3.0 projects live alongside my 2.2 projects, yay!). Unfortunately, it requires adding yet another <Target> hack to my functions app .csproj. I also suspect it is not a great long-term solution, though it does appear to get my project back into a good publishing state (obviously YMMV, please perform your own verification). I'm prepared to remove it as soon as this is fixed upstream. :smile:

<Target Name="PostComputeResolvedFilesToPublishList" AfterTargets="ComputeResolvedFilesToPublishList">
  <!-- Try to repair stuff like _ResolveAdditionalReferenceCopyLocalPathsForFunctions does -->
  <!-- https://github.com/Azure/azure-functions-vs-build-sdk/issues/333#issuecomment-546056921 -->
  <ItemGroup>
    <ResolvedFileToPublish Condition="'%(ResolvedFileToPublish.AssetType)'!=''">
      <DestinationSubDirectory>bin\%(ResolvedFileToPublish.DestinationSubDirectory)</DestinationSubDirectory>
      <DestinationSubPath>bin\%(ResolvedFileToPublish.DestinationSubPath)</DestinationSubPath>
      <RelativePath>bin\%(ResolvedFileToPublish.RelativePath)</RelativePath>
    </ResolvedFileToPublish>
  </ItemGroup>
</Target>

[AtOMiCNebula]

@fabiocav / @brettsam / @soninaren, this appears to still be broken with v1.0.30-beta4. ☹️

v3.0.1 kind of works...if I publish from within Visual Studio (2019.4, of course), then it produces a bundle that looks to be laid out correctly (languages and runtimes inside bin instead of being siblings of bin), but I get build errors when running dotnet build/publish via CLI (#320). I have a solution with multiple projects, but only one of them is a Functions project. Not sure if it's because one of my dependencies is pulling in something old, but either way I'm not ready to move my project from netcoreapp2.2 to 3.1 yet, so I'm still blocked.

[jeffputz]

Is this repo going to show releases? It doesn't show one since 1.0.14 more than a year ago, which suggests it isn't being maintained.

[AtOMiCNebula]

The repo is current, they just aren't tagging releases as they happen. ☹️

[brettsam]

@AtOMiCNebula -- do you have a sample solution that I can use as a reference to track down your issue? We're planning an overhaul of how the build system works for Functions (to prevent things like what you're seeing), but I may be able to patch this scenario in the meantime.

@jeffputz -- Yes, we're definitely maintaining this repo. We've released several builds within the last few weeks for v3 out of the v3.x branch. We just haven't been tagging releases or noting them in github. We'll try to get better about that. I've just created an entry for 3.0.1.

[simonvane]

@brettsam Is there a changelog.md or similar we can look at?

[AtOMiCNebula]

@brettsam: literally every function project, at least that I've encountered. 😅

Repro steps:

1. Create new Functions project via VS (I used 2019 16.4.1 just now)
2. dotnet publish, and note that in the publish output dir that the runtimes folder is a sibling of bin instead of a child.
3. dotnet new globaljson --sdk-version 2.2.400 (adjust for whatever pre-3.0 SDK you have installed)
4. Delete old publish directory, and dotnet publish again. Note that runtimes is now (correctly!) a child of bin instead of a sibling.

The default template does not included localized resources, but you can add a <PackageReference> to something like Microsoft.Data.OData.

Feel free to reach out to me on Teams if you'd like, I am MSFT-Internal. :smile:

[IGx89]

If https://github.com/Azure/azure-functions-vs-build-sdk/pull/354, which fixed that issue in Functions v3, wasn't backported to Functions v2 that behavior still existing would make sense to me. Unless it was backported already?

[brettsam]

Okay I was completely misreading this and didn't realize it was a v2 project (even though it says it in the title). Sorry about that. @IGx89 yes that's likely the fix -- I'm looking at it now.

[brettsam]

Side note that this is another case that fixing #344 would help.