Azure DevOps FTP部署文件夹未上传，如何发布.NET Core WebAPI文件夹？

看起来你遇到的核心问题是FTP上传时没有保留本地发布目录的文件夹结构，导致像cs、de、es这些本地化文件夹没有被正确上传到远程站点，进而引发站点无法运行的问题。我来帮你分析几个关键的调整点：

1. 修正FTP任务的preservePaths配置 #

你的FtpUpload@2任务里preservePaths设置为false，这会导致所有文件被平铺上传到远程目录，而不会保留本地的文件夹层级结构。那些cs/de/es文件夹里的文件会直接被传到/service.xxxxxxx.com/根目录，而文件夹本身不会被创建，自然就看不到它们了。

把这个参数改成true，就能让FTP任务按照本地的目录结构在远程服务器创建对应文件夹并上传文件：

- task: FtpUpload@2
  inputs:
    credentialsOption: 'inputs'
    serverUrl: 'ftps://187.4.47.6'
    username: 'calasagoolsa'
    password: 'rdfx@m79M9aaax'
    rootDirectory: '$(build.artifactstagingdirectory)'
    filePatterns: '**/*'  # 明确指定包含所有子文件和文件夹
    remoteDirectory: '/service.xxxxxxx.com/'
    clean: false
    cleanContents: false
    preservePaths: true  # 这里改成true
    trustSSL: true

2. 验证发布目录的完整性 #

在FTP任务之前添加一个命令行任务，确认$(build.artifactstagingdirectory)下确实包含了所有需要的文件夹（cs、de、es等），避免是发布环节没生成这些文件：

- task: CmdLine@2
  inputs:
    script: 'dir $(build.artifactstagingdirectory) /s'

运行流水线后查看这个任务的输出，检查是否存在那些缺失的文件夹和里面的文件。如果发布环节就没生成，那需要检查你的DotNetCoreCLI@2 publish任务配置，确保本地化资源被正确包含在发布输出里。

3. 检查FTP服务器的权限 #

有时候FTP账号没有在远程服务器创建子文件夹的权限，也会导致文件夹无法上传。你可以用FileZilla这类FTP客户端，使用流水线里的相同账号登录服务器，手动尝试创建cs/de/es文件夹并上传文件，如果操作失败，就需要联系托管服务商调整账号权限。

4. 可选：清理远程旧文件（谨慎操作） #

如果远程目录存在旧的文件或文件夹，可能和新上传的内容冲突，可以尝试设置clean: true和cleanContents: true，在上传前清空远程目录。但这个操作会删除远程目录下的所有现有内容，一定要确认没有重要文件再启用：

clean: true
cleanContents: true

按照这些步骤调整后，重新运行流水线，应该就能看到所有文件夹和文件都被正确上传到远程站点了，站点也能正常运行。

内容的提问来源于stack exchange，提问作者coolblue2000