何时安装，何时构建，属于较大项目一部分的可视化组件包
上下文：
我一直在开发一个使用许多基于自定义框架的组件的应用程序（这里的人们一直在超级 有帮助 with 正如我一直在学习的！）。
由于我正在修改应用程序经常使用的可视组件，并且这些组件数量相当多且相互关联（正在进行相当多的继承等），因此我想尽可能简化修改/构建过程。
问题：
何时需要实际安装可视化组件包，而不是仅仅构建（或仅“编译”？）EXE项目哪个使用并引用这些组件？当我更改会影响对象检查器的成员时，我是否只需要真正将包“重新安装”到选项板？任何概念性指导都将受到欢迎。
再次感谢，提前。 :)
Context:
I have been working on and off on an application which uses a number of custom frames-based components (which folks around here have been super helpful with as I've been learning!).
Since I am modifying the visual component that the app uses very often, and those components are fairly numerous and interrelated (quite a bit of inheritance going on, etc), I'd like to streamline the modify/build process as much as possible.
Question:
When is it necessary to actually install a visual component package, vs. just building (or only "compiling"?) the EXE project which uses and references those components? Do I only need to truly "re-install" a package to the palette when I change a member that would be affect the Object Inspector? Any conceptual guidance here would most welcome.
Thanks again, in advance. : )
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
IDE 通常会检测您何时重新编译 IDE 已加载的包。当您编译包时，IDE 将首先卸载相关的设计时包，然后在编译完成时尝试重新加载它们。
当包被选为 IDE 中的活动项目时，您应该对包进行更改。 （您可以使用“项目组”让您同时打开多个项目。一次只能有一个项目是“活动”项目。）
这与在编译应用程序时隐式编译包单元相反。我的建议是避免这种情况。它使您的包和项目更容易不同步，部分原因是包不会加载到 IDE 中，部分原因是您更倾向于对包单元进行特定于项目的更改，而不是暂停考虑更改是否真的适合共享包。切换活动项目所需的那一刻足以让您将包和应用程序分开。
The IDE normally detects when you're recompiling a package that the IDE has loaded. When you compile the package, the IDE will unload the relevant design-time packages first, and then it will attempt to re-load them when compilation finishes.
You should be making changes to your package while that package is selected as the active project in the IDE. (You can use "project groups" to let you have multiple projects open at once. Only one at a time can be the "active" project.)
That's as opposed to having your package units compiled implicitly when you compile your application. My advice is to avoid that scenario. It lets your packages and your project get out of sync much more easily, partly because the package won't be loaded in the IDE, and partly because you'll be more apt to make project-specific changes to the package units instead of pausing to consider whether the change is really appropriate for the shared package. The moment it takes to switch the active project can be enough to keep the package and the application separate in your mind.