Have you ever needed to process an assembly prior to having it packaged up for deployment? A classic example of this requirement is using an obfuscator or signing/watermarking tool.
Prior to the introduction of the VS2010 SharePoint tools, the general advice was to use AfterBuild (reference How to: Extend the Visual Studio Build Process). Unfortunately, this doesn’t really work when dealing with solution packages built in VS2010.
The reason is pretty simple – AfterBuild is too late. You can run your assemblies through the tooling process, but the modified assemblies won’t be a part of your solution package. The packaging step picks up the assemblies before AfterBuild kicks off.
How about AfterCompile? This window of opportunity for post-processing your assembly is ok, but not entirely what you want to use. You will get your processed assembly into the solution package; however, since the tool will modify your assembly, in the long run you will be wasting a lot of time and cpu as AfterCompile will be called multiple times. On a fast running process, you may never even notice this is happening. On a long running process, your mods will trigger multiple calls to compile and the time to completion will literally get out of hand.
The right solution? Override AfterLayout.
This target is new target that is listed as a dependency by the CreatePackage target found in Microsoft.VisualStudio.SharePoint.targets.
All you need to do is open up your project file and add a definition for AfterLayout as shown below:
As you can see, AfterLayout is the perfect solution!
The really nice thing is you can use conditional expressions to define when to run the post-processing tool. In the example above, the tool is run only when working with Release builds.
The build process will go through and copy all the files into the pkg folder. AfterLayout is called once all the files are dropped into the folder, but before they are bundled up into the wsp. Your post-processing tool can then reference the built assembly from the pkg folder.
Ta-da! Done. Your post-processing tool will run when you need it w/o taking the multi-run penalty of using AfterCompile.
Just to give you an example of how efficient AfterLayout is compared to AfterCompile, we recently reduced our build times on one of projects from roughly 3 hours to under 32 minutes. Old habits of defaulting to AfterCompile basically cost us a lot of time early on in our dev cycle… I can’t tell you how nice it was to get builds back down to normal times. 🙂