[Mono-dev] xbuild and a solution containing a vcxproj

Ankit Jain radical at gmail.com
Fri Aug 13 12:29:34 EDT 2010 

Thanks for the test projects. This is fixed in master now.
For 2.6.7, you can use this *workaround* -
Add a condition on the ProjectReference for the vc*proj, either use
the $(OS) check or use
$(Configuration)  != Mono .
Eg.
---------
    <ProjectReference Include="..\MyLibrary3\MyLibrary3.vcxproj"
Condition="'$(OS)' != 'Unix'">
      <Project>{5478C86B-37B1-4116-80EB-CE8DDB6F71BA}</Project>
      <Name>MyLibrary3</Name>
    </ProjectReference>
----------

-Ankit

On Fri, Aug 13, 2010 at 7:02 PM, Nicholas Salerno
<nsalerno at securewatch24.com> wrote:
> (Meant to CC the reply to the mailing list)
>
> Nicholas
>
> -----Original Message-----
> From: Nicholas Salerno
> Sent: Friday, August 13, 2010 9:25 AM
> To: 'Ankit Jain'
> Subject: RE: [Mono-dev] xbuild and a solution containing a vcxproj
>
> Hello Ankit.  I have made a small scratch solution that reproduces this problem (I'm not at liberty to send the real solution file).  The solution file is attached along with the output of xbuild trying to build the solution (with MONO_OPTIONS=--debug and /v:diag).  If you want I can send the solution directory zipped up (it's tiny), but for the most part you can create a stock C# console app and libraries and a stock C++/CLI library for the attached solution file.
>
> In the solution file are four projects, two of which will build (MyApplication and MyLibrary1).  The other two (MyLibrary2 and MyLibrary3) will not build as they are not enabled for the platform configuration.  MyApplication (C# console application) depends on MyLibrary1 (C# library).  MyLibrary2 (C# library) depends on MyLibrary3 (C++/CLI library.
>
> In my scratch solution the library has a class with a public method that writes something to the console.  The application uses the library class from its static Main method.  Likewise, the other libraries also contain a class that has a simple public method that writes something to the console.
>
> Build the solution with xbuild.  You will see xbuild ignore MyLibrary3 and throw the System.FormatException for MyLibrary2.  Open up the MyLibrary2 csproj file and comment/delete the project reference for MyLibrary3.  Save the file and run xbuild again.  This time the build succeeds (we get assemblies for MyApplication and MyLibrary1).
>
> Hope this helps.
>
> Nicholas
>
> -----Original Message-----
> From: Ankit Jain [mailto:radical at gmail.com]
> Sent: Friday, August 13, 2010 7:34 AM
> To: Nicholas Salerno
> Cc: mono-devel-list at lists.ximian.com
> Subject: Re: [Mono-dev] xbuild and a solution containing a vcxproj
>
> Hi,
>
> Could you please run xbuild with "/v:diag" and with env var MONO_OPTIONS=--debug set, and attach the log.
> Also, could you attach the .sln file also?
>
> -Ankit
>
> On Fri, Aug 13, 2010 at 5:40 AM, Nicholas Salerno <nsalerno at securewatch24.com> wrote:
>> Hello.  I have an existing Visual Studio solution (VS 2010) file that I am porting to Mono.  The whole solution does not have to build in Mono and I don't want to maintain two different build files.  I have two platform configurations in the solution.  The Win32 platform will build everything and the Mono platform will only build select projects.  So far so good.
>>
>> I started this effort when Mono 2.6.4 was the latest release.  Since then I have upgraded to 2.6.7 because the 2.6.4 runtime would crash (SIGSEGV) when executing the code I ported to Mono.  So far so good (the assemblies execute properly with the 2.6.7 runtime).  I have a problem with the 2.6.7 xbuild where it is throwing a runtime exception of type System.FormatException.  This happens because a project in the solution has a reference to another project that does not exist in the solution.  Specifically, a csproj file contains a <ProjectReference> element.  This element contains a GUID (via the <Project> child element) and this GUID does not exist in the solution file.  Here is the stack trace from the build:
>>
>> Unhandled Exception: System.FormatException: Input string was not in a correct format.
>>  at System.String.ParseFormatSpecifier (System.String str,
>> System.Int32& ptr, System.Int32& n, System.Int32& width,
>> System.Boolean& left_align, System.String& format) [0x00000] in
>> <filename unknown>:0
>>  at System.String.FormatHelper (System.Text.StringBuilder result,
>> IFormatProvider provider, System.String format, System.Object[] args)
>> [0x00000] in <filename unknown>:0
>>  at System.String.Format (IFormatProvider provider, System.String
>> format, System.Object[] args) [0x00000] in <filename unknown>:0
>>  at System.String.Format (System.String format, System.Object[] args)
>> [0x00000] in <filename unknown>:0
>>  at Microsoft.Build.BuildEngine.Project.LogWarning (System.String
>> filename, System.String message, System.Object[] messageArgs)
>> [0x00000] in <filename unknown>:0
>>  at Microsoft.Build.BuildEngine.Project+<Load>c__AnonStorey10.<>m__1
>> (Int32 errorNumber, System.String message) [0x00000] in <filename
>> unknown>:0
>>  at Mono.XBuild.CommandLine.SolutionParser.ParseSolution
>> (System.String file, Microsoft.Build.BuildEngine.Project p,
>> Mono.XBuild.CommandLine.RaiseWarningHandler RaiseWarning) [0x00000] in
>> <filename unknown>:0
>>  at Microsoft.Build.BuildEngine.Project.Load (System.String
>> projectFileName, ProjectLoadSettings settings) [0x00000] in <filename
>> unknown>:0
>>  at Microsoft.Build.BuildEngine.Project.Load (System.String
>> projectFileName) [0x00000] in <filename unknown>:0
>>  at Mono.XBuild.CommandLine.MainClass.Execute () [0x00000] in
>> <filename unknown>:0
>>
>> So, what project am I missing?  What typo may exist?  Well, I have found that my solution contains a single C++/CLI project (vcxproj).  The output of xbuild shows the project being ignored (warning : Ignoring vcproj 'Data.Manager').  What happens then is that a few C# projects have a reference to this project and xbuild throws the System.FormatException object, which I have come to interpret as "hey, you say A depends on B but B doesn't exist in the solution."  This seems like a bug because even if xbuild wants nothing to do with the vcxproj (and that is fine) it should still be aware of its existence (via the project's GUID that it has read).  This behavior does not happen with the 2.6.4 xbuild.  Note that I am not trying to build these particular projects in Mono and they are not enabled in the "Mono" platform configuration of my solution.
>>
>> I have noticed similar warnings in the 2.6.4 version of xbuild.  However, this did not stop the build nor throw exceptions.  I was able to build my selected projects with 2.6.4 and now I cannot build anything in 2.6.7 because of the thrown exception.  Right now I have a complete 2.6.4 system with a 2.6.7 CLR and C# compiler dropped in place.  I imagine there are consequences with that setup and would like to use a homogenous 2.6.7 installation.  Is there anything I can do to work around this?  Would it be safer to drop a 2.6.4 xbuild (and its version of MSBuild target files) in a complete 2.6.7 installation?
>>
>> I am running openSUSE 11.2 and have installed Mono from RPM packages.  Thanks.
>>
>> Nicholas
>>
>> _______________________________________________
>> Mono-devel-list mailing list
>> Mono-devel-list at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>
>
>
>
> --
> 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
>
>



-- 
Blog : http://www.ankitjain.org/blog

More information about the Mono-devel-list mailing list