-
Notifications
You must be signed in to change notification settings - Fork 772
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
UserSecretsId prevents any deployment of F# ASP.NET Core app to Azure App Service #5549
Comments
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>
.
|
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). |
cc @vijayrkn @mlorbetske any ideas where this might lie? It looks like it's adding an element to end of the |
@cmeeren - How is this entry getting added during deployment? |
@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. |
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. |
I'll try, but how can I do that considering that you'd need a publish profile (I assume with username/password)? |
you can add the publish profile with no credentials. We will try publishing to a different target |
Great! I'll see what I can do. |
@vijayrkn this is actually also visible if you just add |
Here's a repro solution. Just created from template, no changes. Note that the |
Thanks! Taking a look now. |
@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
Once this is added, publish will not add the UserSecretsId to the csproj. |
Thank you so much for the workaround! Will try it tomorrow. |
@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. |
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> |
Guys, not to be annoying but I'd really rather like to see UserSecrets work together with F# |
Me too. Why doesn't assembly attribute generation work for F#? I don't know enough about the language to understand what this means:
|
For AssemblyInfo generation, see #3113 (if I understand correctly). It's been silent on that front for a while. |
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 |
So, if I understand right, we just need to have assembly-attribute generated code in the |
I believe so, yes. @KevinRansom could speak more to this, though. |
@natemcmaster that is correct. |
Ok, this should be easy enough to fix in ASP.NET Core 2.2: aspnet/Configuration#872 |
Closing as the ASP.NET PR is merged. Thanks @natemcmaster |
No problem. This should be in ASP.NET Core 2.2 Preview 2, which should be out in a few weeks. |
We should also fix the issue where - asking for the secrets should not add the property to csproj. |
@natemcmaster - should I create the bug in the tools repo? |
@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. |
done - aspnet/DotNetTools#479 |
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.)
The text was updated successfully, but these errors were encountered: