December 31, 2007
@ 04:36 AM

I know not everyone digs ebooks, but I do. Here are some free ones. [via Development in a Blink]


 
Categories:

December 15, 2007
@ 05:29 AM

Symptoms

  • You've got more than one (Visual Studio) solution depending on the outputs from another.
  • Your checking binaries (.dlls, etc.) that aren't third party into your version control system, as you do with third party stuff.

Causes

  • You have clumps of projects that are highly cohesive. You feel you need to organize them. A solution seems like a good organizational unit above projects.
  • More than one team is working on dependants. To avoid integration pain, they want to work on just their code, using a static version of the dependency (a compiled branch.)

What to Do

  • Put all the projects into one solution.
  • Use folders to organize them, instead of solutions.
  • If there are multiple teams, they all work on their projects in the same solution.
  • If it takes too long to build, unload projects you're not changing right now. Load them again or use a command line build before checking in or doing cross project refactorings.
  • Look at the way modules are implemented in WCSF. Do they look like what you used to have in solutions?

Payoff

  • Reduction in build and version control complexity
  • Reduction in code ownership
  • Less big-bang when updating dependencies.
  • More "we're all in this together"
  • For web applications, you might end up using server resources far more efficiently if the modules can share an app pool. This can make a huge difference when you have a lot of projects.

Contraindications

  • If the project really, really needs to be complicated (say, 100+ screens/pages, each with 20+ controls/fields, or more than 15 developers) then it makes sense to separate them, at the same time spending effort to minimize coupling between the solutions. The idea is to make this more of a last resort. Rough estimate: solution/developer should be about 1/15.

 
Categories:

December 11, 2007
@ 06:43 PM
While I was working this evening, I was listening to my daughter play in the tub while she was supposed to be taking a bath. It's fun to listen to her talk to herself when playing.

One of the things I kept noticing was she would say things like, "If you want to play again, click on the Net. If you want to stop playing, click on the Mermaid." She's kind of been playing video games (not seriously) since she was about 2.

I guess this doesn't really bother me. Just kind of weird the way kids play differently than we did. I probably quoted cartoons or something.


 
Categories:

December 8, 2007
@ 09:30 AM

Update: I just noticed there was already a wix package! It doesn't quite do the same things as mine - it doesn't generate a wxi or components for web project content.

I find that my love for MSIs is inversely proportional to the amount of time I spend messing with them. Using WIX to build MSIs usually involves some up front work, but once you've gotten that out of the way, it's pretty hands off.

I needed to get CI Factory building MSIs for some ASP.NET web projects. While in the process, I got really frustrated, but once I'd gotten the CI Factory package more or less in order...now I think everything should be an MSI.

The big problem is getting all the content (for one of my projects, this includes two sets of flags for every country in the world, plus about 150 other misc. files) into wix components. My package has a nant <script> task to generate wix xml for this. There is a separate shell wxs script that pulls these components in and gets them installed in the right place. Depending on where you are installing your web app in the IIS virtual directory structure, you may need to change this shell wxs script.

Anyway, here is my rough package. I am considering asking Jay Flowers if they would accept this for CI Factory. It would be some work to get it into shape to be part of CI Factory, and the build person (CI Factory user) may still need to create a top level wxs script. Feedback?

If instead, someone just wants to drop this in there CI Factory Build/Packages folder, all you need to do is:

1. Add a bunch of properties to your Properties.build.xml:

  <property name="Wix.ProductName" value="My Company - ${ProjectName}"/>
  <property name="Wix.Manufacturer" value="My Company"/>
  <property name="Wix.Version" value="${CCNetLabel}"/>
  <property name="Wix.ProductID" value="DEADBEEF-DEAD-BEEF-DEAD-DEADBEEF"/>
  <property name="Wix.UpgradeCode" value="DEADBEEF-DEAD-BEEF-DEAD-DEADBEEF"/>
  <property name="Wix.ServiceAccount" value="SomeServiceAccount@MyCompany.com"/>
  <property name="Wix.InstallDirectory" value="${ProjectName}"/>
  <property name="Wix.AppPool" value="SomeAppPool"/>
  <property name="Wix.IIsWithAppPoolSettingsComponentId" value="DEADBEEF-DEAD-BEEF-DEAD-DEADBEEF"/>
  <property name="Wix.IIsWithoutAppPoolSettingsComponentId" value="DEADBEEF-DEAD-BEEF-DEAD-DEADBEEF"/>

2. Add an include for the Wix package (in your Main.build.xml, or Scratch.build.xml, or whatever):

  <description>Begin Package Includes</description>
  ...
  <include buildfile="${PackagesDirectory}\Deployment\Deployment.Target.xml" />
  <include buildfile="${PackagesDirectory}\Wix\Wix.Target.xml" />
  <description>End Package Includes</description>

3. Call Wix.CreateInstaller and Wix.DeployMsi at the end of your build (Main.build.xml):

        <description>Begin Post Build Actions</description>
        ...
        <call target="Wix.CreateInstaller"/>
        <call target="Wix.DeployMsi"/>
        <description>End Post Build Actions</description>
 

4. Call Wix.SetUp and .TearDown in your tear down and setups (Main.build.xml):

  <target name="SetUps">
    <call target="Common.SetUp" />
    <description>Begin SetUps</description>
    ...
    <call target="Wix.SetUp" />
    <description>End SetUps</description>
  </target>
  <target name="TearDowns">
    <description>Begin TearDowns</description>
    ...
    <call target="Wix.TearDown" />
    <description>End TearDowns</description>
  </target>

Now you will end up with an MSI in your artifacts directory. It will show up on the deployment files section of your build report, which is kind of nice. We could send good build reports to testers, and they can just grab the msi from the link.

Please shoot me any feedback or questions. Thanks!


 
Categories: