Updated diff to include changes to the DetermineProductVersion method. I decided that rather than relying on one element or attribute tag, might as well check through them all. This method will now check for the ProductVersion element first for the msbuild project version. If that element doesn't exist, it will then check for the TargetFrameworkVersion element. If neither of those elements exist, it'll then check the ToolsVersion attribute of the Project for a version number. If none of these items exist in the msbuild file, the method will default to 2.0. I figured that this approach would be the most detailed in getting the propert msbuild project file's version number.
The diff is located in the patches section in sourceforge: https://sourceforge.net/tracker/index.php?func=detail&aid=3311661&group_id=31650&atid=402870 I also opened a new review as the old one was getting cluttered. It is CR-63. https://fisheye1.atlassian.com/cru/CR-63 Please let me know if this looks good to commit to the tree. Thanks, Ryan On Fri, Jul 22, 2011 at 11:43 AM, Ryan Boggs <rmbo...@gmail.com> wrote: > Hi, > > Thought I put in such a patch but it looks like I didn't yet. I will > see about creating it today. > > Thanks, > Ryan > > On Fri, Jul 22, 2011 at 2:54 AM, Martin Aliger <martin_ali...@gordic.cz> > wrote: >> Yes, your solution is better. Depending on ProjectVersion was throwing odd >> exceptions when it was not included (which happens even in VS for whatever >> reason): >> >> >> <internalerror> >> <type>System.ArgumentException</type> >> <message><![CDATA[Version string portion was too short or too >> long.]]></message> >> <stacktrace><![CDATA[ at >> System.Version.VersionResult.SetFailure(ParseFailureKind failure, String >> argument) >> at System.Version.TryParseVersion(String version, VersionResult& result) >> at System.Version.Parse(String input) >> at System.Version..ctor(String version) >> at NAnt.MSBuild.MSBuildProject.DetermineProductVersion(XmlElement >> docElement) >> at NAnt.VSNet.ProjectBase..ctor(XmlElement xmlDefinition, SolutionTask >> solutionTask, TempFileCollection temporaryFiles, GacCache gacCache, >> ReferencesResolver referencesResolver, DirectoryInfo outputDir) >> at NAnt.MSBuild.MSBuildProject..ctor(SolutionBase solution, String >> projectPath, XmlElement xmlDefinition, SolutionTask solutionTask, >> TempFileCollection tfc, GacCache gacCache, ReferencesResolver refResolver, >> DirectoryInfo outputDir) >> ... >> >> ToolsVersion should be more accurate as well. I'd need to test it yet, >> though. >> >> Martin Aliger >> >> -----Original Message----- >> From: Ryan Boggs [mailto:rmbo...@gmail.com] >> Sent: Wednesday, June 22, 2011 2:36 AM >> Subject: Re: [nant-dev] Updates to MSBuild & VSNet Tasks >> >> Hey Dominik, >> >> I saw your notes in the atlassian review and I see your point. It would >> probably make more sense to use the "ToolsVersion" property rather than >> relying on the PropertyGroup/ProductVersion xml node. I just took a look at >> some project files created by Sharpdevelop and none of the project files had >> that xml node but they did have the ToolsVersion property. I can give this >> another run through later this week. >> >> Thanks, >> Ryan >> >> > ------------------------------------------------------------------------------ Storage Efficiency Calculator This modeling tool is based on patent-pending intellectual property that has been used successfully in hundreds of IBM storage optimization engage- ments, worldwide. Store less, Store more with what you own, Move data to the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/ _______________________________________________ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
