search

aws / aws-toolkit-visual-studio

AWS Toolkit for Visual Studio - a plugin to interact with AWS
https://aws.amazon.com/visualstudio/
Apache License 2.0
107 stars 29 forks source link

Publish to AWS: I could not deploy to an existing cloud app #467

Open oliver-ec opened 1 week ago

oliver-ec commented 1 week ago

In Publish to AWS, the Existing Targets list did not show my project. I expected to see it there.

Toolkit: 1.58.0.0 Visual Studio: 17.10.5

I've created an ElasticBeanstalk application on the AWS console.

In my visual studio, I used the SSO option to configure my AWS access -- and I can see the Elastic Beanstalk application in the AWS Explorer. But when I right click on my ASP.NET .NET 8 (minimal API) application to publish to AWS -- it does not recognise elastic beanstalk resources.

Maybe this is relevant - my account is a federated account where I have been granted admin rights.

oliver-ec commented 1 week ago

I think I found the issue.

I use the Directory.Build.props file to specify the entirety of the target framework etc and that was throwing off AWS. For me this is a 'bug' as in, it's not matching expected behaviour, but I was blocked by this.

So instead of the APIProject.csproj having this entry:

  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
    <WarningsNotAsErrors>NU1701;1701;CA1416;1416;NU1902;</WarningsNotAsErrors>
  </PropertyGroup>

All of that is removed from the .csproj file, and goes into a top-level file called Directory.Build.props. The idea is that all projects in the solution uses the same reference to define those.

All code bases I've touched since last year has this -- and the idea is that we have one place in the solution (imagine you have 10+ project files inside the same solution, each a library or a microservice etc) to update .NET 8 => .NET 9. And also enforcing nullable checks on all projects etc.

I copy pasted that chunk back into the API project's .csproj file and the toolkit found the resource to deploy, and managed to deploy fine.

If this issue wasn't reported already (sorry I didn't check - I raised this issue by clicking a link on Visual Studio) you'll be getting more of these since I believe it is best practice to have a directory.build.props file for .NET projects and various projects and templates I've touched seem to be using that so I think it's going to be common place.

philasmar commented 1 week ago

@oliver-ec Thanks for bringing up this issue. You are correct. Currently, the Publish to AWS experience parses the .csproj and looks for the properties of interest. It is currently on our radar to add support for Directory.Build.props file to enable more advanced project configurations. We currently have a backlog item for it and due to competing priorities we were unable to get to it. I will bring this issue up in our upcoming planning meeting to discuss and prioritize this with the team.