Re: [nant-dev] Re: Solution task fixes + speedups
- Original Message - From: Matthew Mastracci [EMAIL PROTECTED] To: Gert Driesen [EMAIL PROTECTED] Cc: Nant-Developers (E-mail) [EMAIL PROTECTED] Sent: Wednesday, March 17, 2004 7:30 PM Subject: Re: [nant-dev] Re: Solution task fixes + speedups Gert Driesen wrote: I can also guarantee 100% that VS.NET (2003) is only using the hintpath as a last resort ;) I've reverted the change in CVS. Thanks for the explanation :) You're welcome ;) Gert --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Re: Solution task fixes + speedups
Gert Driesen wrote: So anyways, I finally understand that you are correct - VS.NET does check AssemblyFolders before HintPath. IMHO this is a strange way to do things. VS.NET doesn't make it easy to easily reproduce a build between two machines, does it? No, definitely not. In my opinion, VS.NET should only use AssemblyFolders if the AssemblyFolderKey is set on the reference. I agree! :) Unfortunately, I need to build on a clean system that doesn't have any csproj.user files. Perhaps I'll just delete the AssemblyFolders key from the registry on the build machine. Kind of drastic, no ? Since the AssemblyFolder stuff doesn't take into account versioning (we use two different versions of the ComponentOne stuff and need both for a successful build), we need to be able to specify the exact version that we're linked against. C1 is an example of a 3rd party library that can't be upgraded from a specific version without *something* breaking. :) We also can't really check in the csproj.user file, since each developer has their own copy (it's not really meant to be checked in anyways). Do you have time to add support for the ReferencesPath attrribute to our reference resolving procedure ? Do you mean reading the csproj.user files? Sure. I suppose we should probably add in some debugging traces for reference resolution. It would make it easier to figure out why a DLL is getting picked up from the wrong place. I really would like to set up a small team of developers to focus on improving/refactoring the solution task, would you be interested ? Yep. Just let me know and I'll see if I can allocate a bit of time to help out. Matt. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Re: Solution task fixes + speedups
- Original Message - From: Matthew Mastracci [EMAIL PROTECTED] To: Gert Driesen [EMAIL PROTECTED] Cc: Nant-Developers (E-mail) [EMAIL PROTECTED] Sent: Thursday, March 18, 2004 5:04 PM Subject: Re: [nant-dev] Re: Solution task fixes + speedups Unfortunately, I need to build on a clean system that doesn't have any csproj.user files. Perhaps I'll just delete the AssemblyFolders key from the registry on the build machine. Kind of drastic, no ? Since the AssemblyFolder stuff doesn't take into account versioning (we use two different versions of the ComponentOne stuff and need both for a successful build), we need to be able to specify the exact version that we're linked against. C1 is an example of a 3rd party library that can't be upgraded from a specific version without *something* breaking. :) I never understood why MS did not save the version (and public key, culture) of the assembly in the project file, and used that to resolve the assembly reference. I hope they'll get it right in Whidbey. We also can't really check in the csproj.user file, since each developer has their own copy (it's not really meant to be checked in anyways). Do you have time to add support for the ReferencesPath attrribute to our reference resolving procedure ? Do you mean reading the csproj.user files? Yeps, Sure. Great. I suppose we should probably add in some debugging traces for reference resolution. It would make it easier to figure out why a DLL is getting picked up from the wrong place. Yeah, I'll look into that. I really would like to set up a small team of developers to focus on improving/refactoring the solution task, would you be interested ? Yep. Just let me know and I'll see if I can allocate a bit of time to help out. Guess we'll first have to agree on what and how. I'll send a mail to the dev list later. Gert --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] CopyLocal - once and for all :)
It seems like our CopyLocal logic in the solution task doesn't seem to match VS.NET 2003. Did this change between 2002/2003? As far as I can see, if the CopyLocal flag is not specified in 2003, it should be treated as false. Does anyone know for sure what this is in 2002? Matt. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] CopyLocal - once and for all :)
Matthew, The CopyLocal behaviour depends on whether the assembly is a system assembly or not (and some other criteria too perhaps). I'm pretty sure the current implement matches the behaviour of VS.NET 2003, but I might be wrong ofcourse. Do you have a example of where the behaviour differs ? Gert On Thu, 2004-03-18 at 21:46, Matthew Mastracci wrote: It seems like our CopyLocal logic in the solution task doesn't seem to match VS.NET 2003. Did this change between 2002/2003? As far as I can see, if the CopyLocal flag is not specified in 2003, it should be treated as false. Does anyone know for sure what this is in 2002? Matt. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] CopyLocal - once and for all :)
Gert Driesen wrote: Matthew, The CopyLocal behaviour depends on whether the assembly is a system assembly or not (and some other criteria too perhaps). I'm pretty sure the current implement matches the behaviour of VS.NET 2003, but I might be wrong ofcourse. Do you have a example of where the behaviour differs ? I wonder if this is the problem: in Reference.cs, _privateSpecified and _isPrivate are being used before they have actually been assigned in the constructor (for project refs and visual C++ projects references). The ternary operator logic is correct, but I think _copyLocal always ends up being true for project references due to this bug. I suppose the solution is to move the test up in the file. This will likely fix my issue. :) Matt. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] CopyLocal - once and for all :)
I'll have a look tomorrow (its getting quite late here). If you can provide a repro for this, please do so ... I'm trying to collect as much test projects/solutions as possible, so we have good test cases available if we decide to rewrite parts of the solution task Gert On Thu, 2004-03-18 at 22:46, Matthew Mastracci wrote: Gert Driesen wrote: Matthew, The CopyLocal behaviour depends on whether the assembly is a system assembly or not (and some other criteria too perhaps). I'm pretty sure the current implement matches the behaviour of VS.NET 2003, but I might be wrong ofcourse. Do you have a example of where the behaviour differs ? I wonder if this is the problem: in Reference.cs, _privateSpecified and _isPrivate are being used before they have actually been assigned in the constructor (for project refs and visual C++ projects references). The ternary operator logic is correct, but I think _copyLocal always ends up being true for project references due to this bug. I suppose the solution is to move the test up in the file. This will likely fix my issue. :) Matt. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Solution task problems
Jia, I suggest using the latest nightly build (http://nant.sourceforge.net/nightly/builds) as lots of fixes for the solution task were committed recently. Let us know if you still have this or other problems with the nightly build. Gert On Mon, 2004-01-05 at 03:41, Jia Bin wrote: hi, I'm trying to build a solution and met the following problem. BUILD FAILED INTERNAL ERROR System.IO.FileLoadException: Assembly gemgeocurtainm.dll already loaded without additional security evidenc . File name: gemgeocurtainm.dll Server stack trace: at System.Reflection.Assembly.nLoad(AssemblyName fileName, String codeBase, Boolean isStringized, Eviden e assemblySecurity, Boolean throwOnFileNotFound, Assembly locationHint, StackCrawlMark stackMark) at System.Reflection.Assembly.InternalLoad(AssemblyName assemblyRef, Boolean stringized, Evidence assemb ySecurity, StackCrawlMark stackMark) at System.Reflection.Assembly.LoadFrom(String assemblyFile, Evidence securityEvidence, Byte[] hashValue, AssemblyHashAlgorithm hashAlgorithm) at System.Reflection.Assembly.LoadFrom(String assemblyFile, Evidence securityEvidence) at NAnt.DotNet.Tasks.LicenseGatherer.CreateLicenseFile(LicenseTask licenseTask, String licenseFile) in D \Work\NAnt\src\NAnt.DotNet\Tasks\LicenseTask.cs:line 251 at System.Runtime.Remoting.Messaging.StackBuilderSink.PrivateProcessMessage(MethodBase mb, Object[] args Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[] outArgs) at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg, Int32 methodPtr, oolean fExecuteInContext) Exception rethrown at [0]: at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg) at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData msgData, Int32 type) at NAnt.DotNet.Tasks.LicenseGatherer.CreateLicenseFile(LicenseTask licenseTask, String licenseFile) in D \Work\NAnt\src\NAnt.DotNet\Tasks\LicenseTask.cs:line 210 at NAnt.DotNet.Tasks.LicenseTask.ExecuteTask() in D:\Work\NAnt\src\NAnt.DotNet\Tasks\LicenseTask.cs:line 191 at NAnt.Core.Task.Execute() in D:\Work\NAnt\src\NAnt.Core\Task.cs:line 151 at NAnt.VSNet.Resource.CompileLicx() in D:\Work\NAnt\src\NAnt.VSNet\Resource.cs:line 165 at NAnt.VSNet.Resource.Compile(ConfigurationSettings configurationSettings, Boolean showCommands) in D:\ ork\NAnt\src\NAnt.VSNet\Resource.cs:line 73 at NAnt.VSNet.Project.Compile(String configuration, ArrayList alCSCArguments, String strLogFile, Boolean bVerbose, Boolean bShowCommands) in D:\Work\NAnt\src\NAnt.VSNet\Project.cs:line 355 at NAnt.VSNet.Solution.Compile(String configuration, ArrayList compilerArguments, String logFile, Boolea verbose, Boolean showCommands) in D:\Work\NAnt\src\NAnt.VSNet\Solution.cs:line 279 at NAnt.VSNet.Tasks.SolutionTask.ExecuteTask() in D:\Work\NAnt\src\NAnt.VSNet\Tasks\SolutionTask.cs:line 335 at NAnt.Core.Task.Execute() in D:\Work\NAnt\src\NAnt.Core\Task.cs:line 151 at NAnt.Core.Target.Execute() in D:\Work\NAnt\src\NAnt.Core\Target.cs:line 217 at NAnt.Core.Project.Execute(String targetName, Boolean forceDependencies) in D:\Work\NAnt\src\NAnt.Core Project.cs:line 772 at NAnt.Core.Project.Execute() in D:\Work\NAnt\src\NAnt.Core\Project.cs:line 734 at NAnt.Core.Project.Run() in D:\Work\NAnt\src\NAnt.Core\Project.cs:line 797 Regards Jia Bin - BGC-PET:http://bgc-pet.fea.slb.com/Gallery/ Tel: +86 10 6279 9009 (ext.6239) Fax: +86 10 6279 3733 --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
