On my system, the generate source is perfectly valid :
[assembly:
AssemblyKeyFileAttribute("C:\\first\\project\\FCFL.NET\\build\\net-1.1.win32
\\FCFL.NET-4.0-debugbuild\\Licensing\\L" +
"icenseInstaller\\bin\\..\\..\\..\\..\\Key.snk")]
what version of the .NET Framework are you using ?
Gert
----- Original Message -----
From: "Kevin Miller" <[EMAIL PROTECTED]>
To: "Gert Driesen" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Monday, March 01, 2004 6:54 PM
Subject: RE: [nant-dev] AsmInfo patch
Another bug that I noticed is that if someone uses forward slashes in a
<attribute type="AssemblyKeyFileAttribute"
value="${build.dir}/../Key.snk" />
*Alternatively*
<attribute type="AssemblyKeyFileAttribute"
value="C:\first\project\FCFL.NET\build\net-1.1.win32\FCFL.NET-4.0-debugb
uild\Licensing\LicenseInstaller\bin\..\..\..\..\Key.snk" />
Result in an attribute like this:
[assembly:
AssemblyKeyFileAttribute("C:\\first\\project\\FCFL.NET/build/net-1.1.win
32/FCFL.NET-4.0-debugbuild/Licensing/L" +
"icenseInstaller/../Key.snk")]
I am guessing this is because the path is so long that the codedom is
trying to split it across lines. Which is unfortunate as this does not
seem to be legal syntax. Any CodeDOM-fu help here?
Kevin
-----Original Message-----
From: Gert Driesen [mailto:[EMAIL PROTECTED]
Sent: Saturday, February 28, 2004 5:18 PM
To: Kevin Miller
Subject: Re: [nant-dev] AsmInfo patch
well, clean and less error prone code is more important than performance
for tasks that are not called many times during a normal build cycle ...
keep the patches coming, we can use all help we can get :)
Gert
----- Original Message -----
From: "Kevin Miller" <[EMAIL PROTECTED]>
To: "Gert Driesen" <[EMAIL PROTECTED]>
Sent: Saturday, February 28, 2004 5:56 PM
Subject: RE: [nant-dev] AsmInfo patch
Gasp, well glad you enjoyed it so much it's performance didn't matter.
Thanks!
Kevin
-----Original Message-----
From: Gert Driesen [mailto:[EMAIL PROTECTED]
Sent: Sat 2/28/2004 10:30 AM
To: Kevin Miller; [EMAIL PROTECTED]
Subject: 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=1356&alloc_id=3438&op=click
_______________________________________________
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
