自行创建的 NuGet 包是否应该置于版本控制中？
我已经开始为我们过去在 ASP.NET 解决方案中使用 svn:externals 的一些常见依赖项项目创建 NuGet 包。我将 .nupkg 文件托管在网络文件夹中，并使用该文件夹位置作为 NuGet 源。
我不确定将哪些文件放置在版本控制中以及放置在何处。您是否将 .nuspec 和 .nupkg 文件都放入存储库中？ .nuspec 和 .nupkg 文件是否都包含在项目的版本控制中？我认为由于 .nuspec 文件生成 .nupkg 文件，您只需要在版本控制中使用该文件。但是，我也认为创建网络文件夹可能是个好主意，我将其用作 NuGet 提要，它本身就是一个存储库。然后我可以对 .nupkg 文件进行版本控制。
对创建的 NuGet 包进行版本控制有哪些好的做法？
I have started creating NuGet packages for some frequent dependency projects we used to use svn:externals for in our ASP.NET solutions. I'm hosting the .nupkg files in a network folder, and using that folder location as a NuGet feed.
I'm unsure what files to place in version control and where. Do you put both the .nuspec AND the .nupkg files in your repository? Do both the .nuspec and .nupkg file go in the project's version control? I thought since the .nuspec file generates the .nupkg file, you'd only need that file in version control. But, I was also thinking it might be a good idea to make the network folder, that I'm using as a NuGet feed, a repo in itself. Then I can version control the .nupkg files.
What are some good practices for version controlling created NuGet packages?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我和你在同一个地方。为了与您不提交任何可以构建的文件的想法保持一致，我的 .nuspec 文件进入版本控制，但 .nupkg 文件则不然。
由于版本号已合并到 .nupkg 文件名中，因此您可以在存储库中同时拥有不同版本的包。您需要在 .nuspec 文件中使用
$version$ 为了让客户端项目自动将小错误修复合并到我们的包中，我们将在客户端项目中启用 NuGet Package Restore，并发布具有简短的固定版本号（例如“1.2”）的包。当包有一个简单的错误修复时，我们将使用相同的版本号重新发布。这将覆盖存储库中的先前版本；客户端项目在构建步骤期间恢复包时将获得更新。
I'm in the same place you are. In keeping with the idea that you don't commit any file that you can build, my .nuspec files go in version control, but the .nupkg files don't.
Since the version number is incorporated into the .nupkg file name, you can have distinct versions of the package in the repository at the same time. You either need to either use the
<version>$version$</version>form in the .nuspec file, and set the assembly version to auto-increment, or just manually change the version number each time. You could then make a Subversion tag on that version number, so you could get back to the source for a particular package version if you need to.In order to let client projects automatically incorporate minor bug fixes in our packages, we're going to enable NuGet Package Restore in the client projects, and publish packages with short, fixed version numbers, like "1.2". When there's a simple bug fix for the package, we'll re-publish with that same version number. That will overwrite the prior version in the repository; client projects will then get the update when they restore packages during the build step.