I have just deleted an assembly, and log4net from the build/bin root directory, but 
this typically occurs on the first assembly that is compiled.  Here it is:

     [nant] /home/claytonharbour/dev/src/nant/nant/src/NAnt.DotNet/NAnt.DotNet.build 
build

            Buildfile: 
file://home/claytonharbour/dev/src/nant/nant/src/NAnt.DotNet/NAnt.DotNet.build
            Target(s) specified: build 
            
            build:
            
                  [csc] Compiling 18 files to 
'/home/claytonharbour/dev/src/nant/nant/build/mono-1.0.unix/nant-0.85-debug/bin/NAnt.DotNetTasks.dll'.
                        
                        ** (/usr/bin/mcs.exe:21160): WARNING **: Could not find 
assembly log4net, references from 
/home/claytonharbour/dev/src/nant/nant/build/mono-1.0.unix/nant-0.85-debug/bin/NAnt.Core.dll
 (assemblyref_index=1)
                             Major/Minor: 1,2
                             Build:       0,30714
                             Token:       (null)
                        
                        
                        Unhandled Exception: System.NullReferenceException: A null 
value was found where an object instance was required.
                        in (unmanaged) /usr/lib/libmono.so.0(mono_assembly_open+0x1b9) 
[0x49f797]
                        in (unmanaged) /usr/lib/libmono.so.0 [0x48f9ff]
                        in <0x000d1> Mono.CSharp.Driver:LoadAssembly (string,bool)
                        in <0x0009f> Mono.CSharp.Driver:LoadReferences ()
                        in <0x006ac> Mono.CSharp.Driver:MainDriver (string[])
                        in <0x0001a> Mono.CSharp.Driver:Main (string[])
                        
            
            BUILD FAILED
            
            
/home/claytonharbour/dev/src/nant/nant/src/NAnt.DotNet/NAnt.DotNet.build(11,9):
            External Program Failed: /usr/bin/mcs.exe (return code was 1)


Do you have the dlls somewhere in your path? 




-----Original Message-----
From:   Ian MacLean [mailto:[EMAIL PROTECTED]
Sent:   Wed 5/5/2004 8:01 AM
To:     Clayton Harbour
Cc:     Gert Driesen; Nant-Developers (E-Mail)
Subject:        Re: [nant-dev] Mono 1.0 / Using NAnt project for framework discovery
Clayton,
I built from the release tarballs ( also 0.91 ) but that should be 
pretty much the same as using red-carpet. Why did you have to move the 
dlls ? What error did you get ?

Ian
Clayton Harbour wrote:

>
>I grabbed the rpms off of Red Carpet which give me version 0.91.  For this version I 
>had to move the dlls in the lib/mono/1.0 directory up to the task directory.  Are we 
>using different versions?  Also changing the encoding of the configuration file to 
>UTF-8 gets around the xml exception, can this be changed without causing problems 
>elsewhere?
>
>
>Cheers,
>
>
>Clayton
>
>-----Original Message-----
>From:  Ian MacLean [mailto:[EMAIL PROTECTED]
>Sent:  Wed 5/5/2004 12:34 AM
>To:    Gert Driesen
>Cc:    Nant-Developers (E-Mail)
>Subject:       Re: [nant-dev] Mono 1.0 / Using NAnt project for framework discovery
>Gert Driesen wrote:
>
>  
>
>>I haven't yet had time to look into this myself, so can you tell us what
>>tweaking you had to do to get NAnt working on mono beta 1 ?
>>
>> 
>>
>>    
>>
>sure - Just needed to change the path for framework assemblies in 
>NAnt.exe.config from /usr/local/lib to /usr/local/lib/mono/1.1. The exe 
>files are still all in /usr/local/bin which come to think of it won't 
>work for a true side by side install. I also had to remove the encoding 
>document from the xml header as that was causing it to fail with an xml 
>load error.
>
>There are also a bunch of 'remapping' warnings when running as the 
>assemblies we ship in the /lib directory for mono were built against 
>unsigned versions of the mono system assemblies. This doesn't prevent it 
>from working though.
>
>  
>
>>Should we add a pkg-config "task" to NAnt, and use this "task" in the NAnt
>>configuration file ?
>>
>> 
>>
>>    
>>
>I was actually thinking along similar lines. Someone would need to 
>implement a pkg-config-sharp library which shouldn't be too much effort. 
>It would be better to have that reside in the mono codebase if those 
>guys are amenable to that.
>
>Using 'task' functionality from the config file is an interesting idea. 
>re-using the functionality already defined in tasks would be a good 
>thing. There would have to be restrictions of course as you can do lots 
>of things in a build file that probably aren't appropriate in the config 
>file.
>
>calling it 'project' inside the config file looks a bit funny. Maybe we 
>could give it a different name but still use project loading 
>functionality to process it.
>
>Ian
>
>  
>
>>We could actually allow a project to be defined as part of the framework
>>node, that would really be powerful.
>>
>><framework
>>   name="mono-1.0"
>>   family="mono"
>>   version="1.0"
>>   description="GNOME projects port of the .NET Framework"
>>   runtimeengine="mono"
>>   sdkdirectory="${prefix}/bin"
>>   frameworkdirectory="${prefix}/bin"
>>   frameworkassemblydirectory="${prefix}/lib"
>>   clrversion="1.1.4322"
>>   >
>>   <project>
>>       <pkg-config package="mono" variable="prefix" property="prefix" />
>>   </project>
>>   ....
>></framework>
>>
>>We could then use actual NAnt tasks, expressions, ... to determine
>>information about the framework instead of having to implement "hacks" for
>>this purpose ... For all frameworks except Mono, this project would only be
>>a collection of <property> and <readregistry> tasks (for this last task, we
>>would need to have the NAnt.Win32Tasks assembly loaded, so we should add a
>>tasks fileset to the platform node (which would be better than having to
>>repeat the same includes for every framework).
>>
>>The caveats I see right now are :
>>
>>- all that tasks and expressions that you use in the project should not rely
>>on any framework-related information, as at that time there is no such thing
>>as a target framework, or runtime framework defined (Project.TargetFramework
>>and Project.RuntimeFramework would be null), as we're in the process of
>>actually determining these.
>>- we would not be able to access the filename of the build file (as the
>>project would be constructed using an XML document that would not be backed
>>by a file)
>>
>>But ofcourse, I haven't given this a lot of thought, so there might be more
>>issues ...
>>
>>The properties referenced in attributes of the framework node, would then be
>>expanded using the properties set as part of the framework project ...
>>
>>I really don't think this would require a lot of effort... I'd be happy to
>>look into this ...
>>
>>What do you think ?
>>
>>Gert
>>
>>----- Original Message ----- 
>>From: "Ian MacLean" <[EMAIL PROTECTED]>
>>To: "Jaroslaw Kowalski" <[EMAIL PROTECTED]>
>>Cc: "Scott Hernandez" <[EMAIL PROTECTED]>; "Gert Driesen"
>><[EMAIL PROTECTED]>
>>Sent: Tuesday, May 04, 2004 5:37 PM
>>Subject: Re: Mono GAC
>>
>>
>> 
>>
>>    
>>
>>>Looks like its all ok now. After a bit of config file tweaking nant
>>>builds ok on the mono beta1 preview released today. Looks like we'll
>>>probably need to find a way to use pkg-config to determine the mono base
>>>directory but that will still be better than hardcoding it as we are now.
>>>
>>>Ian
>>>
>>>Jaroslaw Kowalski wrote:
>>>
>>>   
>>>
>>>      
>>>
>>>>See this:
>>>>
>>>>     
>>>>
>>>>        
>>>>
>>>http://lists.ximian.com/archives/public/mono-devel-list/2004-May/005227.htm
>>>   
>>>
>>>      
>>>
>>l
>> 
>>
>>    
>>
>>>>http://lists.ximian.com/archives/public/mono-list/2004-April/019844.html
>>>>
>>>>Jarek
>>>>
>>>>----- Original Message ----- 
>>>>From: "Scott Hernandez" <[EMAIL PROTECTED]>
>>>>To: "Jaroslaw Kowalski" <[EMAIL PROTECTED]>
>>>>Cc: "Gert Driesen" <[EMAIL PROTECTED]>; "Ian MacLean"
>>>><[EMAIL PROTECTED]>
>>>>Sent: Saturday, May 01, 2004 8:10 PM
>>>>Subject: Re: Mono GAC
>>>>
>>>>
>>>>
>>>>
>>>>     
>>>>
>>>>        
>>>>
>>>>>I'm off the mono lists, what is the deal?
>>>>>
>>>>>----- Original Message ----- 
>>>>>From: "Jaroslaw Kowalski" <[EMAIL PROTECTED]>
>>>>>
>>>>>
>>>>>
>>>>>       
>>>>>
>>>>>          
>>>>>
>>>>>>Hi guys!
>>>>>>
>>>>>>What do you think about the recent mono GAC "feature"? Should we fight
>>>>>>
>>>>>>
>>>>>>         
>>>>>>
>>>>>>            
>>>>>>
>>>>the
>>>>
>>>>
>>>>     
>>>>
>>>>        
>>>>
>>>>>>idea or invent a way do handle it?
>>>>>>
>>>>>>The hack to detect system libraries in references and pass them
>>>>>>
>>>>>>
>>>>>>         
>>>>>>
>>>>>>            
>>>>>>
>>>>>unqualified
>>>>>
>>>>>
>>>>>       
>>>>>
>>>>>          
>>>>>
>>>>>>would be huge and ugly.
>>>>>>
>>>>>>Jarek
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>         
>>>>>>
>>>>>>            
>>>>>>
>>>-- 
>>>Ian MacLean, Developer,
>>>ActiveState, a division of Sophos
>>>http://www.ActiveState.com
>>>
>>>
>>>
>>>   
>>>
>>>      
>>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by: Oracle 10g
>>Get certified on the hottest thing ever to hit the market... Oracle 10g. 
>>Take an Oracle 10g class now, and we'll give you the exam FREE.
>>http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
>>_______________________________________________
>>nant-developers mailing list
>>[EMAIL PROTECTED]
>>https://lists.sourceforge.net/lists/listinfo/nant-developers
>> 
>>
>>    
>>
>
>
>  
>


-- 
Ian MacLean, Developer, 
ActiveState, a division of Sophos
http://www.ActiveState.com







-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver
higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers

Reply via email to