I had a coupld of custom build rules in my project and have recently upgraded it all from VS2008 to VS2010 and expected it to "Just work".
This is not good. Thankfully the folk at CodeSynthesis had already sorted out the build rule for XSD http://wiki.codesynthesis.com/Using_XSD_with_Microsoft_Visual_Studio and supplied a custom build rule that sorted that out.
Now I just need my build rule for HelpNDoc3 and I am back in business.
My problem is that the Upgrade Wizard, while its obviously done a fair job has either revealed some bugs in my old rule ( and faithfully upgraded those bugs) or its just done a shit job... either way, there are some issues that need fixing and no one else I can push the work onto.
So the current process seems to be:
A) Go use the editor in VS2008 to generate the .rule file and then use the migration wizard to transform the rule into the .target, .props and .xml files for VS2010. Big round trip... lots of moving parts.... but a possibility.
B) Hand edit (hack blindly at..) the three files and try to figure out what you are up to by looking at the malnourished references and examples included with VS2010. Big round trip to test, lots of unknowns, ( there will be PAIN)
C) Hope like hell someone else has already done the work and documented it.
http://blogs.msdn.com/b/vcblog/archive/2010/04/21/quick-help-on-vs2010-custom-build-rule.aspx
Not much to go on but its something.
Hack'n time....
The .XML file
This file defines the property editor interface for use in the solution explorer. After spreading it out in my favorite xml editor and doing some reading, it seems fairly straight forward.This file uses the XAML schema for WinFX. http://msdn.microsoft.com/en-us/library/ms752059.aspx. I dont think VS is using the info in the file as real xaml; its simply structured data that happens to be using the schema for parsing purposes.
If we follow the namespace breadcrumbs I find: http://msdn.microsoft.com/en-us/library/microsoft.build.framework.xamltypes.aspx which seems more meaningful as to the content than UI xaml which this file clearly does not contain. This gives me enough clues to take some guesses at the structure of the data in this file but no fucking idea about the logical effect of adding or removing elements from this file. Where does that info exist I wonder?
Here are some clues:
http://blogs.msdn.com/b/vsproject/archive/2009/06/10/platform-extensibility-part-1.aspx
http://blogs.msdn.com/b/vsproject/archive/2009/06/18/platform-extensibility-part-2.aspx
The .props file
This file seems to contain default values for some of the properties defined in the .xml file above. (Why have them in a seperate file?)There are some clues on this at http://blogs.msdn.com/b/vsproject/archive/2009/06/23/inherited-properties-and-property-sheets.aspx.
and here
http://blogs.msdn.com/b/visualstudio/archive/2010/05/14/a-guide-to-vcxproj-and-props-file-structure.aspx
The .targets file
This file contains a whole lot of shit. Mostly it defines the output for the build file. Logically this defines how the property values from the editor are mapped into the actual build script. Looks hideous and nasty and will be damn hard to debug simply due to the length of the round trip and difficulty of getting useful/meaningful error messages from the build system.The .VCXPROJ file
This file contains (along with everything else) the actual values for the properties as applied to the file item. These are the values at the bottom of the property inheritance chain. (See the link above under the .props file heading for more info on property sheet evaluation orders)Looks like you can do some fairly tricky stunts in the property pages via inline function calls:
http://blogs.msdn.com/b/visualstudio/archive/2010/04/02/msbuild-property-functions.aspx
http://msdn.microsoft.com/en-us/library/dd633440.aspx
I have no use for these at the moment.
No comments:
Post a Comment