我有一个没什么特别的.NET Core解决方案,我们可以调用它Application.sln,它包含12个C#项目和1个SQL项目.在Visual Studio 2017中,我没有构建所有项目的问题,但是当我前往命令行使用打包项目时dotnet pack Application.sln --no-build,我立即遇到了sql项目的问题.这是错误:
error MSB4019: The imported project "C:\Program Files\dotnet\sdk\1.1.0\Microsoft\VisualStudio\v14.0\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk
在解读之后,我发现第一部分C:\Program Files\dotnet\sdk\1.1.0来自我使用dotnet而不是msbuild来打包解决方案,而且由于SSDT无法安装到dotnet文件夹中,这将失败.
最好,我希望它忽略.sqlproj项目,只包装.csproj项目,因为我将在之后单独处理sql项目,但我没有看到任何方法这样做.有办法吗？似乎我不能使用MSBuild样式的通配符作为dotnet pack(***.csproj)的参数,因为它会抛出一个单独的错误.
我尝试过使用msbuild/t:pack,但这给了我其他问题(它说项目中不存在目标"pack").
有人对我有什么建议吗？如果它有帮助,我想通过TeamCity这样做,但所有这些问题也存在于我的开发机器上.
根据解决方案的任何标准/默认格式的Microsoft 文档，顶层有一个 ***.sln，然后是与sln 同一级别的src文件夹（以及可能的其他各种文件夹，例如），这意味着testcore 项目将位于该src文件夹中（与该文件夹中的测试项目类似test），与 sln 不在同一级别。
我的问题是，是的，您可以在 Visual Studio 选项中更改默认项目创建位置，但这会将其设置为整个 sln。理想情况下，我想利用 src、test 等的解决方案文件夹（正如他们通常建议的那样），当您在该文件夹中添加新项目时，默认文件系统位置是 C:\path\to\solution\ src 或 C:\path\to\solution\test 取决于您要添加到的文件夹。这使得添加到该解决方案的人员可以非常轻松地将项目添加到解决方案内和文件系统内的正确位置以进行源代码控制。
默认情况下，无论您在何处添加新项目，它都会尝试将其置于解决方案的同一级别，这意味着虽然它在 Visual Studio 中看起来可能正确，但需要重新排列文件系统（以及源代码管理）否则文件将位于错误的位置。
如果这不是可以自动处理的事情，为什么微软自己会建议这种布局作为默认布局？
请帮忙！
我使用此 Microsoft 教程作为使用 Azure Batch 池、作业和容器的起点。
我已经稍微修改了他们删除池和作业的代码
// Cleanup Batch Account Resources
// Clean up Job
await batchClient.JobOperations.DeleteJobAsync($"{BatchConstants.JobIdPrefix}-{Guid}");
// Clean up Pool
await batchClient.PoolOperations.DeletePoolAsync($"{BatchConstants.PoolIdPrefix}-{Guid}");
当我在本地运行此代码时，这非常有效，但是当它进入我的开发环境时，在删除池或作业（通常是作业）时会遇到问题。我收到状态代码“ServiceUnavailable”。
当我手动登录到 Azure 门户时，我可以看到容器已被毫无问题地删除（因此我知道可以建立连接并且可以成功删除 Azure 对象），但请注意池和作业仍然存在。
它似乎没有JobOperations重PoolOperations试策略的概念，所以如果它返回 ServiceUnavailable 状态，是否有其他方法可以让它重试删除池和/或作业几次？或者我应该在本质上是一个 for 循环中尝试它，如果它返回一个错误的状态代码，该循环最多运行 5（或更多）次，或者如果返回一个好的状态代码，则继续执行程序的其余部分？
谢谢您的帮助。