views:

39

answers:

1

So something I've been doing recently is adding an additional project to my code solutions and doing my post build stuff programmatically in it. This project builds last and then launches itself.

cool stuff I can do there is run an ILMerge automation class I created to perform merges automatically if i just give it a project folder, increment version numbers in my assembly info, copy files where-ever i want, etc etc etc. It seems to me like the possibilities here are endless.

example of one im working with now -- i've got a fairly large framework library that i'm going to be deploying with one of our applications, but obv we dont want to include all the dlls separately (there are like 20). Also i dont need every class in the library for this application, so it makes sense to trim it down. Sooo in the library's post build project, I'm doing this...

        outputDirectory = new DirectoryInfo(@"...postbuildmerges\output");
        solutionDirectory = new DirectoryInfo(@"...mainSolutionDirectory");

        #region Web Lib
        List<string> webLibraryNames = new List<string>
        {
            "Beast.Configuration",
            "Beast.Web",
            "Beast.Data",
            "Beast.Utilities",
            "Beast.Threading"
        };
        List<string> AllNeededAssemblies = new List<string>();
        webLibraryNames.ForEach((libname) => 
            {
                foreach (string assembly in GetLibraryAssemblies(libname))
                    if (AllNeededAssemblies.Exists((assemblyName) => Path.GetFileName(assemblyName) == Path.GetFileName(assembly)) == false)
                        AllNeededAssemblies.Add(assembly);
            });

        SharpMergeAutomator.Merge(
            @"...path to primary assembly...",
            AllNeededAssemblies.ToArray(),
            "...desired output file...",
            //merges xml documentation
            true);
        #endregion

soooo is this post-build project thing a good approach? is it needlessly complicated? is there a better way? do people normally do stuff like this? blah blah blah?

+2  A: 

MSBuild is the scripting language for builds, it gives the ability to easily iterate folder trees committing actions against any filter of files you like etc. You should be doing these things in an MSBuild script I would posit because when a new .net comes out, it will most likely still be the scripting language for builds, and you wont have to change the build scripts to work with the new .net, whereas the more build work you do in code like this, that's just more code you'll have to rewrite as files and things have moved. Plus with MSBuild you get logging by default along with tons of built in stuff.

Also, there are lots of community tasks to easily use for things like ILMerge: http://code.google.com/p/ilmerge-tasks/wiki/HowToUse

Jimmy Hoffa
This is the right approach, albeit the hand writing of MSBuild XML has something of a learning curve. Worth noting pre- and post-build events in the VS prohect properties just populate the approproate build script elements.
Richard
i like the idea of writing these events in csharp. if there were an awesome library available for creating these post build events, could either of you see this as ever being a good idea?
Joshua Evensen