UserSecretsId prevents any deployment of F# ASP.NET Core app to Azure App Service

[cmeeren]

When deploying an F# ASP.NET Core app to Azure App Service. the deployment process adds a <UserSecretsId> element to the fsproj if it's not already present. As explained in this article, this element causes the build to fail with the following error:

A function labeled with the 'EntryPointAttribute' attribute must be the last declaration in the last file in the compilation sequence

The article explains why the error occurs and instructs to fix it by removing the element from the project file and instead adding the user secrets ID in an AssemblyInfo.fs. I have tried this and can then build manually, but each time I try to deploy, the deployment process still adds a <UserSecretsId> element with a new ID in my project file, causing the build to fail.

In other words, this bug seems to completely block deployment of F# ASP.NET Core apps to Azure App Service. It might happen for other Azure deployments too; I haven't tested.

Let me know if I can provide any other relevant info.

(Also posted as a question on SO to try to find workarounds.)

[forki]

We are putting our asp.net core app into a docker container and run the container in app service. That works. Maybe a workaround for you Christer van der Meeren <notifications@github.com> schrieb am Do., 23. Aug. 2018, 10:46:

…

When deploying an F# ASP.NET Core app to Azure App Service. the deployment process adds a <UserSecretsId> element to the fsproj if it's not already present. As explained in this article ***@***.***/making-asp-net-core-user-secrets-work-in-f-projects-9b04572d81f6>, this element causes the build to fail with the following error: A function labeled with the 'EntryPointAttribute' attribute must be the last declaration in the last file in the compilation sequence The article explains why the error occurs and instructs to fix it by removing the element from the project file and instead adding the user secrets ID in an AssemblyInfo.fs. I have tried this and can then build manually, but each time I try to deploy, the deployment process still adds a <UserSecretsId> element with a new ID in my project file, causing the build to fail. In other words, this bug seems to *completely block deployment of F# ASP.NET <http://ASP.NET> Core apps to Azure App Service.* It might happen for other Azure deployments too; I haven't tested. Let me know if I can provide any other relevant info. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#5549>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADgNCGLPj-p-bzMh9ubuOSHrW5NoFjHks5uTmvqgaJpZM4WJGQM> .

[cmeeren]

Thanks for the suggestion. If I need to use containers, I think I'll rather just wait until our supplier supports AKS (which won't be too long).

[cartermp]

cc @vijayrkn @mlorbetske any ideas where this might lie? It looks like it's adding an element to end of the ItemGroup in the project file, but this violates order dependence in the F# compiler.

[vijayrkn]

+@BillHiebert

[vijayrkn]

When deploying an F# ASP.NET Core app to Azure App Service. the deployment process adds

@cmeeren - How is this entry getting added during deployment?

[cmeeren]

@vijayrkn It may have been first added when I created the publish profile, but if it's missing (e.g. if I delete it) it is re-added to the project file (with a new GUID) each time I click the final "Publish" button.

[vijayrkn]

The publish process should not be adding anything to the fsproj. Can you please provide a simple repro project? This will help us diagnose the issue faster.

[cmeeren]

I'll try, but how can I do that considering that you'd need a publish profile (I assume with username/password)?

[vijayrkn]

you can add the publish profile with no credentials. We will try publishing to a different target

[cmeeren]

Great! I'll see what I can do.

[NinoFloris]

@vijayrkn this is actually also visible if you just add <UserSecretsId>Anything</UserSecretsId> to an fsproj and run dotnet run

[cmeeren]

Here's a repro solution. Just created from template, no changes. Note that the <UserSecretsId> element is added once the Publish button is clicked, even before you enter username and password, so you can try to just publish using the existing target and observe the behavior.

TestApp.zip

[vijayrkn]

Thanks! Taking a look now.

[vijayrkn]

@cmeeren - Thank you for the repro project.

@BillHiebert helped diagnose the issue and we will create a bug in the correct repo. For now, to unblock the scenario, you can delete the UserSecretsId property from the csproj and add the following to the pubxml under Properties\PublishProfiles\profile.pubxml

<DisableKeyVaultDuringPublish>true</DisableKeyVaultDuringPublish>

Once this is added, publish will not add the UserSecretsId to the csproj.

[cmeeren]

Thank you so much for the workaround! Will try it tomorrow.

[vijayrkn]

@natemcmaster - This looks like an issue here - https://github.com/aspnet/DotNetTools/blob/03e73cc8060ad167056d66ee0bf625dfe6943d82/tooling/Microsoft.VisualStudio.SecretManager/ProjectLocalSecretsManager.cs#L79

Requesting for the secretnames is creating a store. We will have to move this issue to this repo.

[natemcmaster]

IMO the better fix would be to get assembly attribute generation working correctly. In the meantime, you can suppress this by adding this to your .fsproj

<PropertyGroup>
 <GenerateUserSecretsAttribute>false</GenerateUserSecretsAttribute>
</PropertyGroup>

[NinoFloris]

Guys, not to be annoying but I'd really rather like to see UserSecrets work together with F#

[natemcmaster]

Me too. Why doesn't assembly attribute generation work for F#? I don't know enough about the language to understand what this means:

A function labeled with the 'EntryPointAttribute' attribute must be the last declaration in the last file in the compilation sequence

[cmeeren]

For AssemblyInfo generation, see #3113 (if I understand correctly). It's been silent on that front for a while.

[cartermp]

As of https://github.com/Microsoft/visualfsharp/pull/4430/files and dotnet/sdk#2023 we should allow it, but only for .NET Core 2.1.

@natemcmaster F# is dependent on declaration and file ordering due to its type system. Nothing can come after a function decorated with [<EntryPoint>] due to this.

[natemcmaster]

So, if I understand right, we just need to have assembly-attribute generated code in the <CompileBefore> item group, not <Compile>, right?

[cartermp]

I believe so, yes. @KevinRansom could speak more to this, though.

[KevinRansom]

@natemcmaster that is correct.

[natemcmaster]

Ok, this should be easy enough to fix in ASP.NET Core 2.2: aspnet/Configuration#872

[cartermp]

Closing as the ASP.NET PR is merged. Thanks @natemcmaster

[natemcmaster]

No problem. This should be in ASP.NET Core 2.2 Preview 2, which should be out in a few weeks.

[vijayrkn]

We should also fix the issue where - asking for the secrets should not add the property to csproj.

[vijayrkn]

@natemcmaster - should I create the bug in the tools repo?

[natemcmaster]

@vijayrkn go for it. Can't promise that we'll get to it soon though. It seems pretty low priority. If someone wants to make a PR, I'd welcome it.

[vijayrkn]

done - aspnet/DotNetTools#479