Open ddivita opened 11 months ago
Hi @ddivita,
Good morning.
Based on initial high level look, I'm not sure if the Procfile
is a .NET Core application compilation/publish concept. Based on the below articles, it appears to be Linux concept not specific to .NET:
So just curious on how in your case, the Procfile
is auto-generated. Also if you are manually crafting Procfile
, you might want to set it to relative path of .NET assembly (e.g. web: dotnet ./dotnet-core-app1/dotnetcoreapp1.dll
) as documented in the 1st link above.
Unsure if this is the AWS .NET CLI extensions issue since Procfile
creation is probably not handled by our tooling, and its process by ElasticBeanstalk environment.
CC @normj
Thanks, Ashish
@ashishdhingra The Procfile is definitely being auto-generated by something ;). I can see the file in the zipped code and looks exactly like the example I set manually.
@ashishdhingra The Procfile is definitely being auto-generated by something ;). I can see the file in the zipped code and looks example like the example I set manually.
@ddivita Is it generated automatically locally when compiling under Visual Studio? If not, might be there is some step in your pipeline that generates it!
@ashishdhingra The Procfile is definitely being auto-generated by something ;). I can see the file in the zipped code and looks exactly like the example I set manually.
@ddivita Looks like I found EBUtilities.SetupPackageForLinux() which uses the existing Procfile
if found, else creates a new one with web:
content here for Linux environment.
Could you please share the sample project for reproduction with folder structure for issue?
Thanks, Ashish
@ashishdhingra I think I see what might be going on. That method you posted led me to look at the runtimeconfig.json file. There are several, and that code picks the first file it sees which is why it may have been failing? I wonder if I only have 1 runtimeconfig
if it would work properly.
Code:
Files in the .zip
@ashishdhingra I think I see what might be going on. That method you posted led me to look at the runtimeconfig.json file. There are several, and that code picks the first file it sees which is why it may have been failing? I wonder if I only have 1
runtimeconfig
if it would work properly.Code:
Files in the .zip
This was the issue. I set the <GenerateRuntimeConfigurationFiles>false</GenerateRuntimeConfigurationFiles>
for any project I didn't want the runtimeconfig.json
to be generated. The deployment worked fine after this.
@ashishdhingra I think I see what might be going on. That method you posted led me to look at the runtimeconfig.json file. There are several, and that code picks the first file it sees which is why it may have been failing? I wonder if I only have 1
runtimeconfig
if it would work properly. Code: Files in the .zipThis was the issue. I set the
<GenerateRuntimeConfigurationFiles>false</GenerateRuntimeConfigurationFiles>
for any project I didn't want theruntimeconfig.json
to be generated. The deployment worked fine after this.
@ddivita Thanks for the findings and update. Please confirm if we are good to close this issue.
Thanks, Ashish
This issue has not received a response in 5 days. If you want to keep this issue open, please just leave a comment below and auto-close will be canceled.
@ashishdhingra If this is by design, then this can be closed, however, what if there are multiple startup projects in a solution? This would always break it.
@ashishdhingra If this is by design, then this can be closed, however, what if there are multiple startup projects in a solution? This would always break it.
@ddivita Thanks for your inputs. I will review this with team and get back to you.
Describe the bug
I will preface this by saying this could be a GitLab pipeline issue, however, I have also seen this happen on a local development machine.
Command:
GitLab script:
The script initiates the dotnet publish command:
After the
publish
compiles the project and creates the files, theProcfile
is auto-generated. The issue is theProcfile
is not setting the proper startupweb
assembly.Expected Behavior
Running the same command on a local environment produces this Procfile:
Current Behavior
The auto-generated
Procfile
is pointing to the wrong assembly. It's not always the same assembly either, but it never picks the API assembly. Even when theProcfile
is created manually, it still does not deploy properly.Reproduction Steps
I'm not 100% sure what might be going on, but I have a Minimal API that is also referencing an MS Test project. I'm not sure that is the issue since I can run the commands locally without issue. It could be the docker image used for the deployment.
I have another minimal API project that deploys fine in GitLab and locally. This project has no references to any other projects.
Possible Solution
I tried creating a
Procfile
that is set toCopy Always
in the root of the API project. This does not work locally or in the pipeline.Contents of the
Procfile
This is in the logs, which makes sense:
However, the instance does not deploy properly:
Additional Information/Context
No response
Targeted .NET platform
.Net 7
CLI extension version
AWS CLI:
aws-cli/1.19.1 Python/3.9.2 Linux/5.4.109+ botocore/1.20.0
Donet EB:
dotnet-eb Tool 'amazon.elasticbeanstalk.tools' (version '4.3.2') was successfully installed
GitLab Runner:
Environment details (OS name and version, etc.)
linux