Re: [Mono-dev] [Patch] xbuild, ResXFileRef and relative windows paths
On Sun, Mar 22, 2009 at 12:24 PM, Leszek Ciesielski skol...@gmail.com wrote: I agree with Gert, either xbuild has to restrict the path separator substitution to cases where a file before substitution can not be found and after substitution it is found, or, IMHO a better solution, xbuild wrapper script (i.e. the /usr/bin/xbuild itself) should set MONO_IOMAP before exec'ing mono instead of replicating such hacks across multiple Microsoft.Build.* classes. Bear in mind that custom (user-provided) tasks will most likely exhibit this problem as well. On Sun, Mar 22, 2009 at 8:48 AM, Gert Driesen gert.drie...@telenet.be wrote: Daniel, I'm ok with the change, but why not just use MONO_IOMAP? Will you only replace the Windows directory separator if the file could not be found? We should continue to support backslashes in unix paths. When we start adding such compatibility hacks in multiple class libraries / tools, then it may be a good time to reconsider implementing it in the runtime. Microsoft.Build.* classes might be used from applications like MonoDevelop, not just xbuild.exe. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] xBuild - metadata in conditions
On 6/19/07, Michael CATANZARITI [EMAIL PROTECTED] wrote: Hi, I would like to implement metadata in conditions in xBuild. For instance : ?xml version=1.0 encoding=utf-8? PropertyGroup copygroupA/copygroup /PropertyGroup ItemGroup myfiles Include=C:\test1.txt groupA/group /myfiles myfiles Include=C:\test3.txt groupB/group /myfiles myfiles Include=C:\test3.txt groupA/group /myfiles /ItemGroup Target Name=copyfiles Copy Condition='%(group)'=='$(copygroup)' SourceFiles=@(myfiles) DestinationFolder=C:\Temp SkipUnchangedFiles=true / /Target /Project Has someone already begun working on this feature ? Or at least has a design idea ? Thank you, Michaël I don't think that anyone started work on this. There is specification on msbuild wiki (channel9 - msbuild) ComplexConditionSpecification. It will require quite a lot of work (it may be needed to rewrite/refactor most of the code that parses expressions in xml attributes) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] AssemblyName.ctor () can't parse ProcessorArchitecture.
I know that AssemblyName.ProcessorArchitecture isn't used in Mono but
I'm using AssemblyName.ctor in xbuild (to build AssemblyName from
string) and current version throws exception when it sees
ProcessorArchitecture=something.
Here's a patch that makes it assign correct values to new field in
MonoAssemblyName.
--
Marek Sieradzki [EMAIL PROTECTED]
Index: mono/metadata/assembly.c
===
--- mono/metadata/assembly.c (wersja 76761)
+++ mono/metadata/assembly.c (kopia robocza)
@@ -1618,7 +1618,7 @@
}
static gboolean
-build_assembly_name (const char *name, const char *version, const char *culture, const char *token, const char *key, MonoAssemblyName *aname, gboolean save_public_key)
+build_assembly_name (const char *name, const char *version, const char *culture, const char *token, const char *key, const char* cpu_arch, MonoAssemblyName *aname, gboolean save_public_key)
{
gint major, minor, build, revision;
gint len;
@@ -1681,6 +1681,18 @@
g_free (pkey);
}
+ if (cpu_arch) {
+ if (g_ascii_strcasecmp (cpu_arch, MSIL) == 0)
+ aname-processor_architecture = 1;
+ else if (g_ascii_strcasecmp (cpu_arch, X86) == 0)
+ aname-processor_architecture = 2;
+ else if (g_ascii_strcasecmp (cpu_arch, IA64) == 0)
+ aname-processor_architecture = 3;
+ else if (g_ascii_strcasecmp (cpu_arch, Amd64) == 0)
+ aname-processor_architecture = 4;
+ else
+ return FALSE;
+ }
return TRUE;
}
@@ -1696,7 +1708,7 @@
return FALSE;
}
- res = build_assembly_name (name, parts[0], parts[1], parts[2], NULL, aname, FALSE);
+ res = build_assembly_name (name, parts[0], parts[1], parts[2], NULL, NULL, aname, FALSE);
g_strfreev (parts);
return res;
}
@@ -1709,6 +1721,7 @@
gchar *culture = NULL;
gchar *token = NULL;
gchar *key = NULL;
+ gchar *cpu_arch = NULL;
gboolean res;
gchar *value;
gchar **parts;
@@ -1755,12 +1768,18 @@
tmp++;
continue;
}
+
+ if (!g_ascii_strncasecmp (value, ProcessorArchitecture=, 22)) {
+ cpu_arch = g_strstrip (value + 22);
+ tmp++;
+ continue;
+ }
g_strfreev (parts);
return FALSE;
}
- res = build_assembly_name (dllname, version, culture, token, key, aname, save_public_key);
+ res = build_assembly_name (dllname, version, culture, token, key, cpu_arch, aname, save_public_key);
g_strfreev (parts);
return res;
}
Index: mono/metadata/image.h
===
--- mono/metadata/image.h (wersja 76761)
+++ mono/metadata/image.h (kopia robocza)
@@ -23,6 +23,7 @@
guint32 hash_len;
guint32 flags;
guint16 major, minor, build, revision;
+ guint32 processor_architecture;
} MonoAssemblyName;
typedef enum {
Index: mono/metadata/object-internals.h
===
--- mono/metadata/object-internals.h (wersja 76761)
+++ mono/metadata/object-internals.h (kopia robocza)
@@ -946,6 +946,7 @@
MonoArray *keyToken;
guint32 versioncompat;
MonoObject *version;
+ guint32 processor_architecture;
} MonoReflectionAssemblyName;
typedef struct {
Index: mono/metadata/icall.c
===
--- mono/metadata/icall.c (wersja 76761)
+++ mono/metadata/icall.c (kopia robocza)
@@ -4502,6 +4502,8 @@
p++;
}
}
+
+ aname-processor_architecture = name-processor_architecture;
}
static void
Index: class/corlib/Test/System.Reflection/AssemblyNameTest.cs
===
--- class/corlib/Test/System.Reflection/AssemblyNameTest.cs (wersja 76761)
+++ class/corlib/Test/System.Reflection/AssemblyNameTest.cs (kopia robocza)
@@ -748,6 +748,22 @@
Assert.IsNull (an, Ctor6#9);
}
+ [Test]
+ public void TestProcessorArchitecture ()
+ {
+ AssemblyName a1 = new AssemblyName (test, processorArchitecture=MSIL);
+ AssemblyName a2 = new AssemblyName (test, processorArchitecture=msil);
+ AssemblyName a3 = new AssemblyName (test, processorArchitecture=X86);
+ AssemblyName a4 = new AssemblyName (test, processorArchitecture=IA64);
+ AssemblyName a5 = new AssemblyName (test, processorArchitecture=Amd64);
+
+ Assert.AreEqual (ProcessorArchitecture.MSIL, a1.ProcessorArchitecture, ProcessorArchitecture#1);
+ Assert.AreEqual (ProcessorArchitecture.MSIL, a2.ProcessorArchitecture, ProcessorArchitecture#2);
+ Assert.AreEqual (ProcessorArchitecture.X86, a3.ProcessorArchitecture, ProcessorArchitecture#3);
+ Assert.AreEqual (ProcessorArchitecture.IA64, a4.ProcessorArchitecture, ProcessorArchitecture#4);
+ Assert.AreEqual (ProcessorArchitecture.Amd64, a5.ProcessorArchitecture, ProcessorArchitecture#5);
+ }
+
#endif
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Wrong logs from make run-test-ondotnet
This patch fixes it. make.patch Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Winforms breakages under 1.2.3
On nie, 2007-01-28 at 23:58 +, Paul wrote: Hi, I have an application built under VS.NET which runs fine. The code is supported happily in Mono (there is nothing in it which causes it to bork on compiling) I've hit the following problems (Under both Linux and Win32) Number 1 - password properties. === password properties on a text box are broken. I have the following code this.tb_password.Enabled = false; // set up the name and position this.tb_password.PasswordChar = (char)'*'; Under 1.2.2, this would result in the tb_password textbox having all *'s inside, under 1.2.3, it's plain text. Number 2. Resources problems Images set using global::progname.Properties.Resources.filename are not being recognised under 1.2.3 - not sure if they are under 1.2.2 (not tested this sort of code before). Works fine under VS.NET. I think that you're using VS generated wrapper class that is accessing resources files. Could you make a simple project that only uses resources that way and attach it? -- Marek Sieradzki [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Need your help: Mainsoft/Novell Race to Linux
On sob, 2007-01-27 at 14:49 +0200, sasha wrote: I think it would be very nice to port SharpDevelop 2.1 on mono :-) No, it wouldn't be nice because SharpDevelop was written as Windows program. You would need to rewrite really big part part of code. Maybe when SharpDevelop will more portable. -- Marek Sieradzki [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] [Mono-dev] Need your help: Mainsoft/Novell Race to Linux
On sob, 2007-01-27 at 14:49 +0200, sasha wrote: I think it would be very nice to port SharpDevelop 2.1 on mono :-) No, it wouldn't be nice because SharpDevelop was written as Windows program. You would need to rewrite really big part part of code. Maybe when SharpDevelop will more portable. -- Marek Sieradzki [EMAIL PROTECTED] ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] compiling VS2005 project in mono
On 1/26/07, Andrés G. Aragoneses [ knocte ] [EMAIL PROTECTED] wrote: Andrus escribió: I need to compile Visual C# Express 2005 project in MONO in Windows but prj2make does not support VS2005 projects. You're wrong; prj2make has been hacked recently to add that support. If you use the SVN version of MonoDevelop you should be able to open your project with it. You're wrong, MSBuild(VS2005) support is in Extras/prj2make in monodevelop but it doesn't have anything common except directory and .addin file. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-dev] corlib tests broken under net_2_0 profile
Hi, as you can see here: http://pastebin.ca/288704 and in mono.ximian.com/monobuild - x86 - latest build - test_profiles Mono writes some weird warnings and fails 2-4 tests in corlib. I'm not sure when it started to happen. I ran those tests on r69950. -- Marek Sieradzki [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] NET_2_0 class status not available
On wto, 2006-12-12 at 13:18 +0100, Kornél Pál wrote: Hi, BTW is the buildbot page (http://mono.ximian.com:8008/) retired? Yes, but there are some old links left on Wiki. New address is http://mono.ximian.com/monobuild/ -- Marek Sieradzki [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] class status 2.0
On 11/14/06, Matthijs ter Woord [EMAIL PROTECTED] wrote: Are there plans to update the class status data files to the .NET 2.0 RTM assemblies? They are already .NET 2.0 RTM. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] running two different versions on mono on one box?
On 10/25/06, ted leslie [EMAIL PROTECTED] wrote: I have a need to keep one particular older version of mono on computer, because it's included in a system that I have deployed and need to support, and it not convenient to upgrade those environments at this time, but yet still update applications written against that older version of mono. But, I'd like to run the newest stable version too on my machine. Write now i do this by having a script, a pre-script/post-script that moves the mono binary, libs and /etc/mono to the version I want, runs the program, and then changes it back. There must be an easier way? to selectively run a mono app against a particular mono version, and do so with different versions on the same machine? I am thinking there is a set of environment variables? I can dig on it, but figuring someone can probably post there sol'n in 2 seconds. http://www.mono-project.com/Parallel_Mono_Environments ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] Microsoft.Build.* API fixes
On 10/20/06, Leszek Ciesielski [EMAIL PROTECTED] wrote: On 10/20/06, Marek Sieradzki [EMAIL PROTECTED] wrote: On 10/20/06, Leszek Ciesielski [EMAIL PROTECTED] wrote: On 10/20/06, Marek Sieradzki [EMAIL PROTECTED] wrote: On 10/20/06, Leszek Ciesielski [EMAIL PROTECTED] wrote: Hi, attached is a patch fixing minor attribute differences between mono and ms.net, and containing stubs for (some of) missing classes. Permission to commit? Hi, AssemblyInfo.cs changes are questionable. If there's a good reason for them please specify it. Those attributes are present in MS.Net assembly ( consult eg. mono class status). Other that that - none, I dubt mono supports them at this time (meaning pays any heed to them, I know compiler generates them properly). It's just a small increase in compatibility, when I could see no problems on our side. I do not want to argue, but if you are against applying them, please specify a reason :-) I asked Miguel some time ago about that. Mono is based on msdn + ecma docs. If specific attribute isn't obvious/needed nor documented it shouldn't be added. Or at least it's the way I understood it. Patch with the class stubs again. This time without changes to assembly attributes and with correct (consistent with module style) formatting. Also, this one contains two more stubs. Permission to commit? Yes. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] Trouble when generating the doc
On 10/21/06, xiii29 [EMAIL PROTECTED] wrote: Hi, I'm trying to generate doc from my source code. ... For info, my project is compiled in 2.0. You need to recompile monodocer/(whatever tool you use) with gmcs. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-dev] Microsoft.Build.* API fixes
On 10/20/06, Leszek Ciesielski [EMAIL PROTECTED] wrote: Hi, attached is a patch fixing minor attribute differences between mono and ms.net, and containing stubs for (some of) missing classes. Permission to commit? Hi, AssemblyInfo.cs changes are questionable. If there's a good reason for them please specify it. Small coding style glitch. You are using F() instead of F () VCBuild is a class that rather won't be implemented. In MSBuild it executes VS C++ build (that uses different format of project files). It is possible that someone can use gcc/g++ for that but generally I'm not sure if anyone will use it. Anyway monotodo + notimplementedexception stub can be added. Vbc task should be quite easy to write when we'll have it working on Mono. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] DebuggingAttribute and ComVisibleAttribute
On 10/19/06, Leszek Ciesielski [EMAIL PROTECTED] wrote: Hi, attached is a small patch which makes those two attributes compatible with net 1.1 and net 2.0. Permission to commit? Another thing: are such small incompatibilities intentional, or is this just a mistake? Should I commit more of such 'API - compatibility' fixes? There are people who know more than me but: probably those incompatibilities should be fixed but no-one had time to do that. BTW your code doesn't follow coding guidelines. (ComVisible.cs already has weird casing for Visible (private field)). ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Microsoft.Build.* API fixes
On 10/20/06, Leszek Ciesielski [EMAIL PROTECTED] wrote: On 10/20/06, Marek Sieradzki [EMAIL PROTECTED] wrote: On 10/20/06, Leszek Ciesielski [EMAIL PROTECTED] wrote: Hi, attached is a patch fixing minor attribute differences between mono and ms.net, and containing stubs for (some of) missing classes. Permission to commit? Hi, AssemblyInfo.cs changes are questionable. If there's a good reason for them please specify it. Those attributes are present in MS.Net assembly ( consult eg. mono class status). Other that that - none, I dubt mono supports them at this time (meaning pays any heed to them, I know compiler generates them properly). It's just a small increase in compatibility, when I could see no problems on our side. I do not want to argue, but if you are against applying them, please specify a reason :-) I asked Miguel some time ago about that. Mono is based on msdn + ecma docs. If specific attribute isn't obvious/needed nor documented it shouldn't be added. Or at least it's the way I understood it. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] We broke nant... again.
On 10/19/06, Leszek Ciesielski [EMAIL PROTECTED] wrote: Hi, on 14th of October a new nant version was released, fixing some bugs that were encountered when running on mono 1.1.17. On 16th mono 1.1.18 was released, breaking nant - again. It is able to compile itself, but falls into an endless loop (seemingly in mono XML parser) when being run on more complex build files, with many 'include's and complex 'depends' attributes. Just downgrade mono until nant is fixed. I am thinking (again) about dumping nant completely and switching to (ms/x)build. But as I tried to build a simple VS2005 project today I run into several problems. First: xbuild does not seem to support .sln files at all. This can be worked around by generating a .proj file from .sln in msbuid, or , for single-project solutions, using just the project file. MS is autogenerating a .csproj file from .sln just before the build. It's a simple target that uses MSBuild task. It can done the same way in xbuild. What you also need are working cross project references. It's still not working in xbuild. Second: xbuild does not know the implicit targets defined in msbuild, like Rebuild or Clean (and probably others). Someone should write them and test them. Third: xbuild does not work on windows. Well, it runs, but cannot compile anything. This is because to bug 79263 ( http://bugzilla.ximian.com/show_bug.cgi?id=79263 ). It won't change soon. Until it's fixed you can use msbuild. While first and third problems are not critical, the second one is... Anyone knows a solution (besides downgrading to mono 1.1.17) ? Beside that my computer is temporarily broken (happening quite often to me) xbuild needs more work in the core. MSBuild consists of: framework + engine + common files + user projects. At the moment core (Microsoft.Build.Engine) needs more NUnit tests. When something goes wrong (anywhere from the components list) new users don't have patience to fix the bugs. Also I don't have a lot of time recently. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Documentation synchronization
On 9/15/06, Jacob Ilsø Christensen [EMAIL PROTECTED] wrote: Hi. On 9/15/06, Michael Schurter [EMAIL PROTECTED] wrote: Hi Jacob, Jacob Ilsø Christensen wrote: Hi again. Just out of curiosity. Why was this documentation approach chosen as opposed to e.g. source code doc comments? A big advantage of source code doc comments is that they are available as you do the actual coding. With the current approach you have to look in a separate xml file to see documentation for a specific class or method or did I miss out on something? If I remember correctly its to make translation easier. Please don't top post. So code documentation is actually translated in mono? No but there is en folder. It doesn't make any sense to me to translate mono documentation to other languages as the English version is not complete. But if someone wants to do it's possible. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Sharing build specs between MS VS .net 2005 and monoon Linux
On 9/15/06, Michael Jerris [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] [mailto:mono-devel-list- [EMAIL PROTECTED] On Behalf Of Mads Bondo Dydensborg Sent: Friday, September 15, 2006 11:13 AM To: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Sharing build specs between MS VS .net 2005 and monoon Linux Optimally, xbuild would support new msbuild format files, and switching between mono and ms.net would be a complete no brainer :-) Yes, this would be ideel. I am not a big MS fan myself, but it seems that MSBuild is a sensible system (inspired by nant, apparently). Having a compatible crossplatform tool for mono would appear to be a good thing. Especially since this would allow the Windows developers to remain in Visual Studio all the time, which appears to be a high priority for them... Another interesting tool to look at would be bakefile. I don't believe it has mono support at this point, but it seems to be approaching the same sort's of issues, and already has quite a bit of support for visual studio and makefiles and several other output types. I like their approach. This is the build tool being developed for WxWidgets. NAnt should be used until xbuild is usable. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Case sensitivity and xbuild
Hi, Some IDEs when making a new project add a reference to Microsoft.CSharp.targets and some to Microsoft.CSharp.Targets. Of course under Linux you need to convert the name or install both files. In mcs/tools/xbuild/Makefile there's already line that installs Microsoft.CSharp.targets. What should I add/change to install the file with another name without having to keep 2 files in svn? (I think that it would create some problems under Windows then) Copying A to B and installing B as it was done with A looks like a best thing to do. -- Marek Sieradzki [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Prj2make
Hi. I wanted to make some changes in MonoDevelop's prj2make but I saw that prj2make is also in Mono. Code is a bit different (one file more in mono). Shouldn't the part that can be put into library be a library (Mono.Prj2make)? I think that I want to be mantainer of prj2make. -- Marek Sieradzki [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Compile mono in FC5
On pią, 2006-07-21 at 10:08 +0800, ZhangZQ wrote: Hi, I checkout the source from SVN and compile it under FC5 with gcc-4.1.1-1, and I installed the mono 1.1.13.7 that come with FC5. I used this command to build mono 'make get-monolite-latest;make EXTERNAL_MCS=false' to build mono, but got the error, Making all in net_2_0 make[3]: Entering directory `/home/zzq01/source/mono/mono/data/net_2_0' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/home/zzq01/source/mono/mono/data/net_2_0' make[3]: Entering directory `/home/zzq01/source/mono/mono/data' make[3]: Nothing to be done for `all-am'. make[3]: Leaving directory `/home/zzq01/source/mono/mono/data' make[2]: Leaving directory `/home/zzq01/source/mono/mono/data' Making all in runtime make[2]: Entering directory `/home/zzq01/source/mono/mono/runtime' if test -w ../../mcs; then :; else chmod -R +w ../../mcs; fi cd ../../mcs make PROFILES='default net_2_0' CC='gcc' all-profiles make[3]: Entering directory `/home/zzq01/source/mono/mcs' make profile-do--default--all profile-do--net_2_0--all make[4]: Entering directory `/home/zzq01/source/mono/mcs' make PROFILE=basic all make[5]: Entering directory `/home/zzq01/source/mono/mcs' make[6]: *** [build/deps/basic-profile-check.exe] Error 1 make[6]: Entering directory `/home/zzq01/source/mono/mcs' *** The compiler 'false' doesn't appear to be usable. *** Trying the 'monolite' directory. make[7]: Entering directory `/home/zzq01/source/mono/mcs' mono: mono-codeman.c:257: new_codechunk: Assertion `!err' failed. make[8]: *** [build/deps/basic-profile-check.exe] Aborted make[8]: Entering directory `/home/zzq01/source/mono/mcs' *** The contents of your 'monolite' directory may be out-of-date *** You may want to try 'make get-monolite-latest' make[8]: *** [do-profile-check-monolite] Error 1 make[8]: Leaving directory `/home/zzq01/source/mono/mcs' make[7]: *** [do-profile-check] Error 2 make[7]: Leaving directory `/home/zzq01/source/mono/mcs' make[6]: *** [do-profile-check-monolite] Error 2 make[6]: Leaving directory `/home/zzq01/source/mono/mcs' make[5]: *** [do-profile-check] Error 2 make[5]: Leaving directory `/home/zzq01/source/mono/mcs' make[4]: *** [profile-do--basic--all] Error 2 make[4]: Leaving directory `/home/zzq01/source/mono/mcs' make[3]: *** [profiles-do--all] Error 2 make[3]: Leaving directory `/home/zzq01/source/mono/mcs' make[2]: *** [all-local] Error 2 make[2]: Leaving directory `/home/zzq01/source/mono/mono/runtime' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/zzq01/source/mono/mono' make: *** [all] Error 2 then I used 'make' to build again, still got the error make all-local make[8]: Entering directory `/home/zzq01/source/mono/mcs/class/System' ** Warning: System.dll built without parts that depend on: System.Xml.dll make[8]: Leaving directory `/home/zzq01/source/mono/mcs/class/System' make[7]: Leaving directory `/home/zzq01/source/mono/mcs/class/System' make[7]: Entering directory `/home/zzq01/source/mono/mcs/class/System.XML' make all-local make[8]: Entering directory `/home/zzq01/source/mono/mcs/class/System.XML' MONO_PATH=../../class/lib/basic:$MONO_PATH /home/zzq01/source/mono/mono/runtime/mono-wrapper ../../class/lib/basic/mcs.exe /codepage:28591 -d:NET_1_1 -d:ONLY_1_1 -d:BOOTSTRAP_WITH_OLDLIB -debug /noconfig -r:mscorlib.dll -r:System.dll -nowarn:0162,0618,0612,0642,1595 -target:library -out:System.Xml.dll System.Xml.XPath/Parser.cs Mono.Xml.Xsl/PatternParser.cs Mono.Xml.Xsl/PatternTokenizer.cs @System.Xml.dll.sources mono: mono-codeman.c:257: new_codechunk: Assertion `!err' failed. make[8]: *** [../../class/lib/basic/System.Xml.dll] Aborted make[8]: Leaving directory `/home/zzq01/source/mono/mcs/class/System.XML' make[7]: *** [do-all] Error 2 make[7]: Leaving directory `/home/zzq01/source/mono/mcs/class/System.XML' make[6]: *** [all-recursive] Error 1 make[6]: Leaving directory `/home/zzq01/source/mono/mcs/class' make[5]: *** [all-recursive] Error 1 make[5]: Leaving directory `/home/zzq01/source/mono/mcs' make[4]: *** [profile-do--basic--all] Error 2 make[4]: Leaving directory `/home/zzq01/source/mono/mcs' make[3]: *** [profiles-do--all] Error 2 make[3]: Leaving directory `/home/zzq01/source/mono/mcs' make[2]: *** [all-local] Error 2 make[2]: Leaving directory `/home/zzq01/source/mono/mono/runtime' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/zzq01/source/mono/mono' make: *** [all] Error 2 I can successfully compile the mono source from SVN in FC4 with gcc 4.0.2-8. has somebody successfully compiled mono in FC5? It's obvious that EXTERNAL_MCS=false makes it treat false as C# compiler. Remove that variable or change it to something useful. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] We want to contribute
On pon, 2006-07-17 at 15:01 -0400, Jesse Guardiani wrote: Andrés G. Aragoneses [ knocte ] wrote: Martin Hinks escribió: My main gripe with MonoDevelop is that the official IDE for cross-platform .NET is not cross-platform. Yes, that's the same thing I claimed when I wrote nowadays, it is very difficult to convince people about using a multiplatform development tool whose own IDE is not multiplatform. Regards. Andrés [ knocte ] -- I understand the concern, but isn't mono very comparable to a Java VM? Of course, it includes a huge open source class library too, but it seems to be very similar to the way Java has multiple VMs (IBM, Sun, MS, Blackdown, etc). I think people just aren't used to thinking of .NET as a technology like Java. They prefer to think of it as some mysterious thing from Microsoft. In that light, it makes sense to not write an IDE for win32 as the win32 folks already have a ton of their own IDEs. But, then again, we made mono itself run on win32, so why not the mono IDE? As John Luke said it wasn't a goal for the MonoDevelop. If someone wants to do that his work will be probably approved. But it's really a lot of work to do. It's easy to discuss about what needs to be done. But when the work needs to be done MonoDevelop on Windows topic gets completely silent after a week. :) I think that I see this topic every year. -- Marek Sieradzki [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] Re: Windows processes
On Sat, 2006-06-17 at 03:28 +0300, Alex Nedelcu wrote: Err ... replying to myself. I had a revelation ... what if I look at how Mono has implemented it. So I happily navigate to the System.Diagnostics.Process implementation http://svn.myrealbox.com/viewcvs/trunk/mcs/class/System/System.Diagnostics/Process.cs?rev=60744view=markup and what do I get ? [MethodImplAttribute(MethodImplOptions.InternalCall)] *private* *extern* *static* *int* GetPid_internal(); [MethodImplAttribute(MethodImplOptions.InternalCall)] *private* *extern* *static* *int*[] GetProcesses_internal(); Damn, I thought I had it easy. What the hell does MethodImplOptions.InternalCall mean ? Does it mean that the CLR takes care of it ? So, can you please help me ? I am not a good C++ programmer to search for code snippets that other people wrote. Yes, it means that Mono runtime takes care of it (it's implemented in the runtime). This call works almost the same as normal P/Invoke. Only multi-platform API for running processes that I know is System.Diagnostics.Process. -- Marek Sieradzki [EMAIL PROTECTED] ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] Single thread scheduler for Threading.Timers patch
On Tue, 2006-06-13 at 23:04 -0700, Rafael Ferreira wrote: Howdy, The attached patch changes the current Threading.Timer class to use a single thread scheduler instead of the current 1 thread per timer logic. I also spent a lot of time working on the Timer unit tests so they more consistently pass as well as fixing the NotWorking tests. Some key features include: * A single thread handles firing all timer jobs thus allowing a much greater number of Timers to be defined - Fixing bug #65734 * Timer scheduler is only started after the first System.Threading.Timer is created (lazy init) * Timer scheduler thread dies if there are no more timer jobs in its Job queue (early termination) * Scheduler can spit out debug info by exporting the MONO_TIMER_DEBUG environment variable Of course, I don't expect this patch to be accepted without some degree of scrutiny so comments/concerns are appreciated and I can commit the code once we're all comfortable with it. You are using wrong coding style in some places (f() instead of f ()). -- Marek Sieradzki [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] preferate build tool ?
Dnia 12-06-2006, pon o godzinie 00:58 +0300, Alex Nedelcu napisał(a): Hi guys, please help me out with this choice ... What build tool do you use and/or what is the preferred build tool for Mono projects ? And I know there are a couple of choices available ... GNU Make, Ant, NAnt, Rake or MSBuild. Depends on what project you are making. If you want to build project under Windows use NAnt. If not use MonoDevelop projects. When MSBuild under Mono will be ready it will be announced on the list. -- Marek Sieradzki [EMAIL PROTECTED] ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] Cross-platform: msbuild and xbuild
Dnia 11-05-2006, czw o godzinie 22:01 -0400, Karl Waclawek napisał(a): When I heard about xbuild I thought its purpose was to allow for sharing project files between MS.NET and Mono. As I would like to release source code for both platforms with minimal build differences this would be very handy. However, it appears that this does not work. Is my assumption mistaken? Implementing MSBuild is complicated task. You're right about your assumption but getting xbuild to work like MSBuild will take some time. If you're looking for a workaround you can use NAnt addin for Visual Studio. -- Marek Sieradzki [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] xbuild
Dnia 09-05-2006, wto o godzinie 15:43 +0200, Giuseppe Greco napisał(a): Hi all, will xbuild be the suggested/official build tool for Mono? The statement that monodevelop will support xbuild as well as NAnt is still true? It's too early to talk about MonoDevelop integration when core of xbuild is still not ready. It's on TODO list of MonoDevelop. SharpDevelop 2 uses MSBuild as default project format. At the moment that's just an idea. -- Marek Sieradzki [EMAIL PROTECTED] ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] xbuild + Microsoft.Build.Engine.dll + Bugs
Dnia 02-05-2006, wto o godzinie 14:54 -0500, [EMAIL PROTECTED] napisał(a): I have a couple small bugs/patches for xbuild.exe and Microsoft.Build.Engine.dll, but there doesn't appear to be the appropriate Products to place them under. Thoughts? There is no entry in bugzilla but you can add it to tools section or post patches here or send me them. -- Marek Sieradzki [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Class status
Dnia 21-04-2006, pią o godzinie 09:29 +0200, Matthijs ter Woord napisał(a): Hi, Why is the class status for the 2.0 profile still compared to the MS .NET framework 2.0 Beta 2 release? The RTM release of MS.NET 2.0 is out for quite some time now. It is compared to 2.0 not 2.0 Beta 2. I'm sure of that in case of Microsoft.Build.*. Probably other assemblies use the same revision. -- Marek Sieradzki [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Patch] Some bugs in xbuild and DirectorySeparator.
Dnia 11-03-2006, sob o godzinie 07:56 +0200, Crestez Leonard napisał(a): I fixed some bugs in xbuild. First, there's no reason for BuildItem.GetMetadata to always fail when the file doesn't exist, msbuild doesn't do that. Stuff that only relies on the path should work. I also modified DirectoryScanner a lot. It used to reorder multiple includes and fail on duplicates. msbuild doesn't do either. I didn't know that it failed on duplicates and forgot to place FIXME for reordering (caused by hashtable). The patch is from a svn diff in the root mcs dir. Right now xbuild won't work with msbuild projects because of path separator problems. A patch to make xbuild take both / and \ as path separators should be easy to write, but it's ugly. On the other hand current behaviour makes xbuild useless. Will you accept the patch if I write it? Yes. I wondered what should I do about strings like a\b. Should I search for '\' and replace with '/' or make switch to xbuild.exe or what else. BTW there are way more reasons why xbuild won't run VS2005 project files. Also, I noticed that in mono both Path.DirectorySeparatorChar and Path.AltDirectorySeparatorChar are /, while msdn says on unix they should be / and \. I know monodoc says they're both /, but why? I'm really excited of that someone tried to fix this mess. Also it would be great not to duplicate work. I'm synchronizing my local changes with SVN today. Could you send the patch? -- Marek Sieradzki [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] can't inport project from visual studio 2005 to monodevelop
Dnia 06-03-2006, pon o godzinie 22:16 -0500, William Huskey napisał(a): If this is the wrong list please let me know.. I have been porting from visual studio 2003 .net will little to no problems.. but my hsop just upgraded to visual studio 2005 and when I try to inport project I get Importing solution Importing project: /home/huskeyw/Calc/Calc/Calc.csproj ERROR: Could not import project:/home/huskeyw/Calc/Calc/Calc.csproj. Sharing violation on path /home/huskeyw/Calc/Calc/Calc.csproj if I just try the Calc.csproj file I get Exception occurred: Sharing violation on path /home/huskeyw/Calc/Calc/Calc.csproj System.IO.IOException: Sharing violation on path /home/huskeyw/Calc/Calc/Calc.csproj in 0x00338 System.IO.FileStream:.ctor (System.String name, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, Boolean isAsync, Boolean anonymous) in 0x00053 System.IO.FileStream:.ctor (System.String name, FileMode mode) in (wrapper remoting-invoke-with-check) System.IO.FileStream:.ctor (string,System.IO.FileMode) in 0x00127 MonoDevelop.Prj2Make.SlnMaker:CreatePrjxFromCsproj (System.String csprojFileName, IProgressMonitor monitor) I am not sure what this is.. nothing is using these files.. have even rebooted and moved, made copys.. Ive chmoded 777 on them and the directorys.. Thanks That's an unimplemented feature. VS 2005 uses different project file format. Prj2Make needs to be updated and we need rewrite of Microsoft.Build.* assemblies. I'm doing actually the second part. I don't see any chances to finish that before May. (Maybe if someone else help me and if I get lots of free time) -- Marek Sieradzki [EMAIL PROTECTED] ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] XBuild VS2005 Projects
Dnia 04-01-2006, śro o godzinie 23:03 -0500, Norman Young napisał(a): Hi, I'm a VS2005 (RC) user, but am new to Mono and am interested in getting my VS2005 projects to build on Mono. A few questions: 1) What's the best way to get VS2005 projects to build on Mono? I saw a post in the November archives that Prj2Make has yet to be updated to handle VS2005 .csproj files. Is there an alternative? Is the only way just to write a makefile? How about NAnt? There are NAnt add-ins to VS so you can use NAnt files and use them under Linux. XBuild is not in that stage that would allow building .csproj files from VS2005. 2) Is it possible to run msbuild on mono? I tried with little success, but I'm not sure if I'm doing something wrong. I tried to do that. MSBuild uses something that can be run only under Windows (or NET 2.0). (Maybe it's a bug in Mono) 3) Relative to MSBuild, how complete is XBuild? What functionality does it have currently? It has troubles with parsing more complicated files. Beside that it doesn't have a lot of tasks from MSBuild. Another problem is change of API 1-2 months ago. After dealing with those problems we can talk about quite stable software. Before that it isn't usable to build VS2005 project files. 4) Will XBuild work on VS2005 .csproj files? I tried building a default skeleton VS2005 WinForms project with XBuild, but it throws an InvalidCastException. Answered above. -- Marek Sieradzki [EMAIL PROTECTED] ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] [Fwd: Planning for Mono 1.2: API freeze.]
Dnia 02-01-2006, pon o godzinie 12:55 -0500, Miguel de Icaza napisał(a): Załącznik: wiadomość e-mail, Forwarded message - Planning for Mono 1.2: API freeze. Przesyłany list -- Od: Miguel de Icaza [EMAIL PROTECTED] Dla: Mono Hackers [EMAIL PROTECTED] Temat: Planning for Mono 1.2: API freeze. Data: Mon, 02 Jan 2006 12:54:19 -0500 Hello folks, I know that this is a very short notice, I should have mentioned this in mid-December, but I completely blanked out. We are going to API freeze Mono this week. If you have any API changes that you want to make, please contact me directly. What this means is that the public API of the Mono-specific libraries will cease to change, although we can continue to bug fix it and document it. The .NET libraries already had their APIs set in stone, so those will continue to be developed (implementing NotImplementedExceptions, fixing bugs and implementing NET_2_0 protected code). Changes to the .NET public API to fix differences against the published .NET interface is ok (specially in the 2.x universe, as Mono 1.2 will not guarantee .NET 2.0 support in full anyways, so things are much more lax there). So in short: you can change implementation bits, but not public interfaces. If an API change is /absolutely required/ this needs to be discussed before the patch makes it into SVN. API from NET 2.0 (Microsoft.Build.*) isn't considered stable? Code that is currently in SVN was obsoleted by new NET 2.0 release and it needs some changes. There is absolutely no compatibility between these two versions (from Beta 2 and 2.0). I added some code to new Mono.XBuild namespaces. I think that something of it can also change to make it work with 2.0 Microsoft.Build. -- Marek Sieradzki [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] Prj2Make for VS2005
Dnia 08-12-2005, czw o godzinie 18:06 -0500, [EMAIL PROTECTED] napisał(a): I recently moved from VisualStudio 2003 (Everett) to Visual Studio 2005 (Whidbey) for the development under Windows environments (for both .NET and Mono environments, with some hacks). Anyway, I used to pregenerate the .prjx and make files for compatibility with MonoDevelop and Linux gmake (or even MS NMake) with the older version of VS. I tried to do the same for VS2005, but it seems not working: is it there a version of Prj2Make that is suitable? If not, is there any plan for the improvements of the tool to support it? I think Visual Studio 2005 uses msbuild files instead. Yes, it is completely different format. There is some work on SVN that was funded by the Google summer of code to do this, but we have not added it to the make system (somene needs to add them). Microsoft.Build.* assemblies and tools/xbuild. In addition, xbuild is probably not complete today, it might need some work to get to a fully functional state As I said it wouldn't be good to add it to make system by default. Classes design changed after release of .NET 2.0. It has changed so much that I'll need to think about rewriting big part of xbuild. I'm sure that no program should use its API (it changed/will change). After this rewrite and some clean up in parser and tokenizer it should be quite stable (and useful). -- Marek Sieradzki [EMAIL PROTECTED] ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Prj2Make for VS2005
Dnia 07-12-2005, śro o godzinie 15:48 -0600, Francisco T. Martinez napisał(a): Antonello Provenzano wrote: Hi guys, I recently moved from VisualStudio 2003 (Everett) to Visual Studio 2005 (Whidbey) for the development under Windows environments (for both .NET and Mono environments, with some hacks). Anyway, I used to pregenerate the .prjx and make files for compatibility with MonoDevelop and Linux gmake (or even MS NMake) with the older version of VS. I tried to do the same for VS2005, but it seems not working: is it there a version of Prj2Make that is suitable? If not, is there any plan for the improvements of the tool to support it? I intend to work on some level of compatibility with Prj2make# and Visual Studio 2005. However, I have a number of other projects and pressing issues that are keeping me from working on that at present. My hopes are to begin work on that task around March, 2006. Paco PS The sooner I get GtkSourceView-Sharp working on Windows (natively) the sooner I will be able to work on other non-profit projects. To build VS2005 projects you need only MSBuild. After some rewrite you would be able to use xbuild for this. It will be also possible to write project file type addin to MonoDevelop for VS2005 files. I don't think that making code from a scratch for whole new format is good solution. Problem is that I won't have time for a few months to update xbuild (MSBuild changed recently in NET 2.0 release) because I'm finishing high school. -- Marek Sieradzki [EMAIL PROTECTED] ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] building for Mono under msbuild
Dnia 11-10-2005, wto o godzinie 11:49 -0700, Andy Waddell napisał(a): I have an application that needs to run under both .NET and Mono and I came up with a pretty simple way to get MS DevStudio to build both. I don’t know how others have solved this problem, but I thought I would offer it up in case it helps someone else with the same issue. The basic approach I took was to call the Mono compiler after the Microsoft build has already run. Microsoft has a well known target “AfterBuild” which I have hooked to invoke gmcs with pretty much the same arguments that csc.exe takes with some minor modifications. I put all the Mono build stuff in a file called Mono.targets, so it only take a one line addition to the standard *.csproj file to get the functionality: Import Project=$(MSBuildBinPath)\Microsoft.CSharp.targets / Add this lineà Import Project=your path\Mono.targets / Few weeks before this post someone sent post with his .targets file. It should be in the archive. (I don't know if attachment is also archived) This will make your build essentially a dual pass build with all the Microsoft stuff running and then the Mono compiler running with all the warnings and erros showing up in the IDE as you would expect. The work is not complete (I don’t pass all the options possible, etc), but I think it’s fairly obvious how to expand it if needed. I’m sure there are many other ways to skin this cat, but for a quick and dirty solution, it seems to work pretty well. ToDo: invesitgate xbuild to do my Linux builds. Current xbuild won't build project from .csproj file because some features use by Microsoft.Common.targets are not implemented and because of that this .targets file is not made for Mono but Microsoft .NET runtime. At this moment it should be possible to use mcs by Microsoft.Build.Tasks.Csc from xbuild. You would need to load it (UsingTask) and create your own version of Compile target. You need to be sure that VS does not use HostObject(Microsoft.Build.Tasks.Hosting.ICscHostObject) compiler which is implemented in VS2005 but not in MSBuild or xbuild. I'm working on rewrite in xbuild. When I'll get some free time I'll write more tests and fix bugs. (like AL task that isn't reporting errors/warnings properly) -- Marek Sieradzki [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] MSBuild target for Mono
Builds inside VS2005 use Microsoft.Build.Tasks.Hosting.ICscHostObject interface. Microsoft.Build.Tasks.Csc class is also used for builds. To use mcs instead of csc you need to write your own Csc task with ie. CscHostObject. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] Converting csproj to Makefile
Dnia 22-09-2005, czw o godzinie 09:50 -0700, Rafael Ferreira napisał(a): have you tried prj2make ? I don't think that prj2make would solve the problem. VS2005 uses new format for build files. These files can be executed by xbuild or msbuild. However there are a lot of things that need to be changed in xbuild to make it execute normal .csproj files from VS2005 beta 2. On Thu, 2005-09-22 at 09:41 -0700, Andy Waddell wrote: I’ve been working on getting our product to run under Mono and one of the first problems I had to solve was the moving target of all the MSDEV (2005 B2 btw) project files that the rest are team are actively working with. I wrote a quick-and-dirty Perl script to suck up the XML from the .csproj files and write out a simple Makefile and this has been fine, but I wonder if there is a better way? Yesterday I noticed the “xbuild” project but I couldn’t find too much information about it. Could someone point me in the right direction or offer suggestions so that I don’t spend too much time re-inventing the wheel? I'll update README in tools/xbuild. -- Marek Sieradzki [EMAIL PROTECTED] ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-devel-list] MonoDevelop : looking for mozilla
Dnia 23-06-2005, czw o godzinie 16:22 +0200, Mikkel Kruse Johnsen napisał(a): Hi No it is not possible to use firefox, firefox is compiled in static mode, and gecko-sharp needs a shared compiled mode. Witch mozilla is. You mean firefox from www.mozilla.org site? I mean ie. mozilla-firefox package in Ubuntu. In my case it works. (gecko-sharp from svn). I guess mozilla-firefox was compiled to shared binaries. I think there is a way. Just set MOZILLA_FIVE_HOME environment variable to path where you have Firefox. Dnia 23-06-2005, czw o godzinie 09:49 +0100, Martin Hinks napisał(a): -- Marek Sieradzki [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] MSBuild implementation and Google Summer of code
I'm going to send application to google for this. I have some questions. 1. On what license code from svn.myrealbox.com/monodevelop/trunk/MSBuild/ is released? I have used it for start. I have made stubs for remaining classes, interfaces, delegates and enums that are in namespaces Microsoft.Build.Engine, Microsoft.Build.Framework, Microsoft.Build.Tasks, Microsoft.Build.Utilities. 2. Am i right with that: MSBuild implementation should consist of 3 parts: xml parser(using XmlSerializer), classes from 4 above mentioned namespaces and a command line tool? 3. Which documentation should I use? There are(in MSDN): .NET Framework reference about Longhorn and some notes about msbuild app. 4. What about methods typical to Win32 API? Like Microsoft.Build.Utilities.ToolLocationHelper.GetDotNetFrameworkRootRegistryKey(). 5. Is anyone able to contact with Rob Tillie [EMAIL PROTECTED]? He started the implementation that is available in svn/md. -- Marek Sieradzki [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
