[nant-dev] C++ projects in solution
Hello nant-developers, Is anyone currently working on adding support for C++ projects to the solution task? I'd like to start working on that now, if noone else is already doing that. -- Best regards, Dmitry mailto:[EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] C++ projects in solution
I don't believe anyone is currently working on it. It would be good if the implementation deferred to the existing tasks in NAnt.VisualCpp for the actual compilation stage. I've just moved Midltask and rcTask across from NAntContrib which should help. I'm going to add fileset support for them next. Ian Hello nant-developers, Is anyone currently working on adding support for C++ projects to the solution task? I'd like to start working on that now, if noone else is already doing that. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] [patch] NAntAddin update
Dmitry Jemerov wrote: Hello nant-developers, The attached patch updates NAntAddin to build and work with the latest NAnt. Not quite the latest NAnt. I hit a couple of compile errors where method signatures have changed. I also had to make several changes to the .build file where it was breaking due to some changes in NAnt. Thanks for the patch though. I'll commit it and my changes later today. Ian I have found the add-in to be good enough for running NAnt builds from Visual Studio, but hardly usable for editing or creating new .build files, or even for getting an overview of how a build file works. The add-in uses the standard Properties window for editing target and task properties, which gives very little space for actual property values. It works especially bad for fileset elements - probably the most essential part of a .build file. Just seeing what is in a fileset requires expanding three levels in a tree, and adding a new entry to a fileset requires about five clicks to different parts of the screen. Besides that, the current add-in architecture requires manually writing a wrapper class for every NAnt task class. The wrapper has the same properties as the NAnt task, and delegates property gets and sets to the XML node representing the task. Maintaining these wrappers as NAnt and NAntContrib evolve is quite a major hassle - in fact, I haven't updated them to match the changes in NAnt core tasks since NAntAddin was initially developed. Fixing those shortcomings will require a lot of work. Since I myself don't need the add-in that much, I'll leave it at its current state and focus on a different task... --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] license task broken
Hi, I'm using the following statement in my buildscript: license input=license.licx licensetarget=start.exe / This is similar to the help file. But: I _always_ gt an exception about an invalid path. Before I had an fileset included with the assemblies to be licensed, but this is just the same error. I think this is a newly introduced bug, since this happens after updating to the latest nightly build. -sa -- sa at programmers-world dot com http://www.livingit.de Bookmarks online: http://www.mobile-bookmarks.info Soon available in english They make a desert and call it peace. -- Tacitus (55?-120?) --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] [patch] NAntAddin update
apologies. I didn't see you other patch to project.cs. I've committed it as well. Thanks Ian Not quite the latest NAnt. I hit a couple of compile errors where method signatures have changed. I also had to make several changes to the .build file where it was breaking due to some changes in NAnt. Thanks for the patch though. I'll commit it and my changes later today. Ian I have found the add-in to be good enough for running NAnt builds from Visual Studio, but hardly usable for editing or creating new .build files, or even for getting an overview of how a build file works. The add-in uses the standard Properties window for editing target and task properties, which gives very little space for actual property values. It works especially bad for fileset elements - probably the most essential part of a .build file. Just seeing what is in a fileset requires expanding three levels in a tree, and adding a new entry to a fileset requires about five clicks to different parts of the screen. Besides that, the current add-in architecture requires manually writing a wrapper class for every NAnt task class. The wrapper has the same properties as the NAnt task, and delegates property gets and sets to the XML node representing the task. Maintaining these wrappers as NAnt and NAntContrib evolve is quite a major hassle - in fact, I haven't updated them to match the changes in NAnt core tasks since NAntAddin was initially developed. Fixing those shortcomings will require a lot of work. Since I myself don't need the add-in that much, I'll leave it at its current state and focus on a different task... --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] [patch] NAntAddin update
Dmitry Jemerov wrote: I have found the add-in to be good enough for running NAnt builds from Visual Studio, but hardly usable for editing or creating new .build files, or even for getting an overview of how a build file works. The add-in uses the standard Properties window for editing target and task properties, which gives very little space for actual property values. It works especially bad for fileset elements - probably the most essential part of a .build file. Just seeing what is in a fileset requires expanding three levels in a tree, and adding a new entry to a fileset requires about five clicks to different parts of the screen. This could probably be worked around by using custom property pages for all child elements of tasks. The current implementation is kinda clumsy.. Besides that, the current add-in architecture requires manually writing a wrapper class for every NAnt task class. The wrapper has the same properties as the NAnt task, and delegates property gets and sets to the XML node representing the task. Maintaining these wrappers as NAnt and NAntContrib evolve is quite a major hassle - in fact, I haven't updated them to match the changes in NAnt core tasks since NAntAddin was initially developed. I agree - the wrappers are a big overhead. There was some discussion a while ago as to whether or not the task metadata contains sufficent information for the addin to get what it needs via reflection. I think the consensus was that currently it doesn't. Scott probably remembers the specific better than me. Ian --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] C++ projects in solution
Please consider refactoring the existing project class into separate classes ie: BaseProject, CSharpProject, VBNetProject and CPlusPlusProject this will help keep the subtle details of each project file separate. This was on my list of contributions but I haven't had time to start on it yet. thanks b - Original Message - From: Dmitry Jemerov [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, September 14, 2003 12:07 AM Subject: [nant-dev] C++ projects in solution Hello nant-developers, Is anyone currently working on adding support for C++ projects to the solution task? I'd like to start working on that now, if noone else is already doing that. -- Best regards, Dmitry mailto:[EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.515 / Virus Database: 313 - Release Date: 9/2/2003 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] C++ projects in solution
Don't forget J# project :) Ian Please consider refactoring the existing project class into separate classes ie: BaseProject, CSharpProject, VBNetProject and CPlusPlusProject this will help keep the subtle details of each project file separate. This was on my list of contributions but I haven't had time to start on it yet. thanks b - Original Message - From: Dmitry Jemerov [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, September 14, 2003 12:07 AM Subject: [nant-dev] C++ projects in solution Hello nant-developers, Is anyone currently working on adding support for C++ projects to the solution task? I'd like to start working on that now, if noone else is already doing that. -- Best regards, Dmitry mailto:[EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.515 / Virus Database: 313 - Release Date: 9/2/2003 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] license task broken
Hi,
It seems I found two bugs. One is in the licese task itself.
It can happen (actually it does on one of my systems),
thatasmLoaded.Location is either an empty string or null. If
so, Path.GetFullPath(...) throws an exception. The attached
diff files addesses this issue.
The second thing seems to be in Directory scanner (I'm not
sure, cause I have not much time to dive into this yet). If
I give something like D:\licensed_components\*.dll as
includes in the nested assembly, he tries to load dlls
without the ending. Eg A file name assembly.dll gets only
assembly .
HTH,
-sa
--
sa at programmers-world dot com
http://www.livingit.de
Bookmarks online: http://www.mobile-bookmarks.info
Soon available in english
Es brilig war. Die schlichte Toven
Wirrten und wimmelten in Waben;
Und aller-mumsige Burggoven
Dir mohmen Rath ausgraben.
-- Lewis Carrol, Through the Looking Glass
151c151,153
alAssemblyFilesLoaded.Add(Path.GetFullPath(asmLoaded.Location).ToLower(CultureInfo.InvariantCulture));
---
if (asmLoaded.Location.TrimEnd().TrimStart()
!= asmLoaded.Location != null) {
alAssemblyFilesLoaded.Add(Path.GetFullPath(asmLoaded.Location).ToLower(CultureInfo.InvariantCulture));
}
Re: [nant-dev] license task broken
Yet another bug is that the License task loads assemblies (as far as I can remember) into the main AppDomain. It needs to have code to load these assemblies in a separate AppDomain, like the NUnit tasks have. Matt. On Sun, 2003-09-14 at 11:46, Sascha Andres wrote: Hi, It seems I found two bugs. One is in the licese task itself. It can happen (actually it does on one of my systems), thatasmLoaded.Location is either an empty string or null. If so, Path.GetFullPath(...) throws an exception. The attached diff files addesses this issue. The second thing seems to be in Directory scanner (I'm not sure, cause I have not much time to dive into this yet). If I give something like D:\licensed_components\*.dll as includes in the nested assembly, he tries to load dlls without the ending. Eg A file name assembly.dll gets only assembly . HTH, -sa -- Matthew Mastracci [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] license task broken
Hi, * Matthew Mastracci wrote on 14.09.2003 (12:45): Yet another bug is that the License task loads assemblies (as far as I can remember) into the main AppDomain. It needs to have code to load these assemblies in a separate AppDomain, like the NUnit tasks have. You're right. It does that way. But this is a minor problem as long as other bugs prevent using the license task at all. And this could be considered as 'by design'. Something to the found problems: Even a full path (no placeholders) don't make the license task running. -sa -- sa at programmers-world dot com http://www.livingit.de Bookmarks online: http://www.mobile-bookmarks.info Soon available in english Electrocution, n.: Burning at the stake with all the modern improvements. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
