作者:小妖2502898957 | 来源:互联网 | 2023-08-19 08:11
C#编译构建增量过程吗?我们的解决方案包含许多C#项目。它们之间存在复杂的依赖关系,例如。项目ABC,B上的家属,B上的家属。如果我在项目C中更改了一个文件,然后重建解决方案,项目
C#编译/构建增量过程吗?
我们的解决方案包含许多C#项目。 它们之间存在复杂的依赖关系,例如。 项目A / B / C,B上的家属,B上的家属。如果我在项目C中更改了一个文件,然后重建解决方案,项目A,B,C将一起重建。
在C ++中,build包含两个进程,编译和链接。 如果我在项目C中更改了一个文件,那么我构建解决方案,将编译A和B中的相关文件(其他文件将不会被编译,其.obj将在链接过程中重用),然后进行链接。
在java中,只需重新编译项目C中的已更改文件,其他文件将保留,然后打包到.jar。 它重用以前的工作输出(未更改文件的.class)。
总之,C#不重用任何以前的工作输出。 它没有像Java的.class和C ++的.obj那样的任何中间文件。 所以在这一点上,我觉得C#不做增量构建过程。 一些小的改变将导致一个大的构建过程。 我不明白为什么C#不使用以前的工作输出来加速构建过程。
我不确定我对C#编译/构建过程的理解是否正确。 你能帮忙解释一下吗? 非常感谢。
C#编译器进行渐进式编译,我不确定你认为它没有的地方。 也许,由于您的解决方案的复杂性,您无法正确理解依赖关系,并且您认为不需要重新编译的项目实际上是必要的。
检查编译器行为的最佳方法是创建一个简单的虚拟解决方案并使用它:
建立:
- 创建一个空的Visual Studio C#解决方案。
- 添加任意两个项目
A
和B
- 使项目
B
成为项目A
的参考。
- 在
B
实现一个类FooInB
并在A
BarInA
中的另一个类中使用它。
现在让我们玩这个设置:
- 编译解决方案。 您将看到两个项目都编译。
- 再次编译解决方案。 您将看到没有任何项目编译,两者都是最新的。
- 更改
BarInA
的实现并再次编译。 您将看到只有一个项目编译, A
。 由于没有变化,因此无需再次编译B
- 更改
FooInB
的实现并最后一次编译。 您将看到两个项目都编译。 这种行为是正确的, A
依赖于B
因此B
任何更改都必须再次重新编译以确保它指向最新版本的B
在理论世界中, C#编译器可以检测到B
的更改是否在B
中没有后果,因此可以再次“优化”远离建筑物A
,这将是一个噩梦场景,其中每个项目可能引用不同的和过时的汇编版本。
也就是说,我想指出,AFAIK,C#编译器只会在项目级别执行增量编译。 我不知道任何给定程序集内的类级别的任何增量编译优化。 对编译器内部工作有更深入了解的人可能能够澄清这种行为。
你是对的。
如果项目A依赖于项目B.依赖项目B的更改确实需要重新编译项目A.
如果项目B依赖于项目C.项目B的更改,不会使项目C重新编译。
在Java中,一个类/文件被编译为单个.class文件。 因此,当单个文件发生更改时,不会重新编译整个项目。
在分发之前,这些.class文件被组合成.jar。 如果单个.class文件发生更改,则还需要重新组装整个.jar。
在.Net中,您立即将项目编译为程序集(.dll或.exe),因此单个文件更改需要重新编译整个程序集。
在Java环境中可以看到相同的行为,其中.jar(或.apk等依赖项)用于运行/调试应用程序。 在开发过程中也需要整个.jar。 当单个文件发生更改时,将重新编译整个项目。
您始终可以在解决方案之外放置项目。 并且只添加他们生成的.dll的引用。 这将最小化编译时间。
好的..你实际上是在正确的轨道上..如果解决方案中有3个项目,你可以将一个项目的参考提供给另一个项目。 这意味着项目A依赖于项目B依赖于项目C ..
构建项目时,所有构建的文件和dll(来自后构建事件)最终都在该项目的bin文件夹中。
因此,当您构建项目A时,项目C将首先构建(因为A-> B-> C)。 项目B使用项目C的构建组件并创建自己的组件。 和项目A使用B和C的组件并创建自己的组件。
因此,如果您只构建项目A,如果引用正确,您将在项目A的bin文件夹中看到B和C的所有构建文件。
我有一个包含许多项目和更多跨项目参考的解决方案。
为简单起见,我想说我有A
B
和C
项目。
我的主要问题是: B
需要大约四十五秒才能编译。 现在让我说我只改变C
的一小段代码,编译器将编译C
,之后它将编译B
,而不是A
因为我主要更改C
中编译速度非常快的代码我总是要等待B
编译。
我从redgate发现了.NET Daemon
。 这是一个更改构建过程的工具,只有在C
的公共API发生更改时才会重建B
这可能会对您的构建过程产生巨大影响。 我想说,根据我的个人经验,它可以节省大约80%的建筑时间。
但是,我只是看了,他们不再卖了它: https : //www.red-gate.com/products/dotnet-development/dotnet-demon/
Visual Studio 2015将介绍微软的新Roslyn编译器,我们认为这些改进使.NET Demon变得多余。
我仍然在Visual Studio 2013上,但我认为对于带有Roslyn的Visual Studio 2015,对构建过程的初步观察以及关于.NET构建的其他答案可能不再适用。 也许它的行为更像是dotnet-deamon构建。
旁注:我的新项目使用IOC
容器,所有内容都在主项目中连接,没有太多交叉项目引用。 这也将改善构建过程,因为几乎所有东西都可以并行构建。
所有版本的C#(MSBuild确实)都支持非依赖项目的增量编译。
VS2003中的C#支持项目中的增量编译。 有一个uservoice建议将该function转发到最新的C#版本。
我已经使用Jenkins MSBuild插件进行了测试,增量构建按预期工作,只有重新编译的项目才会被重新编译。
我想要的是进行增量部署,只部署这些已更改/重新编译的dll。 现在我如何才能有效地找到重新编译的dll。
上述就是C#学习教程:C#编译/构建增量过程吗?分享的全部内容,如果对大家有所用处且需要了解更多关于C#学习教程,希望大家多多关注—编程笔记