Anyone had a change to review this yet? Does it look ok to commit? Please
let me know.
Thanks,
Ryan
On Fri, Jul 22, 2011 at 5:17 PM, Ryan Boggs <rmbo...@gmail.com> wrote:
> 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
> >>
> >>
> >
>
------------------------------------------------------------------------------
Got Input? Slashdot Needs You.
Take our quick survey online. Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
_______________________________________________
nant-developers mailing list
nant-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nant-developers
