views:

110

answers:

2

We have a tool that generates some code (.cs) files that are used to build the project.

EDIT: These files are the other half of some partial classes, so the build process requires access to the source. It's not possible to compile it into a DLL, for example, and then set the build order.

The tool is run during the pre-build step, but the files are updated in the solution only after the build, which means the build needs to be performed twice to clear the errors after a change to the input.

Example:

  • Modify Tool Input File
  • Run Build
    • Tool Runs and changes source file
  • Build Fails
  • Run Build
    • Tool Runs and changes source file (but it doesn's actually change, because the input remains the same)
  • Build Succeeds

Any ideas how we can do away with the double build, and still let our tool be run from VS?

Thanks guys!

A: 

refactor your soln into 2 projects: the first gen's the cs file, the second uses it (as a dll).

The first project (call it Gen) has 2 post-build events: 1 to run the tool and re-create the source file, and 2) compile the Gen'ed src file for use by the 2nd project:

Gen.exe 
csc.exe /target:library Gened.cs

The second project (call it Use) references the dll and calls it.

==Gen.cs

using System.IO;
namespace sm3
{class Gen
{static string bod = "public static int var = 46;";
 static string clas = "public class Gened {" + bod + "}";
 static string ns  = "namespace sm3 {" + clas + "}";
 static void Main(string[] args)
 {StreamWriter SW;
     SW = File.CreateText("Gened.cs");
     SW.WriteLine(ns);
     SW.Close();
    }}}

==Use.cs

using System;
namespace sm3
{class Use
    {static void Main(string[] args)
        {Gened g = new Gened();
         Console.Write(Gened.var.ToString());
         Console.ReadLine();
         }}}
ja
We can't do this because the code generated is part of a partial class.
Byron Ross
A: 

It would be trivial to write a VS macro that would execute your tool and then start a build so you could have the whole process executed with a single keypress, in a faster way that doing a double build.

Alternatively (or in conjunction with the above), you could add a custom tool to the VS Tool menu that executes your tool (see Tools->External Tools). Then just manually execute this custom tool before you execute the build - this is still a tedious double step, but much quicker and easier than building twice. (and you will probably be able to leave your tool running in the pre-build step so the old double-build approach will still work).

Another option may be to edit the MSBuild script for your project to Exec your tool earlier in the build process so that the change to the file is picked up during the dependency scans (so only one build pass is needed).

None of these are great solutions, but hopefully they might give you a lead that provides an acceptable improvement over your current situation.

Jason Williams