I did not realize that the defaultFramework would force the library to use. Is the compiler choosing the libraries then?
In any case, the algorithm sounds good to me. Clayton -----Original Message----- From: Ian MacLean [mailto:[EMAIL PROTECTED] Sent: June 16, 2003 6:22 PM To: Clayton Harbour Cc: Erv Walter; [EMAIL PROTECTED] Subject: Re: [nant-dev] BUG?: <includes ... frompath="true" /> Clayton Harbour wrote: >Bingo. Might not be the best solution but (I think) it is a little more >deterministic. The implications of course are that if the default >framework gets changed in nant then all csc targets in all build files >point to the new framework libraries unless overridden. I think this >would be a good thing though... > > Just to be clear - this will only affect <includes> entries that specify a bare file name ( ie not includes name="../foo.dll" ) and that bare file name isn't matched in the current directory - what the fileset will do by default. So the algorithm will go somthing like this: if includes entry is barefile name and not asis and not frompath if currentframeworkdir / filename exists use that else pass file name directly to the compiler and let it deal with it. I think that trying the default framework from the config file would only add confusion. Remember that if currentframework hasn't been set in the build file it will be the same as defaultframework. If you specify frompath or asis then you've made the decision about where to find the reference. Does this sound reasonable ? I hope I understodd everyones suggestions correctly. Ian > >Clayton > > >-----Original Message----- >From: Erv Walter >Sent: Fri 6/13/2003 2:59 PM >To: Clayton Harbour; Erv Walter; Erv Walter; >[EMAIL PROTECTED] >Cc: >Subject: RE: [nant-dev] BUG?: <includes ... frompath="true" /> >Ok, I think we're actually agreeing and I was just confused on the term >"nant framework path" > >I was previously thinking you meant "nant framework path" = path of the >framework that is hosting nant.exe (aka the path for whichever framework >you get from sys.clr.version and the <sysinfo/> task). I hope that that >makes sense. Basically, in our default releases, nant.exe is a .NET 1.0 >application. The fact that it is a .NET 1.0 application should not >impact which paths are used for references in the <csc> task. > >I think that you are actually saying that "nant framework path" = path >of the framework from <nantsettings defaultframework="net-1.0"/> in >nant.exe.config. > >If that is the case then I agree conceptually that the first choice >should be the framework specified by the .build file. Then the default >framework from the nant.exe.config file. I don't think that finding a >reference in the system path is ever a "wise" idea because it's >unpredictable depending on the machine you're running on. However, I'm >happy to give people the option to be unwise as long as we try the other >two choices first. > > > >-----Original Message----- >From: Clayton Harbour [mailto:[EMAIL PROTECTED] >Sent: Friday, June 13, 2003 4:57 PM >To: Erv Walter; Erv Walter; [EMAIL PROTECTED] > >I disagree. > > > >>>If nant is compile with and running under the 1.0 .NET framework >>>(which it does by default if you have both frameworks installed) >>> >>> > >Specified by the current framework variable. > > > >>>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 >>> >>> > >Then the build would break, unless you override the current framework >for that specific target. In which case the libraries being used would >be from whatever framework you specify (using the current framework >variable). The decision would be made once before csc is called, not >before each library is determined. > > > >What is happening now (if I understand matters correctly) is the csc >task is falling through to the path variable when choosing libraries to >build with. What this means is that you are depending on the framework >1.0 or 1.1 to be first in the path variable. In other words unless you >are particular with your path variable it is a crap shoot which library >you are getting. And there is no way to override that during a build >(again, if my understanding is correct). > >I see defaulting to the same libraries as the nant application is using >an alternative to falling through to this path variable. Although this >may not be the correct decision for the project being compiled it is at >least declarative. > >So while gathering references the choice would look something like this >(please excuse aproximate names): > > if (currentFramework != null) { > cscLibraryPath = currentFrameworkLibraryPath; > } > else if (defaultNAntFramework != null) { > cscLibraryPath = defaultNAntFrameworkLibraryPath; > } > else { > cscLibraryPath = librariesFromPath; > } > >This gives you the ability to override the path variable at the project >level (and I believe the task level). This is a decision that would be >run before the referenced files were gathered, therefore you would not >mix and match frameworks. > > > >Clayton > >-----Original Message----- >From: Erv Walter >Sent: Fri 6/13/2003 1:13 PM >To: Clayton Harbour; Erv Walter; >[EMAIL PROTECTED] >Cc: >Subject: RE: [nant-dev] BUG?: <includes ... frompath="true" /> >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 > > > > > >------------------------------------------------------- >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: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php _______________________________________________ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
