使用 NAnt 和 Ivy 构建 VB6 项目
我正在使用 Subversion、CruiseControl、NAnt 和 Ivy 为 .Net 和 VB6 应用程序开发一个持续集成系统。
.Net 方面的问题并不是太大的问题，但我需要一些关于 VB6 方面的指导，更多来自“DLL 地狱”方面的指导！
我当前的设置是按照预期获取 VB6 系统的所有依赖文件，并在 ok 内构建各种项目。 但是...它使用的是已经在我的电脑上注册的 DLL，而不是我的 Lib 文件夹中的那些，这是我解决 Ivy 依赖关系的地方。
我可以通过在Ivy解析完下载的DLL后注册它们来解决这个问题，这意味着项目文件可以指向本地的Lib文件夹； 但我希望我的 NAnt 脚本自动执行此操作，然后在构建过程完成后自动取消注册它们，以便下一个项目依次可以执行相同的操作。
我认为我需要帮助的是，能够让 Ivy 给我一份项目依赖项列表...
例如，如果我正在构建项目 X，它依赖于项目 A、B 和 C，那么我是否可以发出给 Ivy 的命令会返回一个列表，例如 A、B、C，然后我可以将它们传递给另一个目标进程以依次注册/取消注册它们...
这有意义吗？ 这可能吗？我是否以正确的方式看待这个问题？ 或者，还有更好的方法？
我很抱歉，我已经绕着房子转了一圈来解释这一点......！
I am working on a continuous integration system for both .Net and VB6 applications using Subversion, CruiseControl, NAnt and Ivy.
The .Net side of things isn't too much of a problem, but I need a little guidance with the VB6 side of things, more from the 'DLL-hell' side of things!
My current set-up is getting all dependent files for my VB6 system, as expected and builds the various projects within ok. BUT... it's using DLLs that are already registered on my PC, and not those within my Lib folder, which is where I am resolving my dependencies from Ivy.
I can get around this problem by registering the downloaded DLLs after Ivy has resolved them, which means that the project file can be pointed at the local Lib folder; but I want my NAnt script to do this automatically, and then automatically un-register them after the build process has completed, so that the next project in-turn can do the same thing.
What I think I need help with, is the ability to have Ivy give me a list of the project's dependencies...
For example, if I am building Project X, which depends on projects A, B and C, then if I could issue a command to Ivy that would give back a list such as A, B, C then I can pass these to another Target process to register/unregister them in turn...
Does this make sense? Is this possible and am I looking at this in the right way? Or is there a better way?
My apologies is I have gone right around the houses to explain this...!!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
Visual Build Pro 在此答案。 其他答案也值得一看。
Visual Build Pro is recommended in this answer. The other answers are worth a look too.
我自己已经找到了这个问题的答案；
我认为我应该使用文件系统来为我提供相同的列表，而不是使用 Ivy 尝试按需生成依赖项列表，因为 Ivy 已经完成了为我解决依赖项的工作，从而导致一个充满 .dll 文件的“lib”文件夹...
我所做的就是获取该 lib 文件夹中的 .dll 文件的列表，将它们存储在属性（变量）中，然后循环返回相同的属性注册/根据需要注销。
真的很简单..！
I have found the answer to this myself;
Instead of using Ivy to try to generate a list of dependencies for me on-demand, I thought I'd use the file-system to give me that same list, as Ivy has done it's job in resolving the dependencies for me, resulting in a 'lib' folder full of .dll files...
All I have done, is get a list of the .dll files within that lib folder, store them in a property (variable) and then cycle back through that same property registering/unregistering as need be.
Simple really..!
我们将项目引用保存在 VBP 文件旁边的单独 REF 文件中，并且我们使用自定义工具在编译期间“修复”VBP。 我们的构建过程深受此页面（我们的工作方式）的启发我们的 REF 文件是直接抄袭他所描述的结构。
在《我们的工作方式》中，您可以点击LJ Johnson 控制您的构建周期 对于无需外部文件即可执行相同“修复”的实用程序。
基本上，修复必须使用 tlbinfo 从可执行文件 (OCX/DLL) 中提取 LIBID，并完全替换 VBP 文件中引用的 guid。 一旦使用了这个不太复杂的过程，您的项目是否使用二进制或项目兼容性就不再重要了。 另外，如果进行完整构建，则无需注册以前的 OCX/DLL。
We keep project references in separate REF files next to our VBP files and we are using custom tool to "fix" VBPs during compile. Our build process is greatly inspired by this page (The Way We Work) and our REF files are direct rip-off of the structure he is describing.
From The Way We Work you can follow a link to L.J. Johnson's Take Control of Your Build Cycle for a utility that does the same "fix" without external files.
Basicly the fix has to use tlbinfo to extract LIBID from the executable (OCX/DLL) and completely replace the guid of the reference in the VBP file. Once this not so complicated procedure is used, it doesn't matter if you are using binary or project compatibility for your projects. Also, if doing full builds none of the previous OCX/DLL has to be registered.