2013-07-31 31 views
0

我的团队遇到了一个问题,在使用Nuget进行程序包管理时,它会在我的项目中为特定版本的dll创建引用。有没有办法阻止Nuget创建这些紧密耦合的引用?Nuget为项目中的程序集创建了特定的版本引用

有点背景。

我们使用nuget来管理我们的内部共享库。软件包通常使用VS UI进行安装。 Nuget软件包是使用.csproj文件上的nuget.exe规范和nuget.exe软件包创建的。

我们使用主线dev的标准分支策略在trunk上完成并释放rc分支。

我们不想通过命名我们的所有软件包x.y.z-build123来进入版本控制地狱,因为开发人员可能需要从我们的CI系统执行本地构建,并使用它来测试下游解决方案。我们的答案是简化我们的软件包版本控制,说所有的trunk构建都只是xyz-staging,然后rc build命名为xyz这将使开发人员能够执行本地构建,并在nuget.exe安装的帮助下指向开发机器上的一个存储库使用他们在下游解决方案中的版本。无需更新软件包等。

我们看到的问题是,虽然这在包级别上工作正常。由于项目中的引用是程序集的特定文件版本,因此构建失败。在本地开发版本上的版本不会包含内部版本号,但是它将在CI服务器上。

即。

一个项目有一个类似于下面的参考。

的版本(123)的内部版本号的部分是CI服务器的本地开发机器上的不同地方,通常为0

有没有什么办法让的NuGet创建版本不可知的引用,例如只是程序集名称,而不是这个几乎强大的名称。

回答

0

也许可以通过项目上的binding redirects进行诀窍。

但是请考虑两个具有相同id和版本的NuGet包被认为是相同的包,并且这是由设计

考虑这种情况:

  • 您从变更发布包“foo.1.2.3分期” 1
  • 我安装它在我的解决方案
  • 您发布包“foo.1.2 0.3-举办”从变更2(也许这是一个bug修复)
  • 我的NuGet绝不会通知更新,更有甚者,在建立我的机器上的每个解决方案,将继续使用旧的(缓存)版本

所以你强迫你的开发人员每次创建解决方案的时间来清除缓存的NuGet,只是为了确保他们使用的是“真实”的版本

+0

感谢。这是我们长期争论的问题。这两者都不是理想的,而且我开始思考使用Nuget来管理内部软件包的圆形孔,圆孔。 – Fen

1

看来,我已经找到了解决这个。

我在试图重现该问题创造了一个新的控制台项目。添加了我最初使用的软件包,并添加了没有版本信息的软件包!

我看不出我以前的项目中的任何奇怪的设置,以便开始瞎搞。我能够通过以下步骤重新创建问题。 1)NuGet包添加到您的项目 2)建立 3)卸载NuGet包 4)重新安装NuGet包

这4步让包安装与版本信息项目。

这一切都归结为是,如果你在你的bin文件夹中有组件已经和您尝试添加(或卸载并重新安装)新的引用将被添加到版本信息的项目。

的解决方案是,确保你总是处理的NuGet前清理您的解决方案。

相关问题