I guess my point is this: If nant is compile with and running under the 1.0 .NET framework (which it does by default if you have both frameworks installed), and If I specify my project should built with the 1.1 .NET framework, and if the referenced file is not found in the 1.1 .NET framework path, using a file from the 1.0 .NET Framework path is *never* a correct choice. That would mean that some of my reference go to 1.0 assemblies and some to 1.1 assemblies. That is a recipe for a broken application. If I reference System.Xml.dll without a specific path and if I'm compiling with "current framework" set to 1.1, the only correct place to find System.Xml.dll is the 1.1 framework path. That's what you get when you do asis="true".
-----Original Message----- From: Clayton Harbour [mailto:[EMAIL PROTECTED] Sent: Friday, June 13, 2003 2:21 PM To: Erv Walter; [EMAIL PROTECTED] I might be a bit wrong on this (and if I am please correct me) but the way I understand it the nant framework path is the path being used to run nant. I think this can be seperate from the framework you specify to compile your project with the csc task. Is this correct? Blazing ahead under this assumption, the csc task would then be looking at the closest setting (the project/ build file level). If nothing is found at this level then look at the version of .net that nant is running with, if that falls through (not sure if it ever would...) then check the system path. The reason for the second stop is to give a little more control of which framework is being used (i.e. it is not left up to order in the path variable). I do not think this would ever fall through (unless it is possible to hack the default framework out of the nant.exe.config and still have it work...have not tried that) but if it does the backup would then be to use whatever is in your path variable. Does this make sense? Clayton -----Original Message----- From: Erv Walter Sent: Fri 6/13/2003 11:28 AM To: [EMAIL PROTECTED] Cc: Subject: RE: [nant-dev] BUG?: <includes ... frompath="true" /> I'm confused on why you would ever want to find a reference in "Current nant framework path" as listed below? The only time that an assembly would be in the nant framework path and not in the current framework path is when the located assembly is of the wrong version!? -----Original Message----- From: Clayton Harbour [mailto:[EMAIL PROTECTED] On Behalf Of Clayton Harbour Sent: Friday, June 13, 2003 1:36 PM To: Ian MacLean; Jaroslaw Kowalski Cc: [EMAIL PROTECTED] Hi, I think it would be more intuitive to search in the following manner: - Current project framework path - Current nant framework path - Path system variable - blow up! Is this what you are suggesting Ian? Clayton -----Original Message----- From: Ian MacLean Sent: Fri 6/13/2003 7:45 AM To: Jaroslaw Kowalski Cc: [EMAIL PROTECTED] Subject: Re: [nant-dev] BUG?: <includes ... frompath="true" /> not really - although a bit confusing. The frompath is working as expected assuming that Framework\v1.0.3705 is the first one in the path. When you specify asis it passes the bare file name to csc and so the 1.1 csc will find System.Data.dll using its own search heuristics. There was talk a little while back of making references framework aware. However the problem is if you specify a bare filename ( eg System.Data.dll ) how does the csc task know whether its a system dll to be resolved by currentframeworkpath or whether you expect to find it on the path. I guess if there is not frompath and no asis we can try it as a framework path and if it exists pass that to the compiler. Just thinking aloud - any ideas welcome. Ian > I have two frameworks (net-1.0 and net-1.1) installed. I have a <csc> > task that includes a reference to <csc> <includes > name="System.Data.dll" frompath="true" /> > > When i compile with net-1.1 it passes the following (incorrect) option > to the csc.exe compiler. > "/reference:C:\WINNT\Microsoft.NET\Framework\v1.0.3705\System.Data.dll" > > instead of: > "/reference:C:\WINNT\Microsoft.NET\Framework\v1.1.4322\System.Data.dll" > > When I do: > <includes name="System.Data.dll" asis="true" /> > > it works, because csc finds the correct version of System.Data.dll by > itself. Is it a bug? > > Jarek > > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: eBay Great deals on office > technology -- on eBay now! Click here: > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > _______________________________________________ > Nant-developers mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/nant-developers ------------------------------------------------------- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 _______________________________________________ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers ------------------------------------------------------- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 _______________________________________________ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers ------------------------------------------------------- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 _______________________________________________ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
