Re: [nant-dev] AsmInfo patch
Hi Kevin, I just added support for this to the asminfo task in cvs yesterday :( I actually compared each line of both files and skipped all comments ... I did this as files generated with .NET 1.0 or .NET 1.1 only differ in the comment block that is insert into the generated file : //-- // autogenerated // This code was generated by a tool. // Runtime Version: 1.1.4322.940 // // Changes to this file may cause incorrect behavior and will be lost if // the code is regenerated. // /autogenerated //-- However, I do like your approach a lot better. So, I'm not sure if I should keep the current (quick and dirty) implementation or use yours ... What do you think ? Gert - Original Message - From: Kevin Miller [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, February 27, 2004 9:24 PM Subject: [nant-dev] AsmInfo patch I found the asminfo task today and fell in love. It solved a few problems I was having with signing assemblies and paths to the key file. I was frustrated by the fact that it always generates the AssemblyInfo.cs file even if there are no changes. This causes the csc/vbc task to build the project even if only the AssemblyInfo class has been updated. This is clearly an annoyance during development builds. Attached is an updated that compares the present AssemblyInfo.x to the one being generated. If they are different it writes the new code one out to disk. This file is updating the .84 release. Sorry I did not compare to the latest cvs. Also, I did not add a switch to make this behavior optional. This post is just to feel out well this enhancement would be received. I am willing to create a decent patch. Let me know if there is interest in this feature. Kevin Miller --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] AsmInfo patch
The problem is that the C# code provider automatically inserts the comment block I mentioned into the generated file. Meaning the asm task will generate different files when run on .NET 1.0 and .NET 1.1, as the runtime version that's output in that comment block will be different. If there's any way of preventing that comment block from being generated, please let me know ... We can still use your hash implementation, but in that case the asm will regenerate the AssemblyInfo file when switching runtimes (as the hash will be different because of the fact that the comment block that's automatically generated by the code provider will be different) ... Gert - Original Message - From: Kevin Miller [EMAIL PROTECTED] To: Gert Driesen [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, February 28, 2004 3:58 PM Subject: RE: [nant-dev] AsmInfo patch Funny, oh well it was fun getting my hands dirty with NAnt stuff again. I say use my implementation :) Hmm, Not sure what which would be better. I don't understand the importance of the 1.0 vs 1.1 comment differences when the file generated will not have any comments. Unless I missed out on a feature of asminfo that allows those comments to be retained. I say if the comment feature is not explicitly necessary and the performance of hashing is better than line by line compare which is anyones guess (my gut tells my the line by line may be better) that we use the hash based method. Honestly I do not care too much either way as long as the feature makes it into NAnt :) Kevin -Original Message- From: Gert Driesen [mailto:[EMAIL PROTECTED] Sent: Sat 2/28/2004 2:01 AM To: Kevin Miller; [EMAIL PROTECTED] Subject: Re: [nant-dev] AsmInfo patch Hi Kevin, I just added support for this to the asminfo task in cvs yesterday :( I actually compared each line of both files and skipped all comments ... I did this as files generated with .NET 1.0 or .NET 1.1 only differ in the comment block that is insert into the generated file : //-- // autogenerated // This code was generated by a tool. // Runtime Version: 1.1.4322.940 // // Changes to this file may cause incorrect behavior and will be lost if // the code is regenerated. // /autogenerated //-- However, I do like your approach a lot better. So, I'm not sure if I should keep the current (quick and dirty) implementation or use yours ... What do you think ? Gert - Original Message - From: Kevin Miller [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, February 27, 2004 9:24 PM Subject: [nant-dev] AsmInfo patch I found the asminfo task today and fell in love. It solved a few problems I was having with signing assemblies and paths to the key file. I was frustrated by the fact that it always generates the AssemblyInfo.cs file even if there are no changes. This causes the csc/vbc task to build the project even if only the AssemblyInfo class has been updated. This is clearly an annoyance during development builds. Attached is an updated that compares the present AssemblyInfo.x to the one being generated. If they are different it writes the new code one out to disk. This file is updating the .84 release. Sorry I did not compare to the latest cvs. Also, I did not add a switch to make this behavior optional. This post is just to feel out well this enhancement would be received. I am willing to create a decent patch. Let me know if there is interest in this feature. Kevin Miller --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] AsmInfo patch
Your implementation is indeed slower, but I've committed it to CVS anyway ... Thanks for the contribution ! Gert - Original Message - From: Kevin Miller [EMAIL PROTECTED] To: Gert Driesen [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, February 28, 2004 4:28 PM Subject: RE: [nant-dev] AsmInfo patch Ah interesting. I am sure your CodeDOM-fu is better than mine. I am not sure how negative the extra generation of the assemblyinfo file when switching runtimes is. I am guessing if you are building multiple runtime versions of your application you still need to compile all the assemblies in the build for each runtime. Thus the only negative I see in that scenario is the extra time it takes to write the MemoryStream out to disk. -Original Message- From: Gert Driesen [mailto:[EMAIL PROTECTED] Sent: Sat 2/28/2004 9:23 AM To: Kevin Miller; [EMAIL PROTECTED] Subject: Re: [nant-dev] AsmInfo patch The problem is that the C# code provider automatically inserts the comment block I mentioned into the generated file. Meaning the asm task will generate different files when run on .NET 1.0 and .NET 1.1, as the runtime version that's output in that comment block will be different. If there's any way of preventing that comment block from being generated, please let me know ... We can still use your hash implementation, but in that case the asm will regenerate the AssemblyInfo file when switching runtimes (as the hash will be different because of the fact that the comment block that's automatically generated by the code provider will be different) ... Gert - Original Message - From: Kevin Miller [EMAIL PROTECTED] To: Gert Driesen [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, February 28, 2004 3:58 PM Subject: RE: [nant-dev] AsmInfo patch Funny, oh well it was fun getting my hands dirty with NAnt stuff again. I say use my implementation :) Hmm, Not sure what which would be better. I don't understand the importance of the 1.0 vs 1.1 comment differences when the file generated will not have any comments. Unless I missed out on a feature of asminfo that allows those comments to be retained. I say if the comment feature is not explicitly necessary and the performance of hashing is better than line by line compare which is anyones guess (my gut tells my the line by line may be better) that we use the hash based method. Honestly I do not care too much either way as long as the feature makes it into NAnt :) Kevin -Original Message- From: Gert Driesen [mailto:[EMAIL PROTECTED] Sent: Sat 2/28/2004 2:01 AM To: Kevin Miller; [EMAIL PROTECTED] Subject: Re: [nant-dev] AsmInfo patch Hi Kevin, I just added support for this to the asminfo task in cvs yesterday :( I actually compared each line of both files and skipped all comments ... I did this as files generated with .NET 1.0 or .NET 1.1 only differ in the comment block that is insert into the generated file : //-- // autogenerated // This code was generated by a tool. // Runtime Version: 1.1.4322.940 // // Changes to this file may cause incorrect behavior and will be lost if // the code is regenerated. // /autogenerated //-- However, I do like your approach a lot better. So, I'm not sure if I should keep the current (quick and dirty) implementation or use yours ... What do you think ? Gert - Original Message - From: Kevin Miller [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, February 27, 2004 9:24 PM Subject: [nant-dev] AsmInfo patch I found the asminfo task today and fell in love. It solved a few problems I was having with signing assemblies and paths to the key file. I was frustrated by the fact that it always generates the AssemblyInfo.cs file even if there are no changes. This causes the csc/vbc task to build the project even if only the AssemblyInfo class has been updated. This is clearly an annoyance during development builds. Attached is an updated that compares the present AssemblyInfo.x to the one being generated. If they are different it writes the new code one out to disk. This file is updating the .84 release. Sorry I did not compare to the latest cvs. Also, I did not add a switch to make this behavior optional. This post is just to feel out well this enhancement would be received. I am willing to create a decent patch. Let me know if there is interest in this feature. Kevin Miller --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] Current target
Hi all,
is there a built-in property that contains the name
of the current target? In my projects, I use to
generate gateway build files like this:
project
name=myProject
default=recurse
target
name=recurse
description=Builds recursively all subprojects
foreach
item=Folder
property=foldername
in
items
includes name=*/
excludes name=CVS/
/items
/in
do
nant
buildfile=${foldername}/default.build
target=${project.config} ${target}/
/do
/foreach
/target
/project
The purpose of such a build file is just to forward
a target from a build file in the parent directory to
the build files in all of the children directories.
To implement that, I define a property named target
in the parent build file that contains the name of
the target to execute...
I think it would be nice to have a built-in property
named nant.current.target that contains the name of
the executing target.
What's your opinion?
j3d.
--
Giuseppe Greco
::agamura::
phone: +41 91 604 67 65
mobile: +41 76 390 60 32
email: [EMAIL PROTECTED]
web:www.agamura.com
---
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
