Hi,

I'm thinking that at this point, since I believe I fixed the one or two
things from the comments I received some months ago, I will commit these
changes by end of day Monday unless I hear any objections before then.  From
there, I will perform some nightlys with these changes for public testing.
Sound good?

Thanks,
Ryan

On Fri, Jul 29, 2011 at 10:28 PM, Ryan Boggs <rmbo...@gmail.com> wrote:

> 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
>> >>
>> >>
>> >
>>
>
>
------------------------------------------------------------------------------
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts. 
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
_______________________________________________
nant-developers mailing list
nant-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nant-developers

Reply via email to