Spent a couple of hours this morning trying to pin point a problem I had with an older release of (new install I couldn't run or debug) upon further investigation i noticed it was just on extension methods. the following blog post solved the problems
http://oshyn.com/_blog/Software_Development/post/DOTNET-Extension-Methods-for-extending-classes-not-working-in-inline-code/
Monday, 27 June 2011
Saturday, 25 June 2011
Building Projects in Parallel
I've been a little frustrated with how long it takes to build the main solution in my new job, having some 37 projects it seams to take an age to rebuild and get back to running and debugging after a change.
so my first problem is to enable the build time to be output so I can see how long it actually takes so I can prove my changes actually make a difference. so a quick google brings up VSCommands (how did I miss this tool before), while VSCommands can show a build summary the version containing this feature is only available for VS2010.
So back to google for another stab at it. this time I find this. perfect a macro that logs the time taken and puts it in the output window.. so how long does it take.. 00:03:45.0148701 while this doesn't seam too long it can be very annoying.
Moving on, after a few more minutes on google (google really is your friend) good old Scott Hanselman comes to my rescue once again. following advise from this blog I started doing some experiments, building the solution with 1 core using ms build took: 00:00:17.70 so what the hell is VS playing at maybe its because the build is running in the same process?? who knows.. Anyway when I switched this to auto detect the number of cores it brings the build time down to 00:00:11.96 now this figure I can live with. With just 30 minutes of searching I've managed to increase the build time 20 fold.
Unfortunately this doesn't really help the build time when you start debugging, but I think its useful non the less.
(update)
Strangely when using auto detect only 3 processes get spawned. so I tried specifying the number of cores to 4 and got it down to 00:00:11.32. the difference is so negligible that I've left it up to MSBuild to detect the number of cores.
(update 2)
I'm still not convinced by these figures.. need to look at this again..
so my first problem is to enable the build time to be output so I can see how long it actually takes so I can prove my changes actually make a difference. so a quick google brings up VSCommands (how did I miss this tool before), while VSCommands can show a build summary the version containing this feature is only available for VS2010.
So back to google for another stab at it. this time I find this. perfect a macro that logs the time taken and puts it in the output window.. so how long does it take.. 00:03:45.0148701 while this doesn't seam too long it can be very annoying.
Moving on, after a few more minutes on google (google really is your friend) good old Scott Hanselman comes to my rescue once again. following advise from this blog I started doing some experiments, building the solution with 1 core using ms build took: 00:00:17.70 so what the hell is VS playing at maybe its because the build is running in the same process?? who knows.. Anyway when I switched this to auto detect the number of cores it brings the build time down to 00:00:11.96 now this figure I can live with. With just 30 minutes of searching I've managed to increase the build time 20 fold.
Unfortunately this doesn't really help the build time when you start debugging, but I think its useful non the less.
(update)
Strangely when using auto detect only 3 processes get spawned. so I tried specifying the number of cores to 4 and got it down to 00:00:11.32. the difference is so negligible that I've left it up to MSBuild to detect the number of cores.
(update 2)
I'm still not convinced by these figures.. need to look at this again..
Friday, 24 June 2011
Almost easy
Well I have TC on my local machine and I've copied the template and most of the settings. I couldn't find a way to easily clone the settings and import them to my local server, so I just copied them via the UI (did i miss something here?)
I managed to get msbuild to build the vb6 stuff into a temp dir (I had a few more issues with the dependancies) and overwrite the exes ready to push then back into svn. then decide it was time to commit my changes to the branch and see if it would build.
After a few false starts with not committing the new build script, and then not telling TC to fetch the externals I think were there with the building (its still running as I type so it might be finished before the end)
bugger the build failed. will provide an update later..
(update)
well its building now (1 of the 6 vb projects didn't use the project name as its exe name so when it tried to copy it back it failed). I've also updated the externals to all be branches, so that's safe too now. now ill get the tigris bits.
I managed to get msbuild to build the vb6 stuff into a temp dir (I had a few more issues with the dependancies) and overwrite the exes ready to push then back into svn. then decide it was time to commit my changes to the branch and see if it would build.
After a few false starts with not committing the new build script, and then not telling TC to fetch the externals I think were there with the building (its still running as I type so it might be finished before the end)
next up is to add the tigris tasks and try and commit the changes back.
oh maybe it would be a good idea at this point to branch the externals too. so I don't commit back to the trunk. few... glad i though of that now.
bugger the build failed. will provide an update later..
(update)
well its building now (1 of the 6 vb projects didn't use the project name as its exe name so when it tried to copy it back it failed). I've also updated the externals to all be branches, so that's safe too now. now ill get the tigris bits.
Thursday, 23 June 2011
On to MSBuild and Teamcity
Right I took a good look at WIX (well I skimmed over the getting started doc just to get a feel for it.) then moved onto MSBuild. I need to get a good idea of the whole process (code to deployed) before I can really put forward any serious suggestions for improvement.
So yesterday I took a look at the nightly batch script that currently builds our VB6 apps, with a view of moving them to to msbuild and ultimately over to team city. Looking at the script it all looked pretty straight forward. So I grabbed the msbuildextensions pack from codeplex took a look at the documentation, and put a very simple build script together, using mostly default settings. pointed it at the vbp and ran it. This appeared to be working. so off I go to make tea. upon my return... build failed :(. (exit code 1 link.exe failed )
So I take another look at the batch script. this time in a little more detail. Turns out just before we build the apps we put an svn lock on the exes (yes the compiled files are stored in svn). unfortunately there is no way to put a lock on a file in svn from msbuild, well not out the box or via community tasks (unless ive misssed something? ), I guess I could build a custom task, but I don't think its worth it. so I change the output dir and set it off again, and went to make more tea. upon my return build succeeded. at last were getting somewhere.
Now due to the way we currently have team city set up to pull the source (auto on server) it just performs an export so all svn data is missing, need to change this to auto on agent (this performs a checkout and retains all svn info), not ready to start changing anything on the production boxes just yet so time to install team city locally and create a branch of the src to prototype this properly. Now how do I copy the config off the server without access to the box... found it if you do a diff of changes it gives you the raw xml. now I need a light weight editor on this box. (I find vs with all it bells and whistles a little too heavy for simple text manipulation. so I'm off to fetch notepad++)
this blog really is living up to its name. thetownfool is rambling again....
So yesterday I took a look at the nightly batch script that currently builds our VB6 apps, with a view of moving them to to msbuild and ultimately over to team city. Looking at the script it all looked pretty straight forward. So I grabbed the msbuildextensions pack from codeplex took a look at the documentation, and put a very simple build script together, using mostly default settings. pointed it at the vbp and ran it. This appeared to be working. so off I go to make tea. upon my return... build failed :(. (exit code 1 link.exe failed )
So I take another look at the batch script. this time in a little more detail. Turns out just before we build the apps we put an svn lock on the exes (yes the compiled files are stored in svn). unfortunately there is no way to put a lock on a file in svn from msbuild, well not out the box or via community tasks (unless ive misssed something? ), I guess I could build a custom task, but I don't think its worth it. so I change the output dir and set it off again, and went to make more tea. upon my return build succeeded. at last were getting somewhere.
Now due to the way we currently have team city set up to pull the source (auto on server) it just performs an export so all svn data is missing, need to change this to auto on agent (this performs a checkout and retains all svn info), not ready to start changing anything on the production boxes just yet so time to install team city locally and create a branch of the src to prototype this properly. Now how do I copy the config off the server without access to the box... found it if you do a diff of changes it gives you the raw xml. now I need a light weight editor on this box. (I find vs with all it bells and whistles a little too heavy for simple text manipulation. so I'm off to fetch notepad++)
this blog really is living up to its name. thetownfool is rambling again....
Tuesday, 21 June 2011
Thought it was about time
Having been a long time reader of blogs in various guises, and after threatening to create my own (for more than 3 years now) I thought it was about time I bit the bullet and actually got off my backside and did something about it.
Having started a new job a few weeks ago, and as my first task is to review their CI process. I guess now is as good a time as any. over the coming weeks and months ill try and document the problems we're having and the solutions we find.
We're having some major problems with deploying a vb6 app and its dependencies (of which there are many) and this is yet to be integrated into Team City. Going to take a good look at WIX today, to see what is capable of.
Having started a new job a few weeks ago, and as my first task is to review their CI process. I guess now is as good a time as any. over the coming weeks and months ill try and document the problems we're having and the solutions we find.
We're having some major problems with deploying a vb6 app and its dependencies (of which there are many) and this is yet to be integrated into Team City. Going to take a good look at WIX today, to see what is capable of.
Subscribe to:
Comments (Atom)