3

我们有许多库，它们分布在不同的解决方案中（关注点分离）。每次签入时都会构建新的 nuget 包，并且依赖于这些其他包的解决方案可以更新它们的引用。

在一个理想的世界里，一切都应该进行单元测试，CI 测试的原因，但现实生活中的命中，并且在某些时候一些难以重现的极端情况错误表面，并且需要一些本地调试。

为了避免做我们都在某个小项目上尝试过的事情，检查 N 次小修复，结果证明不是修复:) 并获得一个新的构建是痛苦和耗时的。

在 dotnet core 之前，我曾经在引用解决方案中调试这些，只需添加对本地构建 dll 的本地引用并在提交之前修复问题。使用 dotnet 核心，这已被证明是不可能的，因为所有东西都需要包装在一个 nupkg 中。

我还需要一个简单的工作流程/流程来处理 dotnet core 中的这些情况吗？

4

1 回答 1

2

这是我想出的结果，也许有人有更好的方法。

https://twitter.com/pksorensen/status/761590754301079552 https://gist.github.com/pksorensen/df61ded634bad99f85cc68f91c230361

"scripts": {
    "postcompile": [
      "nuget delete -Verbosity detailed -noninteractive -source %USERPROFILE%\\.nuget\\packages %project:name% %project:version%",
      "nuget delete -Verbosity detailed -noninteractive -source c:\\localpackages %project:name% %project:version%",
      "dotnet pack --no-build --configuration %compile:Configuration% -o ../../artifacts/",
      "nuget add -Verbosity detailed -NonInteractive -source c:\\localpackages  ../../artifacts/%project:name%.%project:version%.nupkg"
    ]
  }

使用本地提要，我根据以下内容添加了提要：https ://docs.nuget.org/create/hosting-your-own-nuget-feeds at c:\localpackages。

  1. 然后在每个构建中，我打包并将包推送到这个本地源
  2. 为此，我还必须删除相同的版本，如果它已经存在（删除之一）。
  3. 由于 nuget 还将包缓存在用户文件夹全局文件夹中，因此也必须在那里将其删除。

构建完成后，我只需右键单击并恢复依赖于这些本地包的解决方案中的包。

问题解决后，只需将这两种解决方案再次提交给 CI 系统，它将从正常提要解析包，而不是仅在我的开发机器上可用的本地提要。

于 2016-08-05T21:52:50.087 回答