Considering starting a software project - anything like this exist?
-
Judah Himango wrote:
Even 1:00 is insane, considering we do many builds per day.
Or perhaps what is "insane" is the number of builds you do per day. What purpose would that serve? I don't know how VS does it's "code analysis" without building on the fly in the background, but anyway it does for the most part do a very good job of immediately indicating invalid parameters, members that don't exist, whether or not a type is recognized (missing the using directive?) and so on. So it seems to me the only time you really need to build is when you need to *run* the code. On the other hand, VS sometimes wants to build stuff on it's own initiative, and often stupidly. For example, if I rename a private method in a "normal" (non-partial) class in the business layer, it sets off to rebuild the web project... I find however that simply using search-and-replace takes care of those cases. The few times it is desireable to rename more accessible members are slow, but it's costing me a few minutes a month. I "lose" *far* more time to codeproject and coffee breaks than to the compiler. When debugging you may of course want to change something and go again. But for that we have edit-and-continue, which is nearly instantanious. Admittedly it doesn't work in web applications, but there are other ways to work around that. In ours I wrote a little console where you can log on to the system the same way you do when using the web ui, and then issue commands to load classes and call methods on them. When our business layer (in class libraries) is run in the context of the console app edit-and-continue does work, which simplifies life for the developer. And it can of course also be used as a crude framework for unit testing (by writing test classes and console scripts that load them and execute test methods). All of that having been said, it can never build too quickly, so I'm sure a lot of people would be interested in any tool that boosted build times 100x. In any event, a programmers job is, in my view, more about thinking that about typing the code. So there's little reason to stop working because you're building.
dojohansen wrote:
Or perhaps what is "insane" is the number of builds you do per day.
Hey that could be. :) How many do you do a day?
Religiously blogging on the intarwebs since the early 21st century: Kineti L'Tziyon Judah Himango
-
Beware. Quick build time means less solitaire.
Steve
You're right. I'll abandon this project immediately. ;)
Religiously blogging on the intarwebs since the early 21st century: Kineti L'Tziyon Judah Himango
-
The project sounds interesting, but... Considering the man-hour cost of writing your software, I honestly wonder if you wouldn't be better off putting your money into better (faster) hardware?
Oh, my boss has already purchased us SSDs at work. Our machines are pretty beefy as it is. This is a personal project that, if it really can significantly decrease build times, I'd go commercial. Keep my day job, but run this project outside that. Make a little money on the side.
Religiously blogging on the intarwebs since the early 21st century: Kineti L'Tziyon Judah Himango
-
JetBrains - Yeah the Java IDE guys - have a Continuous Integration product called TeamCity that does exactly what you're looking for. It's also free for up to 20 developers and 20 build configurations and 3 build agents (remote machines). It has a plugin directly into VS and is a very solid product. It supports the pre-commit build where it identifies that changed files and builds the code base with those changes before they are committed into your SCM. I highly recommend using this product, it saves a lot of broken builds. <a href="http://www.jetbrains.com/teamcity/index.html">http://www.jetbrains.com/teamcity/index.html</a> E. Wallace
elwallacejr wrote:
have a Continuous Integration product called TeamCity that does exactly what you're looking for
Interesting. It significantly decreases build times for large .NET solutions (40+ projects)?
Religiously blogging on the intarwebs since the early 21st century: Kineti L'Tziyon Judah Himango
-
JetBrains - Yeah the Java IDE guys - have a Continuous Integration product called TeamCity that does exactly what you're looking for. It's also free for up to 20 developers and 20 build configurations and 3 build agents (remote machines). It has a plugin directly into VS and is a very solid product. It supports the pre-commit build where it identifies that changed files and builds the code base with those changes before they are committed into your SCM. I highly recommend using this product, it saves a lot of broken builds. <a href="http://www.jetbrains.com/teamcity/index.html">http://www.jetbrains.com/teamcity/index.html</a> E. Wallace
Looks promising. But it appears you need to configure machines in your local network to become part of a grid and assign build chains to run on different machines. While that sounds like a good solution if you've got the time and machines to administer all that, my solution is one that teams don't have to maintain or administer: I would have the beefy machines, I would do the load balancing, I would do the work splitting, etc. From the user's perspective, it would work like magic: instantly faster builds. No need to set up and maintain your own build server farms.
Religiously blogging on the intarwebs since the early 21st century: Kineti L'Tziyon Judah Himango
-
Oh, my boss has already purchased us SSDs at work. Our machines are pretty beefy as it is. This is a personal project that, if it really can significantly decrease build times, I'd go commercial. Keep my day job, but run this project outside that. Make a little money on the side.
Religiously blogging on the intarwebs since the early 21st century: Kineti L'Tziyon Judah Himango
-
Yeah, I'm aware of that. I know .NET doesn't do things this way; the best parallelism we can get is having MSBuild build each project using multiple cores. There isn't file-level parallelism. However, in my anecdotal experience, many .NET solutions have several projects that can be built independently. Potential speed up there. And while MSBuild supports building projects in parallel to a degree, the local disk becomes a bottleneck. By spreading the work across machines, I theoretically could save significant build times.
Religiously blogging on the intarwebs since the early 21st century: Kineti L'Tziyon Judah Himango
modified on Tuesday, September 15, 2009 12:27 PM
Actually, you could do file-level parallel builds if you did a bit of work: First off, you would want to compile the files into individual modules. In C# you would use the /target:module, which generates a file with a .netmodule extension. Afterwards you you would run the AL.exe (assembly linker) to pull the modules together into an assembly. I haven't tried this myself, but it is in the documentation, so it should be possible...
-
Actually, you could do file-level parallel builds if you did a bit of work: First off, you would want to compile the files into individual modules. In C# you would use the /target:module, which generates a file with a .netmodule extension. Afterwards you you would run the AL.exe (assembly linker) to pull the modules together into an assembly. I haven't tried this myself, but it is in the documentation, so it should be possible...
Wow, that's news to me. That is very helpful. Thank you. I will look into this.
Religiously blogging on the intarwebs since the early 21st century: Kineti L'Tziyon Judah Himango
-
Our current project here at work takes about 2:30 to build. Even 1:00 is insane, considering we do many builds per day. Make a change to some low-level component, then suddenly all these dependent projects need to build, and you go on a coffee break as VS thrashes your disk for a while. The idea is to make even large solutions (30-50 projects) build in seconds, rather than minutes. The idea is to eliminate coffee breaks. :)
Religiously blogging on the intarwebs since the early 21st century: Kineti L'Tziyon Judah Himango
But I realy like coffee! besides, it's the only time I get to see real people during the work day.
-
Actually, you could do file-level parallel builds if you did a bit of work: First off, you would want to compile the files into individual modules. In C# you would use the /target:module, which generates a file with a .netmodule extension. Afterwards you you would run the AL.exe (assembly linker) to pull the modules together into an assembly. I haven't tried this myself, but it is in the documentation, so it should be possible...
I looked into this and wanted to let you know the results. This isn't as simple as you may think. Take the following .cs file:
class Foo
{
public Foo()
{
Bar b = new Bar();
Zap z = new Zap();
}
}If I try to compile that using /target:module, the C# compiler tells me it can't find Bar or Zap. I was hoping the compiler could still spit out a .netmodule, and just have the linker resolve the dependencies. Alas, this doesn't seem to work. Now that I think about it, that would be a little too magical. If I wanted to do file-level compilation, I'd need to build a dependency graph for the target file, then compile all those files as a .netmodule. More work than I bargained for.
Religiously blogging on the intarwebs since the early 21st century: Kineti L'Tziyon Judah Himango
modified on Saturday, October 24, 2009 3:36 PM