[Mono-dev] Current 'xbuild' status
Leszek Ciesielski
skolima at gmail.com
Wed Feb 11 12:44:55 EST 2009
Something along this patch? :-)
And the problematic assemblies follow:
Target ResolveAssemblyReferences:
Replacing reference to assembly:
/opt/mono/lib/mono/gac/System.Runtime.Serialization/2.0.5.0__7cec85d7bea7798e/System.Runtime.Serialization.dll
with
/opt/mono/lib/mono/gac/System.Runtime.Serialization/2.0.5.0__b77a5c561934e089/System.Runtime.Serialization.dll
Replacing reference to assembly:
/opt/mono/lib/mono/gac/System.ServiceModel/2.0.5.0__31bf3856ad364e35/System.ServiceModel.dll
with
/opt/mono/lib/mono/gac/System.ServiceModel/2.0.5.0__b77a5c561934e089/System.ServiceModel.dll
Replacing reference to assembly:
/opt/mono/lib/mono/gac/System.ServiceModel.Web/2.0.5.0__31bf3856ad364e35/System.ServiceModel.Web.dll
with
/opt/mono/lib/mono/gac/System.ServiceModel.Web/2.0.5.0__7cec85d7bea7798e/System.ServiceModel.Web.dll
They are different because they are signed with different public keys?
It's probably because they graduated from olive into mcs, and those
trees use different keys AFAIK? Anyway, the resolver has to handle
this - probably by including the public key in version information.
2009/2/11 Jonathan Chambers <joncham at gmail.com>:
> I have seen this repeatedly and have not been able to figure out why (unless it's just old things lying around). If you look in your GAC, somewhere you will have 2 versions of some assembly that both are 2.0.0.xxx. The current resolve logic chokes on this trying to add a duplicate key to a dictionary. It probably shouldn't fail but I can't figure out why there are two assemblies with similar version numbers.
> If you modify the code in xbuild where it is populating the dictionary you can output the duplicate assembly. In fact, I'll try and add code that outputs the duplicate assembly and handle the error case better.
> Thanks,
> Jonathan
>
> On Wed, Feb 11, 2009 at 11:55 AM, Leszek Ciesielski <skolima at gmail.com> wrote:
>>
>> When I forced msbuild 2.0 and regenerated the project, xbuild bails
>> out on ResolveAssemblyReferences. Log attached.
>>
>> On Wed, Feb 11, 2009 at 5:35 PM, Jonathan Chambers <joncham at gmail.com> wrote:
>> > Hello,
>> > I am guessing xbuild is only supporting 2.0 for now. I am not sure how much
>> > effort is needed to support 3.5/2008 projects.
>> > Thanks,
>> > Jonathan
>> >
>> > On Wed, Feb 11, 2009 at 11:28 AM, Leszek Ciesielski <skolima at gmail.com>
>> > wrote:
>> >>
>> >> using today's svn version, .proj file generated with "set
>> >> MSBuildEmitSolution=1" trick:
>> >>
>> >> [mono] ~/mono_svn/EVEMon @ xbuild EVEMonCSharp.sln.proj
>> >> XBuild Engine Version 0.1
>> >> Mono, Version 2.5.0.0
>> >> Copyright (C) Marek Sieradzki 2005. All rights reserved.
>> >> MSBUILD: error MSBUILD0000:
>> >> /root/mono_svn/EVEMon/EVEMonCSharp.sln.proj: Could not load file or
>> >> assembly 'Microsoft.Build.Tasks.v3.5' or one of its dependencies. The
>> >> system cannot find the file specified.
>> >>
>> >> (project is EVEMon, from
>> >> svn://evemon.battleclinic.com/EVEMon/EVEMon/trunk)
>> >>
>> >> On Thu, Feb 5, 2009 at 11:23 AM, Ankit Jain <radical at gmail.com> wrote:
>> >> > xbuild (svn) can't directly handle .sln files right now. But it can
>> >> > build the temporary .proj that msbuild
>> >> > generates for .sln files.
>> >> >
>> >> > We can build the .sln.proj with multiple projects. Its not
>> >> > complete yet though.
>> >> > Currently, it generates the resources, satellite assemblies,
>> >> > resolves gac/assembly references, compiles, but doesn't deploy
>> >> > the referenced assemblies etc to the right location. But most of
>> >> > this will be work in the .targets .
>> >> > It should be easy to write a sln-> proj convertor.
>> >> >
>> >> > List of msbuild features from msdn (
>> >> > http://msdn.microsoft.com/en-us/library/ms171452.aspx )
>> >> > • Items
>> >> > ∘ Supported. These are used all over the place, so seems to work
>> >> > fine for current test cases
>> >> > • Properties
>> >> > ∘ Likewise
>> >> > • Targets
>> >> > ∘ Implemented
>> >> > ∘ Including dependency checking, in the form of input/output list,
>> >> > "DependsOnTargets" etc
>> >> > • Tasks
>> >> > ∘ Implemented
>> >> > ∘ Most of the functionality in msbuild files are based on using
>> >> > tasks. Custom tasks can be loaded
>> >> > • Advanced Concepts
>> >> > ∘ Logging
>> >> > ‣ Implemented. But its not being used throughout the system
>> >> > right now to report errors/warnings.
>> >> > ∘ Batching (
>> >> > http://msdn.microsoft.com/en-us/library/ms171473(VS.80).aspx )
>> >> > ‣ Very important feature
>> >> > ‣ Both task and target batching have been implemented, and seem
>> >> > to be working fine
>> >> > ∘ Transforms ( http://msdn.microsoft.com/en-us/library/ms171476.aspx )
>> >> > ‣ Supported
>> >> > ∘ Using multiple processors (
>> >> > http://msdn.microsoft.com/en-us/library/bb383805.aspx )
>> >> > ‣ Nothing has been done for this yet
>> >> > • Building for Specific .NET Frameworks (
>> >> > http://msdn.microsoft.com/en-us/library/bb397456.aspx )
>> >> > ∘ I've added some preliminary support for TargetFramework* stuff,
>> >> > but this will need more work
>> >> > ∘ Similar work done in monodevelop should prove useful here
>> >> > • Others
>> >> > ∘ Project references, assembly, gac references are resolved
>> >> > ‣ I committed kinda preliminary code for this, which works fine
>> >> > in the simple test cases (eg. pdn3) that I tried
>> >> >
>> >> > Ofcourse, most of this hasn't been tested extensively. I try to write
>> >> > reasonable number of tests for the stuff
>> >> > that I'm touching, but real testing would happen once the targets
>> >> > files are more complete and we try real
>> >> > world projects.
>> >> >
>> >> > Would be nice to start trying this out and get feedback/bug reports :)
>> >> >
>> >> > I'll be on vacation till end of next week, but will try to reply to
>> >> > mails.
>> >> >
>> >> > -Ankit
>> >> >
>> >> > --
>> >> > Blog : http://www.ankitjain.org/blog
>> >> > _______________________________________________
>> >> > Mono-devel-list mailing list
>> >> > Mono-devel-list at lists.ximian.com
>> >> > http://lists.ximian.com/mailman/listinfo/mono-devel-list
>> >> >
>> >> _______________________________________________
>> >> Mono-devel-list mailing list
>> >> Mono-devel-list at lists.ximian.com
>> >> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>> >
>> >
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: log_and_replace.diff
Type: application/octet-stream
Size: 720 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20090211/9f23dcd4/attachment.obj
More information about the Mono-devel-list
mailing list