Re: [nant-dev] Updates to MSBuild & VSNet Tasks
After all the work that has been put into these VS.NET/MSBuild changes, they have been finally committed. Thanks for the hard work guys. Thanks, Ryan On Sun, Aug 7, 2011 at 3:25 PM, Ryan Boggs wrote: > Ah, good catches. I've made the changes in my tree and they are ready for > committing. > > If I don't hear anything else, all of these changes that Dominik, Martin, > and myself have worked hard on will be committed tonight. > > Thanks everyone :) > Ryan > > On Sun, Aug 7, 2011 at 1:33 PM, Dominik Guder wrote: > >> Am 06.08.2011 21:12, schrieb Ryan Boggs: >> >>> 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? >>> >>> Another minor fix: >> please add the missing entry to xmldoc >> >> Thanks >> >> Dominik >> >> -- >> The answer to the great question of life, >> the universe and everything is 42 (Douglas Adams) >> >> >> -- >> BlackBerry® 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 >> >> > -- BlackBerry® 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
Re: [nant-dev] Updates to MSBuild & VSNet Tasks
Ah, good catches. I've made the changes in my tree and they are ready for committing. If I don't hear anything else, all of these changes that Dominik, Martin, and myself have worked hard on will be committed tonight. Thanks everyone :) Ryan On Sun, Aug 7, 2011 at 1:33 PM, Dominik Guder wrote: > Am 06.08.2011 21:12, schrieb Ryan Boggs: > >> 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? >> >> Another minor fix: > please add the missing entry to xmldoc > > Thanks > > Dominik > > -- > The answer to the great question of life, > the universe and everything is 42 (Douglas Adams) > > > -- > BlackBerry® 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 > > -- BlackBerry® 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
Re: [nant-dev] Updates to MSBuild & VSNet Tasks
Am 06.08.2011 21:12, schrieb Ryan Boggs: 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? Another minor fix: please add the missing entry to xmldoc Thanks Dominik -- The answer to the great question of life, the universe and everything is 42 (Douglas Adams) diff -r 97ca578ef4f5 src/NAnt.MSBuild/MSBuildProject.cs --- a/src/NAnt.MSBuild/MSBuildProject.csSat Aug 06 23:07:12 2011 +0200 +++ b/src/NAnt.MSBuild/MSBuildProject.csSun Aug 07 22:30:20 2011 +0200 @@ -254,6 +254,7 @@ /// /// ToolsVersion attribute /// +/// /// /// /// A representing the msbuild project file. -- BlackBerry® 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
Re: [nant-dev] Updates to MSBuild & VSNet Tasks
Hi Ryan,
these changes are good rom my point of view.
I have ony one minor thing what I can't test since I have difficulties
to debug nant at the moment.
MSBuildProject.cs within DetermineProductVersion line 279
if (_productVerNode != null) {
Version _ver = new Version(_productVerNode.InnerText);
_productVerNode.InnerText might be empty especially in vb.net projects.
Which results in an exception since "" is not valid vor Version
constuctor. You might use following:
if (_productVerNode != null &&
!StringUtils.IsNullOrEmpty(_productVerNode.InnerText))
Well done
Dominik
Am 06.08.2011 21:12, schrieb Ryan Boggs:
> 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
>
>
--
The answer to the great question of life,
the universe and everything is 42 (Douglas Adams)
--
BlackBerry® 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
Re: [nant-dev] Updates to MSBuild & VSNet Tasks
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 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 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 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 >> 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): >> >> >> >> >> >> >> >> System.ArgumentException >> >> >> >>
Re: [nant-dev] Updates to MSBuild & VSNet Tasks
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 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 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 > 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): > >> > >> > >> > >> System.ArgumentException > >> > >>
Re: [nant-dev] Updates to MSBuild & VSNet Tasks
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 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 > 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): >> >> >> >> System.ArgumentException >> >>
Re: [nant-dev] Updates to MSBuild & VSNet Tasks
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 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): > > > > System.ArgumentException > >
Re: [nant-dev] Updates to MSBuild & VSNet Tasks
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): System.ArgumentException
Re: [nant-dev] Updates to MSBuild & VSNet Tasks
Have you had a chance to review these changes? Please let me know so I know what I should do next with this batch of changes. Thanks, Ryan On Thu, Jun 23, 2011 at 10:36 PM, Ryan Boggs wrote: > Updated both the diff in NAnt's patches section and atlassian, just in > case there are issues: > > https://sourceforge.net/tracker/index.php?func=detail&aid=3311661&group_id=31650&atid=402870 > > https://fisheye1.atlassian.com/cru/CR-62 > > I switched the DetermineProductVersion method to use the > "ms:PropertyGroup/ms:TargetFrameworkVersion" xml path since it's > present across all msbuild files. I also added a check with the c++ > pdb file names. > > Thanks, > Ryan > > On Tue, Jun 21, 2011 at 5:36 PM, Ryan Boggs wrote: >> 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 >> >> On Thu, Jun 16, 2011 at 7:26 PM, Ryan Boggs wrote: >>> Hi, >>> >>> Updated the patch posted in NAnt's SF patches section. It's the top >>> one in red. Also, it looks like there was some feedback on there for >>> the updates regarding the C++ portion of it. >>> >>> Please see inline for other comments. >>> >>> On Thu, Jun 16, 2011 at 7:13 AM, Martin Aliger >>> wrote: >>>> I just checked and it correctly resolves all the MSBuild providers on my >>>> machine. >>>> Maybe it is becouse I have NAnt.MSBuild.dll in same directory as NAnt.exe? >>>> Maybe plugins do not resolve when in one of those Framework lib which is >>>> default for MSBuild assembly atm (no idea why). Or perhaps the order in >>>> which assemblies are loaded? >>> It's still not on my machine. I moved the assembly to the same dir as >>> the executable. Changed the target framework to net-2.0 and it still >>> does not pick up the plugins. I'm kinda wondering if it is my >>> machine. Am I the only one experiencing this? >>>> >>>> The registration is done in PluginScanner class from Core. All loaded types >>>> should be send into that (via TypeFactory). >>> Thanks, I take a look at this as well. >>>> >>>> Btw: I noticed, the solution providers from MSBuild assembly got VSNet >>>> namespace. Maybe it should be changed, for clarity. >>> I tried switching this too but it didn't make a difference. Unless >>> this is really making a difference, I don't see any reason to change >>> it right now. >>>> >>>> Martin Aliger >>>> >>>> >>>> >>>> -Original Message- >>>> From: Ryan Boggs [mailto:rmbo...@gmail.com] >>>> Sent: Thursday, June 16, 2011 3:37 PM >>>> To: Martin Aliger >>>> Cc: Dominik Guder; nant-developers@lists.sourceforge.net >>>> Subject: ***SPAM***BAR*** Re: [nant-dev] Updates to MSBuild & VSNet Tasks >>>> Importance: Low >>>> >>>> Hi, >>>> >>>> Please see inline. >>>> >>>> Thanks, >>>> Ryan >>>> >>>> On Jun 16, 2011, at 2:39 AM, "Martin Aliger" >>>> wrote: >>>> >>>>>>> Hi Ryan, sln file handling is some kind of broken since VS2005. They >>>>>>> only work with 2002/2003. I would not spend to much time for now in >>>>>>> sln file handling in VS2005 and up. >>>>>> Eww, makes sense. Well, not to let my work go to waste, I think I >>>>>> know why >>>>> it isn't working. The plugins that contains the schema information >>>>> for >>>>> VS2005+ solution files (NAnt.MSBuild.dll) doesn't seem to be getting >>>>> VS2005+ picked >>>>> up during NAnt's plugin >discovery phase. >>>>>> However, I have been having difficulty trying to locate where the >>>>>> plugin >>>>> discovery phase occurs in NAnt to make sure that they are getting picked >>>> up. >>>>> There is also the fact that the VS2005+ solutio
Re: [nant-dev] Updates to MSBuild & VSNet Tasks
Updated both the diff in NAnt's patches section and atlassian, just in case there are issues: https://sourceforge.net/tracker/index.php?func=detail&aid=3311661&group_id=31650&atid=402870 https://fisheye1.atlassian.com/cru/CR-62 I switched the DetermineProductVersion method to use the "ms:PropertyGroup/ms:TargetFrameworkVersion" xml path since it's present across all msbuild files. I also added a check with the c++ pdb file names. Thanks, Ryan On Tue, Jun 21, 2011 at 5:36 PM, Ryan Boggs wrote: > 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 > > On Thu, Jun 16, 2011 at 7:26 PM, Ryan Boggs wrote: >> Hi, >> >> Updated the patch posted in NAnt's SF patches section. It's the top >> one in red. Also, it looks like there was some feedback on there for >> the updates regarding the C++ portion of it. >> >> Please see inline for other comments. >> >> On Thu, Jun 16, 2011 at 7:13 AM, Martin Aliger >> wrote: >>> I just checked and it correctly resolves all the MSBuild providers on my >>> machine. >>> Maybe it is becouse I have NAnt.MSBuild.dll in same directory as NAnt.exe? >>> Maybe plugins do not resolve when in one of those Framework lib which is >>> default for MSBuild assembly atm (no idea why). Or perhaps the order in >>> which assemblies are loaded? >> It's still not on my machine. I moved the assembly to the same dir as >> the executable. Changed the target framework to net-2.0 and it still >> does not pick up the plugins. I'm kinda wondering if it is my >> machine. Am I the only one experiencing this? >>> >>> The registration is done in PluginScanner class from Core. All loaded types >>> should be send into that (via TypeFactory). >> Thanks, I take a look at this as well. >>> >>> Btw: I noticed, the solution providers from MSBuild assembly got VSNet >>> namespace. Maybe it should be changed, for clarity. >> I tried switching this too but it didn't make a difference. Unless >> this is really making a difference, I don't see any reason to change >> it right now. >>> >>> Martin Aliger >>> >>> >>> >>> -Original Message- >>> From: Ryan Boggs [mailto:rmbo...@gmail.com] >>> Sent: Thursday, June 16, 2011 3:37 PM >>> To: Martin Aliger >>> Cc: Dominik Guder; nant-developers@lists.sourceforge.net >>> Subject: ***SPAM***BAR*** Re: [nant-dev] Updates to MSBuild & VSNet Tasks >>> Importance: Low >>> >>> Hi, >>> >>> Please see inline. >>> >>> Thanks, >>> Ryan >>> >>> On Jun 16, 2011, at 2:39 AM, "Martin Aliger" >>> wrote: >>> >>>>>> Hi Ryan, sln file handling is some kind of broken since VS2005. They >>>>>> only work with 2002/2003. I would not spend to much time for now in >>>>>> sln file handling in VS2005 and up. >>>>> Eww, makes sense. Well, not to let my work go to waste, I think I >>>>> know why >>>> it isn't working. The plugins that contains the schema information >>>> for >>>> VS2005+ solution files (NAnt.MSBuild.dll) doesn't seem to be getting >>>> VS2005+ picked >>>> up during NAnt's plugin >discovery phase. >>>>> However, I have been having difficulty trying to locate where the >>>>> plugin >>>> discovery phase occurs in NAnt to make sure that they are getting picked >>> up. >>>> There is also the fact that the VS2005+ solution plugin classes are >>>> marked as internal but I am not sure >how much of an impact that is making >>> overall. >>>> >>>> Discovery mechanism was made by me and Gert some time ago. I could >>>> look into it... >>> Thanks Martin. I thought your names looked familiar. :) >>>> >>>> SolutionFactory.cs is main branching thingy. Providers itself are >>>> registred though Core's IPluginConsumer and ISolutionBuildProvider >>> interfaces. >>> I see that and it seems to be working ok with the classes within the >>> NAnt.VSNet assembly. It just won't pickup the classes from the NAnt.MSBuild >>> assembly. If u can point me to where in the code that the solution task >>> begins to search for plugins in external assemblies, I can research further >>> as well. >>>> >>>> M. >>>> >>> >>> >> > -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
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 On Thu, Jun 16, 2011 at 7:26 PM, Ryan Boggs wrote: > Hi, > > Updated the patch posted in NAnt's SF patches section. It's the top > one in red. Also, it looks like there was some feedback on there for > the updates regarding the C++ portion of it. > > Please see inline for other comments. > > On Thu, Jun 16, 2011 at 7:13 AM, Martin Aliger > wrote: >> I just checked and it correctly resolves all the MSBuild providers on my >> machine. >> Maybe it is becouse I have NAnt.MSBuild.dll in same directory as NAnt.exe? >> Maybe plugins do not resolve when in one of those Framework lib which is >> default for MSBuild assembly atm (no idea why). Or perhaps the order in >> which assemblies are loaded? > It's still not on my machine. I moved the assembly to the same dir as > the executable. Changed the target framework to net-2.0 and it still > does not pick up the plugins. I'm kinda wondering if it is my > machine. Am I the only one experiencing this? >> >> The registration is done in PluginScanner class from Core. All loaded types >> should be send into that (via TypeFactory). > Thanks, I take a look at this as well. >> >> Btw: I noticed, the solution providers from MSBuild assembly got VSNet >> namespace. Maybe it should be changed, for clarity. > I tried switching this too but it didn't make a difference. Unless > this is really making a difference, I don't see any reason to change > it right now. >> >> Martin Aliger >> >> >> >> -Original Message----- >> From: Ryan Boggs [mailto:rmbo...@gmail.com] >> Sent: Thursday, June 16, 2011 3:37 PM >> To: Martin Aliger >> Cc: Dominik Guder; nant-developers@lists.sourceforge.net >> Subject: ***SPAM***BAR*** Re: [nant-dev] Updates to MSBuild & VSNet Tasks >> Importance: Low >> >> Hi, >> >> Please see inline. >> >> Thanks, >> Ryan >> >> On Jun 16, 2011, at 2:39 AM, "Martin Aliger" >> wrote: >> >>>>> Hi Ryan, sln file handling is some kind of broken since VS2005. They >>>>> only work with 2002/2003. I would not spend to much time for now in >>>>> sln file handling in VS2005 and up. >>>> Eww, makes sense. Well, not to let my work go to waste, I think I >>>> know why >>> it isn't working. The plugins that contains the schema information >>> for >>> VS2005+ solution files (NAnt.MSBuild.dll) doesn't seem to be getting >>> VS2005+ picked >>> up during NAnt's plugin >discovery phase. >>>> However, I have been having difficulty trying to locate where the >>>> plugin >>> discovery phase occurs in NAnt to make sure that they are getting picked >> up. >>> There is also the fact that the VS2005+ solution plugin classes are >>> marked as internal but I am not sure >how much of an impact that is making >> overall. >>> >>> Discovery mechanism was made by me and Gert some time ago. I could >>> look into it... >> Thanks Martin. I thought your names looked familiar. :) >>> >>> SolutionFactory.cs is main branching thingy. Providers itself are >>> registred though Core's IPluginConsumer and ISolutionBuildProvider >> interfaces. >> I see that and it seems to be working ok with the classes within the >> NAnt.VSNet assembly. It just won't pickup the classes from the NAnt.MSBuild >> assembly. If u can point me to where in the code that the solution task >> begins to search for plugins in external assemblies, I can research further >> as well. >>> >>> M. >>> >> >> > -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Updates to MSBuild & VSNet Tasks
Hi, Updated the patch posted in NAnt's SF patches section. It's the top one in red. Also, it looks like there was some feedback on there for the updates regarding the C++ portion of it. Please see inline for other comments. On Thu, Jun 16, 2011 at 7:13 AM, Martin Aliger wrote: > I just checked and it correctly resolves all the MSBuild providers on my > machine. > Maybe it is becouse I have NAnt.MSBuild.dll in same directory as NAnt.exe? > Maybe plugins do not resolve when in one of those Framework lib which is > default for MSBuild assembly atm (no idea why). Or perhaps the order in > which assemblies are loaded? It's still not on my machine. I moved the assembly to the same dir as the executable. Changed the target framework to net-2.0 and it still does not pick up the plugins. I'm kinda wondering if it is my machine. Am I the only one experiencing this? > > The registration is done in PluginScanner class from Core. All loaded types > should be send into that (via TypeFactory). Thanks, I take a look at this as well. > > Btw: I noticed, the solution providers from MSBuild assembly got VSNet > namespace. Maybe it should be changed, for clarity. I tried switching this too but it didn't make a difference. Unless this is really making a difference, I don't see any reason to change it right now. > > Martin Aliger > > > > -Original Message- > From: Ryan Boggs [mailto:rmbo...@gmail.com] > Sent: Thursday, June 16, 2011 3:37 PM > To: Martin Aliger > Cc: Dominik Guder; nant-developers@lists.sourceforge.net > Subject: ***SPAM***BAR*** Re: [nant-dev] Updates to MSBuild & VSNet Tasks > Importance: Low > > Hi, > > Please see inline. > > Thanks, > Ryan > > On Jun 16, 2011, at 2:39 AM, "Martin Aliger" > wrote: > >>>> Hi Ryan, sln file handling is some kind of broken since VS2005. They >>>> only work with 2002/2003. I would not spend to much time for now in >>>> sln file handling in VS2005 and up. >>> Eww, makes sense. Well, not to let my work go to waste, I think I >>> know why >> it isn't working. The plugins that contains the schema information >> for >> VS2005+ solution files (NAnt.MSBuild.dll) doesn't seem to be getting >> VS2005+ picked >> up during NAnt's plugin >discovery phase. >>> However, I have been having difficulty trying to locate where the >>> plugin >> discovery phase occurs in NAnt to make sure that they are getting picked > up. >> There is also the fact that the VS2005+ solution plugin classes are >> marked as internal but I am not sure >how much of an impact that is making > overall. >> >> Discovery mechanism was made by me and Gert some time ago. I could >> look into it... > Thanks Martin. I thought your names looked familiar. :) >> >> SolutionFactory.cs is main branching thingy. Providers itself are >> registred though Core's IPluginConsumer and ISolutionBuildProvider > interfaces. > I see that and it seems to be working ok with the classes within the > NAnt.VSNet assembly. It just won't pickup the classes from the NAnt.MSBuild > assembly. If u can point me to where in the code that the solution task > begins to search for plugins in external assemblies, I can research further > as well. >> >> M. >> > > -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Updates to MSBuild & VSNet Tasks
I just checked and it correctly resolves all the MSBuild providers on my machine. Maybe it is becouse I have NAnt.MSBuild.dll in same directory as NAnt.exe? Maybe plugins do not resolve when in one of those Framework lib which is default for MSBuild assembly atm (no idea why). Or perhaps the order in which assemblies are loaded? The registration is done in PluginScanner class from Core. All loaded types should be send into that (via TypeFactory). Btw: I noticed, the solution providers from MSBuild assembly got VSNet namespace. Maybe it should be changed, for clarity. Martin Aliger -Original Message- From: Ryan Boggs [mailto:rmbo...@gmail.com] Sent: Thursday, June 16, 2011 3:37 PM To: Martin Aliger Cc: Dominik Guder; nant-developers@lists.sourceforge.net Subject: ***SPAM***BAR*** Re: [nant-dev] Updates to MSBuild & VSNet Tasks Importance: Low Hi, Please see inline. Thanks, Ryan On Jun 16, 2011, at 2:39 AM, "Martin Aliger" wrote: >>> Hi Ryan, sln file handling is some kind of broken since VS2005. They >>> only work with 2002/2003. I would not spend to much time for now in >>> sln file handling in VS2005 and up. >> Eww, makes sense. Well, not to let my work go to waste, I think I >> know why > it isn't working. The plugins that contains the schema information > for > VS2005+ solution files (NAnt.MSBuild.dll) doesn't seem to be getting > VS2005+ picked > up during NAnt's plugin >discovery phase. >> However, I have been having difficulty trying to locate where the >> plugin > discovery phase occurs in NAnt to make sure that they are getting picked up. > There is also the fact that the VS2005+ solution plugin classes are > marked as internal but I am not sure >how much of an impact that is making overall. > > Discovery mechanism was made by me and Gert some time ago. I could > look into it... Thanks Martin. I thought your names looked familiar. :) > > SolutionFactory.cs is main branching thingy. Providers itself are > registred though Core's IPluginConsumer and ISolutionBuildProvider interfaces. I see that and it seems to be working ok with the classes within the NAnt.VSNet assembly. It just won't pickup the classes from the NAnt.MSBuild assembly. If u can point me to where in the code that the solution task begins to search for plugins in external assemblies, I can research further as well. > > M. > -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Updates to MSBuild & VSNet Tasks
Hi, Please see inline. Thanks, Ryan On Jun 16, 2011, at 2:39 AM, "Martin Aliger" wrote: >>> Hi Ryan, sln file handling is some kind of broken since VS2005. They >>> only work with 2002/2003. I would not spend to much time for now in >>> sln file handling in VS2005 and up. >> Eww, makes sense. Well, not to let my work go to waste, I think I know why > it isn't working. The plugins that contains the schema information for > VS2005+ solution files (NAnt.MSBuild.dll) doesn't seem to be getting picked > up during NAnt's plugin >discovery phase. >> However, I have been having difficulty trying to locate where the plugin > discovery phase occurs in NAnt to make sure that they are getting picked up. > There is also the fact that the VS2005+ solution plugin classes are marked > as internal but I am not sure >how much of an impact that is making overall. > > Discovery mechanism was made by me and Gert some time ago. I could look into > it... Thanks Martin. I thought your names looked familiar. :) > > SolutionFactory.cs is main branching thingy. Providers itself are registred > though Core's IPluginConsumer and ISolutionBuildProvider interfaces. I see that and it seems to be working ok with the classes within the NAnt.VSNet assembly. It just won't pickup the classes from the NAnt.MSBuild assembly. If u can point me to where in the code that the solution task begins to search for plugins in external assemblies, I can research further as well. > > M. > -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Updates to MSBuild & VSNet Tasks
Hi, Thanks for your reply. Inline comments below. On Wed, Jun 15, 2011 at 2:05 AM, Dominik Guder wrote: > Am 14.06.2011 05:14, schrieb Ryan Boggs: >> Hi, >> >> Just an update. I'm having issues with trying to process solution >> files from .NET 2.0 and above with the solution task. I'm still >> taking a look at it but it seems that the VS20** plugins in the >> NAnt.MSBuild assembly are not being picked up by the solution task. >> I'll keep checking... >> > > Hi Ryan, sln file handling is some kind of broken since VS2005. They > only work with 2002/2003. I would not spend to much time for now in sln > file handling in VS2005 and up. Eww, makes sense. Well, not to let my work go to waste, I think I know why it isn't working. The plugins that contains the schema information for VS2005+ solution files (NAnt.MSBuild.dll) doesn't seem to be getting picked up during NAnt's plugin discovery phase. However, I have been having difficulty trying to locate where the plugin discovery phase occurs in NAnt to make sure that they are getting picked up. There is also the fact that the VS2005+ solution plugin classes are marked as internal but I am not sure how much of an impact that is making overall. > > The common approach I see is to use solution task with included > projects, or use msbuild task from nantcontrib (eg. for WiX projects). I see. I went straight for the solution files first. That may have been my problem. > > Basically I think we should provide a basic way to build projects up to > net-4.0 and add extended features like target version compiling and sln > file handling when 1.x runtime support was dropped. Ok, I'm assuming that the statement above fills in the basics, is that correct? > > I got my sample compiled against the correct framework recently. I think > this makes a step further to release 0.91 Are you saying that you are ok with Martin's patch now? Or did you have to make some mods? Thanks, Ryan > > So far > Dominik > > > > -- > The answer to the great question of life, > the universe and everything is 42 (Douglas Adams) > > -- > EditLive Enterprise is the world's most technically advanced content > authoring tool. Experience the power of Track Changes, Inline Image > Editing and ensure content is compliant with Accessibility Checking. > http://p.sf.net/sfu/ephox-dev2dev > ___ > nant-developers mailing list > nant-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/nant-developers > -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Updates to MSBuild & VSNet Tasks
Am 14.06.2011 05:14, schrieb Ryan Boggs: > Hi, > > Just an update. I'm having issues with trying to process solution > files from .NET 2.0 and above with the solution task. I'm still > taking a look at it but it seems that the VS20** plugins in the > NAnt.MSBuild assembly are not being picked up by the solution task. > I'll keep checking... > Hi Ryan, sln file handling is some kind of broken since VS2005. They only work with 2002/2003. I would not spend to much time for now in sln file handling in VS2005 and up. The common approach I see is to use solution task with included projects, or use msbuild task from nantcontrib (eg. for WiX projects). Basically I think we should provide a basic way to build projects up to net-4.0 and add extended features like target version compiling and sln file handling when 1.x runtime support was dropped. I got my sample compiled against the correct framework recently. I think this makes a step further to release 0.91 So far Dominik -- The answer to the great question of life, the universe and everything is 42 (Douglas Adams) -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Updates to MSBuild & VSNet Tasks
Hi, Just an update. I'm having issues with trying to process solution files from .NET 2.0 and above with the solution task. I'm still taking a look at it but it seems that the VS20** plugins in the NAnt.MSBuild assembly are not being picked up by the solution task. I'll keep checking... Thanks, Ryan On Tue, Jun 7, 2011 at 5:21 AM, Martin Aliger wrote: > Hi, > > >>In addition I had issues to get solution task with included projects and > without soultionfile property set running. Maybe I did something wrong. >>(I used only vb projects) > That should definitelly work. In fact, I would be less suprised if some > problems arise in sln handling, since we are using/testing bunch of csproj's > without solution itself. > Maybe that vbprojs need some tweaks. > >>On question: Should it be possible to compile for another targetframework? > I think this should be handled. > It should be possible, but I found some problems with it. And since I do not > use it myself, I didnt test extensivelly. As Ryan wrote, BuildEngine > wrappers was introduced becouse of it as well as some dynamic loads, dynamic > listener etc. > Some testcases for crosscompiling would be great. I think, that hosting > Framework should be higher that the target, but perhaps opposite could work > as well. Msbuild4 would need clr4 though. > But generally, crosscompiling should be possible. > > Martin > > > > -- > EditLive Enterprise is the world's most technically advanced content > authoring tool. Experience the power of Track Changes, Inline Image > Editing and ensure content is compliant with Accessibility Checking. > http://p.sf.net/sfu/ephox-dev2dev > ___ > nant-developers mailing list > nant-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/nant-developers > -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Updates to MSBuild & VSNet Tasks
Hi, >In addition I had issues to get solution task with included projects and without soultionfile property set running. Maybe I did something wrong. >(I used only vb projects) That should definitelly work. In fact, I would be less suprised if some problems arise in sln handling, since we are using/testing bunch of csproj's without solution itself. Maybe that vbprojs need some tweaks. >On question: Should it be possible to compile for another targetframework? I think this should be handled. It should be possible, but I found some problems with it. And since I do not use it myself, I didnt test extensivelly. As Ryan wrote, BuildEngine wrappers was introduced becouse of it as well as some dynamic loads, dynamic listener etc. Some testcases for crosscompiling would be great. I think, that hosting Framework should be higher that the target, but perhaps opposite could work as well. Msbuild4 would need clr4 though. But generally, crosscompiling should be possible. Martin -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Updates to MSBuild & VSNet Tasks
Hmm, On Mon, Jun 6, 2011 at 10:28 PM, Dominik Guder wrote: > Am 07.06.2011 01:53, schrieb Ryan Boggs: >> Hi, >> >> Martin seems good with the diff I posted. Has anyone else reviewed it >> since I posted it last saturday? The link to the patch is below. >> > > Yes, I did. > > One point it is not working with vb solutions, since > PropertyGroup/ProductVersion exists but is empty in vb projects. > But this could be fixed easyly. Is this MSBuild or VSNet tasks? > > In addition I had issues to get solution task with included projects and > without soultionfile property set running. Maybe I did something wrong. > (I used only vb projects) I'll check into this. However, I only test with C# really. > > On question: Should it be possible to compile for another > targetframework? I think this should be handled. Yes it should. I believe that is the reason why that new NAnt.MSBuild.BuildEngine tasks were included. To handle the cross compile. Thanks, Ryan > > So far Dominik > > -- > The answer to the great question of life, > the universe and everything is 42 (Douglas Adams) > > -- > EditLive Enterprise is the world's most technically advanced content > authoring tool. Experience the power of Track Changes, Inline Image > Editing and ensure content is compliant with Accessibility Checking. > http://p.sf.net/sfu/ephox-dev2dev > ___ > nant-developers mailing list > nant-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/nant-developers > -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Updates to MSBuild & VSNet Tasks
Am 07.06.2011 01:53, schrieb Ryan Boggs: > Hi, > > Martin seems good with the diff I posted. Has anyone else reviewed it > since I posted it last saturday? The link to the patch is below. > Yes, I did. One point it is not working with vb solutions, since PropertyGroup/ProductVersion exists but is empty in vb projects. But this could be fixed easyly. In addition I had issues to get solution task with included projects and without soultionfile property set running. Maybe I did something wrong. (I used only vb projects) On question: Should it be possible to compile for another targetframework? I think this should be handled. So far Dominik -- The answer to the great question of life, the universe and everything is 42 (Douglas Adams) -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Updates to MSBuild & VSNet Tasks
Hi, Martin seems good with the diff I posted. Has anyone else reviewed it since I posted it last saturday? The link to the patch is below. https://sourceforge.net/tracker/?func=detail&aid=3311661&group_id=31650&atid=402870 Thanks, Ryan On Sat, Jun 4, 2011 at 4:23 PM, Ryan Boggs wrote: > Hi, > > I decided to make a new thread specifically for this update for better > organization. > > The diffs in question have been posted as a single diff in the patches > tracker in SF. Direct link is below: > https://sourceforge.net/tracker/?func=detail&aid=3311661&group_id=31650&atid=402870 > > I just finished making some slight mods to the original diffs. I > restructured it a bit too. The files that were originally in the > NAnt/MSBuild/MSBuild directory have been moved to > NAnt/MSBuild/BuildEngine and the namespace in those files have been > changed to NAnt.MSBuild.BuildEngine. Thought this made sense because > the claases that these files wrap are in a similar namespace. Just > tested on .NET 2.0 and everything built and tested out ok when patched > against cvs. > > One thing I wanted to point out. In the original diff(s) that I > received from Martin, there was one for Element that made the Location > property's accessor asymmetric (public get; protected set;). While I > like this, it is not currently possible since NAnt still supports .net > 1.0 runtime. Since the diff relied on that changed and I didn't know > why the Location property is not public, I went ahead and created a > new method in Element called "GetLocation()" that just returns the > location. If there is no good reason why the location is not public, > I would rather go that route. If there is a valid reason, this is the > only thing I can think of until .net 1.0 runtime support is dropped > from NAnt. > > Thanks, > Ryan > -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
