建设需要很长时间。怎么跟那个打呢?

发布于 2024-09-27 15:48:21 字数 217 浏览 7 评论 0原文

谈到编译语言(在我的例子中是 c#),我认为无论您的开发机器的性能如何,这个问题将永远存在。构建时间可能或多或少取决于具体的环境,但通常它足以让你的注意力从你的任务转移到其他东西,比如 stackoverflow、youtube、twitter 等,这非常烦人。

我为 Java 开发人员感到高兴,因为 Java 的动态类加载,但是 .net(和其他)开发人员可以做些什么来使构建过程不那么痛苦和烦人呢?

Speaking about compiled languages (c# in my case) I think that problem would always remain, no matter how performant your develop machine is. Build time could be more or less depending on concrete environment, but often it's enough to make your attention wanna move from your task to something else like stackoverflow, youtube, twitter etc. and it's just very annoying.

I'm happy for java developers because of Java's dynamic class loading, but what can .net (and others) developers do to make build process less painful and obtrusive?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(7

如果没有你 2024-10-04 15:48:21

我们使用多种构建配置来在速度和全面构建之间进行权衡。

完整的构建会执行一些耗时的事情,例如 FX cop 分析、ASP.NET 编译、所有单元测试项目、实体框架视图预生成等。

“快速构建”通常只需要几秒钟,而这些是完成任务所需的最低限度。让项目运行起来。

开发人员根据需要在整个工作流程中在完整构建和快速构建之间切换。

We use multiple build configurations to trade-off between speed and a comprehensive build.

A full build does time-consuming things like FX cop analysis, ASP.NET compilation, all unit test projects, Entity Framework view pre-generation, etc.

A "fast build" typically takes just a few seconds and those the bare minimum needed to get the project running.

Developers switch between the full build and the fast build throughout their workflow, as needed.

第几種人 2024-10-04 15:48:21

类文件是否也必须构建?与编译时相比,这不会只是将工作负载转移到运行时吗?这其实没什么区别不是吗?软件越大,自然地,构建它所需的时间就越长,这取决于机器而不是语言或框架 - 这是强类型、解释字节代码(或取决于语言/编译器的二进制代码)等事物的权衡)而不是每次运行时解释源代码(就像 php 和 python 等一样)。我不认为java改进了很多东西,你必须在一个时间框架内构建你的应用程序。

我认为与C和C++相比,C#和java在编译时间方面有了巨大的改进。

就利用偷懒的时间吧:

Compiling

来源

Don't the class files have to be build as well? Wouldn't that just put the workload to runtime in contrast to compile time? That's not really a difference isn't it? The bigger software grows, naturally, the longer it takes to build it, depending on the machine and not on the language or framework - this is the tradeoff for things like strong typing, interpreted byte code (or binary code depending on the language/compiler) instead of interpreted source code at each run (as you have with php and python etc). I don't think java improves things much, there will a timeframe you have to build your application in.

I think in comparision to C and C++ both C# and java have improved immensely on the account of compile time.

Just use the time for slacking off:

Compiling

source

网名女生简单气质 2024-10-04 15:48:21

可以尝试的一些操作:

  1. 对包含源代码的驱动器进行碎片整理

  2. 从病毒扫​​描程序中排除源代码文件夹

  3. 从 Windows 搜索索引器中排除源代码文件夹

  4. 禁用任何您未使用的 Visual Studio 扩展

Some things to try:

  1. Defragment the drive containing your source code

  2. Exclude your source code folders from the virus scanner

  3. Exclude your source code folders from the Windows Search indexer

  4. Disable any Visual Studio extensions that you are not using

那小子欠揍 2024-10-04 15:48:21

你的问题中关于注意力偏离任务的评论让我想起了这个 Joel on Software 因此,

投资固态磁盘(因为我假设您在开发和调试时正在谈论开发盒上的构建过程)可能会有所帮助。

此外,让你的计算机运行得更快通常不会有什么坏处,对吧? :)

The remark in your question about one's attention wandering off-task reminded me of this Joel on Software post.

So investing in solid-state disks (since I'm assuming you're talking about the build process on a dev box while you're developing and debugging) could help.

Besides, making your computer faster in general can't hurt, right? :)

心的憧憬 2024-10-04 15:48:21

除了获得更快的计算机、从解决方案中删除不必要的项目等许多其他建议之外,还可以考虑使用 Visual Studio 2010 + 多核计算机。 VS2010 在构建时可以利用所有核心。查看此帖子了解更多信息关于如何设置它。

In addition to many of the other suggestions to get a faster machine, remove unnecessary projects from your solution, etc, consider Visual Studio 2010 + a multicore machine. VS2010 can take advantage of all of your cores when doing a build. Check out this thread for more on how to set that up.

南风几经秋 2024-10-04 15:48:21

您是否每次都进行重建,或者是否将所有内容都放在同一个组件中?我正在处理相当大的项目,而且我的构建时间并不长。我有几个程序集,每次对项目进行更改时我只修改一些程序集。

如果您发现自己到处修改程序集,您可能会尝试重构代码结构。或者也许您没有花时间进行单元测试?它们不仅可以帮助您进行测试,还可以帮助您获得更好的代码结构(很难测试设计糟糕的应用程序)。

另一种选择是使用加速构建的工具,例如:http://www.xoreax.com/

Are you doing a rebuild all every time or do you have everything in the same assembly? I'm working with quite large projects and my build time isn't that high. I got several assemblies and I only modify a few each time I do changes to the project.

If you find yourself modifying assemblies all over the place, you might try to refactor your code structure. Or maybe you haven't taken yourself time to do unit tests? They do not only help you with the testing, but to get better code structure (hard to test apps with lousy design).

Another alternative is to use tools that speed up builds, for instance: http://www.xoreax.com/

时光与爱终年不遇 2024-10-04 15:48:21

我参与过一些非常大的 C# 项目,很少看到调试构建时间超过 2 分钟。

通常消耗时间的是静态分析(例如 fxcop)、单元测试、代码签名(如果使用代码签名服务)等。控制这些的最简单方法是将它们限制为发布版本或拥有一个为“完整构建”单独构建定义,并从调试和发布构建中排除这些步骤。

如果这些不是您的问题,请像其他人所说的那样检查您的计算机性能。碎片、慢速构建磁盘、防病毒等。

I've worked on some very large C# projects and have rarely seen Debug build times exceed 2 minutes.

What generally sucks time are things like static analysis (e.g. fxcop), unit tests, code signing (if using a code sign service), etc. The easiest way to keep these under control is to either limit them to Release builds or to have a separate build definition for 'Full Build' and exclude these steps from your Debug and Release builds.

If these aren't your problems, look to your computer performance as others have said. Fragmentation, slow build disks, anti-virus, etc.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文