Re: [Mono-dev] System.PlatformID
Ah. It is my unit test. I have a test that launches installutil. The installutil.exe that comes with the 2.6.7 RPM packages is from the /usr/lib/mono/1.0 (there doesn't seem to be one for 2.0). The running of installutil invokes my Installer class and at that point PlatformID is going to be 128. In that particular case my Installer derived class is standard so it should have no problem running in a 1.x runtime (and it appears to be the case). For the other tests in the suite, PlatformID is 4 as the runtime is 2.0. Thank you. Nicholas -Original Message- From: Kornél Pál [mailto:kornel...@gmail.com] Sent: Tuesday, September 21, 2010 2:00 PM To: Nicholas Salerno Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] System.PlatformID Hi, Try looking at Environment.Version in the prod environment. If you get 1.1.x rather than 2.0.x you know what your problem is. Note that only app.config is able to require a specific runtime version, and there is no such thing as a 3.5 runtime (it's 2.0 with extra assemblies versioned to 3.5.x.x). Kornél Nicholas Salerno wrote: >> It means you're running in the 1.0 profile. If you were running under >> the 2.0 profile, you'd get 4 (PlatformID.Unix). > > If I write a scratch C# program to show the PlatformID I do get 4. However, > in my production build I am getting 128. As far as I know the production > build should be the 2.0 profile, especially since the build scripts > (.proj/.csproj) have some components specifically require 3.5 as the minimum > framework version (the whole project is targeted for the 3.5 framework). If > the production assemblies are running as the 1.0 profile I would think > something would have not worked properly by now. I'm a bit puzzled and will > look into it. > > Thank you for the explanation. > > Nicholas > > -Original Message- > From: Jonathan Pryor [mailto:jonpr...@vt.edu] > Sent: Monday, September 20, 2010 10:24 PM > To: Nicholas Salerno > Cc: mono-devel-list@lists.ximian.com > Subject: Re: [Mono-dev] System.PlatformID > > On Mon, 2010-09-20 at 18:06 -0400, Nicholas Salerno wrote: >> When I query System.Environment.OSVersion.Platform on Linux I get a >> value that will equate to 128. Yet, this is not in the source code >> definition for the PlatformID enum. > > It means you're running in the 1.0 profile. If you were running under > the 2.0 profile, you'd get 4 (PlatformID.Unix). See: > > http://www.mono-project.com/FAQ:_Technical > > Quote: > > The first versions of the framework (1.0 and 1.1) didn't include > any PlatformID value for Unix, so Mono used the value 128. The > newer framework 2.0 added Unix to the PlatformID enum but, > sadly, with a different value: 4 and newer versions of .NET > distinguished between Unix and MacOS X, introducing yet another > value 6 for MacOS X. > >> Question: is 128 supposed to mean Linux? > > It means Unix under the 1.x .NET profile; under the .NET 2.0 profile, > PlatformID.Unix (4) is returned. > >> I am wondering if there is a better way or if this is all that can be done. > > Targeting .NET 2.0+ will help (no 128 value), but only so much (there's > still distinct PlatformID.Unix and PlatformID.MacOSX values), so > preferable (normally) are feature checks, not platform checks. > > Feature checks are also more useful anyway, as a feature may be added in > some version of a platform, and (based on reading years of Dr. GUI > articles in MSDN) platform version detection and handling is HARD. You > would not believe the number of errors applications make doing that... > >> Also, what if Microsoft suddenly came out of nowhere and said that 128 >> will map to AIX? > > I would laugh. A lot. (AIX?! Seriously?) > > The matter still has a theoretical nature, which can be answered thus: > dontworryaboutit. > > More specifically, Mono 2.6 is the last release with 1.x profile > support, and thus is the last version that will return 128 for > PlatformID on Unix platforms. (Plus, most actual apps have been 2.0 > apps for quite some time.). Mono 2.8 is 2.0+ only, and thus will never > return 128. > > Furthermore, 2.6 is only getting bug fixes (if that), not feature fixes, > so even if Microsoft added a new enum value, only mono master will > actually receive the value, not 2.6 (or likely 2.8, at this point). > > Thus, in practice, it's not really worth worrying about. > > - Jon > > > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] System.PlatformID
> It means you're running in the 1.0 profile. If you were running under > the 2.0 profile, you'd get 4 (PlatformID.Unix). If I write a scratch C# program to show the PlatformID I do get 4. However, in my production build I am getting 128. As far as I know the production build should be the 2.0 profile, especially since the build scripts (.proj/.csproj) have some components specifically require 3.5 as the minimum framework version (the whole project is targeted for the 3.5 framework). If the production assemblies are running as the 1.0 profile I would think something would have not worked properly by now. I'm a bit puzzled and will look into it. Thank you for the explanation. Nicholas -Original Message- From: Jonathan Pryor [mailto:jonpr...@vt.edu] Sent: Monday, September 20, 2010 10:24 PM To: Nicholas Salerno Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] System.PlatformID On Mon, 2010-09-20 at 18:06 -0400, Nicholas Salerno wrote: > When I query System.Environment.OSVersion.Platform on Linux I get a > value that will equate to 128. Yet, this is not in the source code > definition for the PlatformID enum. It means you're running in the 1.0 profile. If you were running under the 2.0 profile, you'd get 4 (PlatformID.Unix). See: http://www.mono-project.com/FAQ:_Technical Quote: The first versions of the framework (1.0 and 1.1) didn't include any PlatformID value for Unix, so Mono used the value 128. The newer framework 2.0 added Unix to the PlatformID enum but, sadly, with a different value: 4 and newer versions of .NET distinguished between Unix and MacOS X, introducing yet another value 6 for MacOS X. > Question: is 128 supposed to mean Linux? It means Unix under the 1.x .NET profile; under the .NET 2.0 profile, PlatformID.Unix (4) is returned. > I am wondering if there is a better way or if this is all that can be done. Targeting .NET 2.0+ will help (no 128 value), but only so much (there's still distinct PlatformID.Unix and PlatformID.MacOSX values), so preferable (normally) are feature checks, not platform checks. Feature checks are also more useful anyway, as a feature may be added in some version of a platform, and (based on reading years of Dr. GUI articles in MSDN) platform version detection and handling is HARD. You would not believe the number of errors applications make doing that... > Also, what if Microsoft suddenly came out of nowhere and said that 128 > will map to AIX? I would laugh. A lot. (AIX?! Seriously?) The matter still has a theoretical nature, which can be answered thus: dontworryaboutit. More specifically, Mono 2.6 is the last release with 1.x profile support, and thus is the last version that will return 128 for PlatformID on Unix platforms. (Plus, most actual apps have been 2.0 apps for quite some time.). Mono 2.8 is 2.0+ only, and thus will never return 128. Furthermore, 2.6 is only getting bug fixes (if that), not feature fixes, so even if Microsoft added a new enum value, only mono master will actually receive the value, not 2.6 (or likely 2.8, at this point). Thus, in practice, it's not really worth worrying about. - Jon ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] System.PlatformID
Hello. Looking for some enlightenment on System.PlatformID.
When I query System.Environment.OSVersion.Platform on Linux I get a value that
will equate to 128. Yet, this is not in the source code definition for the
PlatformID enum. I can guess at this part, Mono can't add names to an enum
that Microsoft controls, say if Microsoft decided to extend the enum.
Question: is 128 supposed to mean Linux?
So, I am trying to do a switch on OSVersion.Platform and it is not working.
Looking through the Mono source code I see this piece:
int p = (int) Environment.OSVersion.Platform;
if (p == 4 || p == 128 || p == 6){
I'll do this instead (if that is what it takes, although I will use a constant
for 128 rather than the number itself). I am wondering if there is a better
way or if this is all that can be done.
Also, what if Microsoft suddenly came out of nowhere and said that 128 will map
to AIX? Was 128 chosen because there are far less than a 100 platforms worth
caring about?
Nicholas
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] AssemblyInstaller
Hmm. That is an interesting point. Nicholas -Original Message- From: Vincent Povirk [mailto:madewokh...@gmail.com] Sent: Monday, September 20, 2010 5:40 PM To: Nicholas Salerno Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] AssemblyInstaller I suspect that the Installer class is responsible for chaining the Install, Uninstall, and Commit calls to children. If so, AssemblyInstaller just needs to add all the runnable installers to itself and let Installer do the work of making sure they're invoked. This needs a test case. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] AssemblyInstaller
> So you don't really have to care about the COM visible attribute just > take advantage of it if you want to. OK. Understood. > Mono already has an installutil.exe (I don't know how mutch compatible > it is with that of MS.NET) so the easiest implementation of... Yes, I agree about Mono's installutil.exe, and the first thing I thought to myself was that the implementation should be moved into the System.Configuration.Install namespace. With respect to compatibility with Microsoft's behavior, I have found two bugs in Mono's implementation of installutil: 1) It does not invoke the Installer instances that are contained in the main Installer (the one with the RunInstaller(true) attribute). One can work around this bug by manually invoking the child installers in their respective overridden Installer methods. 2) When you execute "installutil /u MyAssembly.exe" it calls the Install() method. The Uninstall() method is not invoked. However, the OnBeforeUninstall() method is called properly so one can work around this bug by setting a value in the IDictionary parameter. In the Install() method, the first thing you do is check for that value. If it exists then dispatch to the Uninstall() method and return. Else, proceed with your implementation of Install(). Both of these bugs I would like to fix because they really break the "write once, run everwhere" model and I (and company) do not want to maintain two code bases for dealing with Microsoft's way and Mono's way of installers. > If you mean something else on "where implementations should fall into > place" please be more specific. You convinced me that installutil.exe is implemented by using ManagedInstallerClass. We agree on that. What I am still undecided about is if ManagedInstallerClass uses AssemblyInstaller to get some of the work done. Right now both of these classes are not implemented in Mono and I am wondering if the code in installutil.exe is split amongst the two classes. You can have ManagedInstallerClass do all the work, but what if somebody was interested in AssemblyInstaller only to find it is not implemented? According to MSDN AssemblyInstaller "Loads an assembly, and runs all the installers in it." In using it with Microsoft's implementation, AssemblyInstaller handles the child installers contained in the parent installer (bug #1 that wrote about above). Bug #2 that I wrote about above would be a problem in ManagedInstallerClass. To summarize: installutil.exe --uses--> ManagedInstallerClass --uses--> AssemblyInstaller installutil.exe Provides command line user interface for ManagedInstallerClass. ManagedInstallerClass Responsible for instantiating and managing IDictionary parameter for Installer methods. Also responsible for managing the sequence of calls to Installer methods. AssemblyInstaller Responsible for invoking override methods of Installers found in the assembly (based on RunInstaller attribute). In addition, for each installer found in assembly, invoke methods on the instances that exist in the "Installers" property of each installer instance. Yes, no? Nicholas -Original Message- From: Kornél Pál [mailto:kornel...@gmail.com] Sent: Monday, September 20, 2010 3:44 PM To: Nicholas Salerno Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] AssemblyInstaller Hi, A COM visible .NET class is a .NET class. If you use it from .NET you don't see a difference, and there is no difference in the internals eiher. The only difference is that you can access COM visible classes using COM interfaces in unmanaged code. This is very much the same as P/Invoke DLLs/delegates with the additional support for reference counting and this argument. (HRESULT to exception translation is also supported for pure non-OOP functions.) So you don't really have to care about the COM visible attribute just take advantage of it if you want to. Mono already has an installutil.exe (I don't know how mutch compatible it is with that of MS.NET) so the easiest implementation of ManagedInstallerClass.InstallHelper is to move logic except version/copyright header from installutil.exe to ManagedInstallerClass.InstallHelper. installutil.exe should not be just a couple of lines longer than my reference implementation in this thread. If you mean something else on "where implementations should fall into place" please be more specific. Kornél Nicholas Salerno: > Thank you for the clarification. All that said, it still seems like > ManagedInstallerClass.InstallHelper would utilize AssemblyInstaller. > ManagedInstallerClass is COM visible, which may imply some things. > AssemblyInstaller appears to be a plain old .NET class. I don't have any > objection to ManagedInstallerClass, I'm just trying to understand where
Re: [Mono-dev] AssemblyInstaller
Thank you for the clarification. All that said, it still seems like
ManagedInstallerClass.InstallHelper would utilize AssemblyInstaller.
ManagedInstallerClass is COM visible, which may imply some things.
AssemblyInstaller appears to be a plain old .NET class. I don't have any
objection to ManagedInstallerClass, I'm just trying to understand where
implementations should fall into place.
Nicholas
-Original Message-
From: Kornél Pál [mailto:kornel...@gmail.com]
Sent: Saturday, September 18, 2010 5:04 AM
To: Nicholas Salerno
Cc: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] AssemblyInstaller
Hi,
See
http://msdn.microsoft.com/en-us/library/system.configuration.install.managedinstallerclass.installhelper.aspx
That page documents exactly what it does.
installutil.exe should be implemented as sometihng like the following
(I've tried it and it works on MS.NET):
class Program
{
static void Main(string[] args)
{
try
{
ManagedInstallerClass.InstallHelper(args);
}
catch (Exception ex)
{
Console.WriteLine(ex.Message);
}
}
}
Arguments accepted are documented here:
http://msdn.microsoft.com/en-us/library/50614e95.aspx
So all the functionality of installutil.exe should be moved to
ManagedInstallerClass. Even the help screen comes as an exception.
Note that no version headers are not printed by ManagedInstallerClass
that should remain in installutil.exe and some appropriate status code
should be set on return as well.
Based on the following example I belive that
IManagedInstaller.ManagedInstall does exactly the same except that
exceptions are not returned:
class Program
{
static void Main(string[] args)
{
try
{
IManagedInstaller installer = new
ManagedInstallerClass();
StringBuilder sb = new StringBuilder();
foreach (string arg in args)
{
sb.Append('"');
sb.Append(arg.Replace("\\",
"").Replace("\"", "\\\""));
sb.Append("\" ");
}
if (sb.Length > 0)
sb.Remove(sb.Length - 1, 1);
installer.ManagedInstall(sb.ToString(), 0);
}
catch (Exception ex)
{
Console.WriteLine(ex.Message);
}
}
}
A search for hInstall in Platform SDK headers resulted in matches only
from MsiQuery.h. So that method is most likely used by Windows Installer
and I would guess that at least errors are reported using hInstall
rather than exceptions.
Kornél
Nicholas Salerno write:
> Vincent Povirk wrote:
>> I don't know much about these classes, but my impression was that
>> ManagedInstallerClass corresponds most directly to installutil.exe,
>> but that that class must use AssemblyInstaller. It seems installutil
>> duplicates some functionality of both of those, and it should probably
>> call on them instead.
>
> The ManagedInstallerClass is scarcely documented in MSDN (unlike the other
> classes in the System.Configuration.Install namespace). Also, the
> description states that the class is not meant to be directly used by one's
> code. I don't know much about this ManagedInstallerClass other than it
> doesn't seem to fit with the model established by the Installer class. It
> doesn't derive from Installer. It implements IManagedInstaller, an interface
> I don't know much about.
>
> I am familiar with the Installer class that derives from Component and is
> meant to be subclassed. The AssemblyInstaller class seems to be the class to
> use if one wants to programmatically install and uninstall .NET components
> (without having to execute shell commands to instalutil). I do this in
> Windows.
>
> If nobody has any objections I would like to submit a patch that implements
> the AssemblyInstaller class.
>
> Nicholas
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] AssemblyInstaller
Vincent Povirk wrote: > I don't know much about these classes, but my impression was that > ManagedInstallerClass corresponds most directly to installutil.exe, > but that that class must use AssemblyInstaller. It seems installutil > duplicates some functionality of both of those, and it should probably > call on them instead. The ManagedInstallerClass is scarcely documented in MSDN (unlike the other classes in the System.Configuration.Install namespace). Also, the description states that the class is not meant to be directly used by one's code. I don't know much about this ManagedInstallerClass other than it doesn't seem to fit with the model established by the Installer class. It doesn't derive from Installer. It implements IManagedInstaller, an interface I don't know much about. I am familiar with the Installer class that derives from Component and is meant to be subclassed. The AssemblyInstaller class seems to be the class to use if one wants to programmatically install and uninstall .NET components (without having to execute shell commands to instalutil). I do this in Windows. If nobody has any objections I would like to submit a patch that implements the AssemblyInstaller class. Nicholas -Original Message- From: Vincent Povirk [mailto:madewokh...@gmail.com] Sent: Friday, September 17, 2010 10:41 PM To: Nicholas Salerno Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] AssemblyInstaller I don't know much about these classes, but my impression was that ManagedInstallerClass corresponds most directly to installutil.exe, but that that class must use AssemblyInstaller. It seems installutil duplicates some functionality of both of those, and it should probably call on them instead. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] AssemblyInstaller
The class System.Configuration.Installer.AssemblyInstaller is currently not implemented (all it does it just call the parent method in the override). However, there does exist an implementation of installutil.exe in Mono. I have noticed with Microsoft's framework that AssemblyInstaller does what installutil.exe does. I get the impression that installutil.exe is just a console application wrapper of AssemblyInstaller. Would it make sense for Mono's implementation of installutil to be used as the implementation of AssemblyInstaller? Nicholas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] XBuild colors
I am using a bash script to make xbuild easier to use (it handles passing all the command line arguments). At the top of the script I have the following: # Using different colors just to prove a point export XBUILD_COLORS XBUILD_COLORS=errors=blue,warnings=green,events=red When I run xbuild I definitely see errors and events change colors. But warnings are always the console's foreground color. This happens in both gnome-terminal and xterm. Hmmm. When I create a scratch program to test my claim I see that the warnings are being colored. I can't imagine the difference between a simple program and the production scripts. Admittedly, we have build files that invoke other build files, shell scripts invoking shell scripts, and all of that mixed and matched. However, I placed the XBUILD_COLORS environment variable in every shell script used just to ensure that the value exists and is set. Again, I can see errors and events being colored but warnings are the console's foreground color. I'll have to experiment more at some point (it's not high priority, but I do like using colors to my advantage). Nicholas -Original Message- From: Ankit Jain [mailto:radi...@gmail.com] Sent: Tuesday, September 07, 2010 6:19 PM To: Nicholas Salerno Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] XBuild colors What are you setting XBUILD_COLORS to? It works for me (2.6.7 on opensuse 11.2). What terminal are you trying this in? -Ankit On Wed, Sep 8, 2010 at 2:52 AM, Nicholas Salerno wrote: > Has anyone noticed that XBuild warnings are not being colored? Or is it > just my setup (Mono 2.6.7 on openSUSE 11.2)? If I change the colors via the > XBUILD_COLORS shell variable I can see the colors change for errors and > events, but warnings appear unaffected. They still remain the default > terminal color (gray, in my case). > > > > Nicholas > > > > ___ > Mono-devel-list mailing list > Mono-devel-list@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@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] XBuild colors
Has anyone noticed that XBuild warnings are not being colored? Or is it just my setup (Mono 2.6.7 on openSUSE 11.2)? If I change the colors via the XBUILD_COLORS shell variable I can see the colors change for errors and events, but warnings appear unaffected. They still remain the default terminal color (gray, in my case). Nicholas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] xbuild and a solution containing a vcxproj
Thank you for the prompt response. The $(OS) check will do for now (I use that
for other things as well just to get the build up and running, then I figure
out how to get rid of it). Thanks again.
Nicholas
-Original Message-
From: Ankit Jain [mailto:radi...@gmail.com]
Sent: Friday, August 13, 2010 12:30 PM
To: Nicholas Salerno
Cc: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] xbuild and a solution containing a vcxproj
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.
-
{5478C86B-37B1-4116-80EB-CE8DDB6F71BA}
MyLibrary3
--
-Ankit
On Fri, Aug 13, 2010 at 7:02 PM, Nicholas Salerno
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:radi...@gmail.com]
> Sent: Friday, August 13, 2010 7:34 AM
> To: Nicholas Salerno
> Cc: mono-devel-list@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
> 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 element. This element contains a GUID (via
>> the 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) [0x0] in
>> :0
>> at System.String.FormatHelper (System.Text.StringBuilder result,
>> IForma
Re: [Mono-dev] xbuild and a solution containing a vcxproj
(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:radi...@gmail.com] Sent: Friday, August 13, 2010 7:34 AM To: Nicholas Salerno Cc: mono-devel-list@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 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 element. This element contains a GUID (via the > 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) [0x0] in > :0 > at System.String.FormatHelper (System.Text.StringBuilder result, > IFormatProvider provider, System.String format, System.Object[] args) > [0x0] in :0 > at System.String.Format (IFormatProvider provider, System.String > format, System.Object[] args) [0x0] in :0 > at System.String.Format (System.String format, System.Object[] args) > [0x0] in :0 > at Microsoft.Build.BuildEngine.Project.LogWarning (System.String > filename, System.String message, System.Object[] messageArgs) > [0x0] in :0 > at Microsoft.Build.BuildEngine.Project+c__AnonStorey10.<>m__1 > (Int32 errorNumber, System.String message) [0x0] in unknown>:0 > at Mono.XBuild.CommandLine.SolutionParser.ParseSolution > (System.String file, Microsoft.Build.BuildEngine.Project p, > Mono.XBuild.CommandLine.RaiseWarningHandler RaiseWarning) [0x0] in > :0 > at Microsoft.Build.BuildEngine.Project.Load (System.String > projectFileName, ProjectLoadSettings settings) [0x0] in unknown>:0 > at Microsoft.Build.BuildEngine.Project.Load (System.String > projectFileName) [0x0] in :0 > at Mono.XBuild.CommandLine.MainClass.Execute () [0x0] in > :0 > > So, what project am I missing? What ty
[Mono-dev] xbuild and a solution containing a vcxproj
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 element. This element contains a GUID (via the 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) [0x0] in :0 at System.String.FormatHelper (System.Text.StringBuilder result, IFormatProvider provider, System.String format, System.Object[] args) [0x0] in :0 at System.String.Format (IFormatProvider provider, System.String format, System.Object[] args) [0x0] in :0 at System.String.Format (System.String format, System.Object[] args) [0x0] in :0 at Microsoft.Build.BuildEngine.Project.LogWarning (System.String filename, System.String message, System.Object[] messageArgs) [0x0] in :0 at Microsoft.Build.BuildEngine.Project+c__AnonStorey10.<>m__1 (Int32 errorNumber, System.String message) [0x0] in :0 at Mono.XBuild.CommandLine.SolutionParser.ParseSolution (System.String file, Microsoft.Build.BuildEngine.Project p, Mono.XBuild.CommandLine.RaiseWarningHandler RaiseWarning) [0x0] in :0 at Microsoft.Build.BuildEngine.Project.Load (System.String projectFileName, ProjectLoadSettings settings) [0x0] in :0 at Microsoft.Build.BuildEngine.Project.Load (System.String projectFileName) [0x0] in :0 at Mono.XBuild.CommandLine.MainClass.Execute () [0x0] in :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@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
