Skip to content
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

Specify folders to exclude and include when deploying #57

Open
HakanL opened this issue Dec 20, 2022 · 2 comments
Open

Specify folders to exclude and include when deploying #57

HakanL opened this issue Dec 20, 2022 · 2 comments
Labels
enhancement Approved new feature or enhancement v3.0 vNext Marked for an upcoming release
Milestone

Comments

@HakanL
Copy link
Contributor

HakanL commented Dec 20, 2022

I noticed I have a runtimes folder on my Linux host (the files that are deployed with this extension) that includes binaries for 12 platforms including Windows and OSX. It would speed up deployment if I could exclude these from the deployment.
Also I have a folder for client-side web files (Spa) that sits in a shared project, I'd like these to be included (they aren't by default).

@HakanL HakanL added the enhancement Approved new feature or enhancement label Dec 20, 2022
@DamianSuess DamianSuess added the not-reviewed Issue that needs reviewed label Dec 23, 2022
@DamianSuess
Copy link
Collaborator

DamianSuess commented Dec 28, 2022

@HakanL, though this is more suited for the Discussions section of this repo, this is an interesting enhancement request.

Initially, I was skeptical about this feature early on considering the following thought process, "_if the build system places a file in the output folder then it should be uploaded to ensure integrity." However, this is not always true as you pointed out, and as a personal example building with CodeAnalysis leads to an unnecessary 13 language folders coming along for the ride.

Though there are many ways this can be achieved, what are your thoughts on the following?

  1. A .linuxdbg file which uses a syntax approach similar to a primal .gitignore and is placed in the same folder as the .sln or .csproj file?
    • PRO: It uses a common file filter syntax approach. Customizable per project.
    • CON: Yet another .config file. What if more than one file is found, who-overrides-who?
  2. Add a filter textbox into Tools > Options window.
    • PRO: Can be reused across projects without creating new filter files.
    • CONS: Using a comma or semicolon as a delimiter conflicts with file names. The rule would apply to all projects uploaded.

Frankly, I'm leaning towards 1.

@HakanL
Copy link
Contributor Author

HakanL commented Dec 28, 2022

Yeah maybe it should've been a discussion first. I don't like proposal 2, but what about adding a property to the csproj file that uses the .gitignore syntax? I realize we're not trying to replace the publish process, but we want the deployment to a Linux host to be as quick and seamless as possible, as you'll push the project over to the host many times during development. Anything that can streamline that process is welcome IMHO.

@DamianSuess DamianSuess added vNext Marked for an upcoming release and removed not-reviewed Issue that needs reviewed labels Jan 2, 2023
@DamianSuess DamianSuess added this to the vNext milestone Jan 2, 2023
@DamianSuess DamianSuess modified the milestones: vNext, v2.2 Mar 24, 2023
@DamianSuess DamianSuess modified the milestones: v2.2, v3.0 Dec 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Approved new feature or enhancement v3.0 vNext Marked for an upcoming release
Projects
Status: Backlog
Development

No branches or pull requests

2 participants