I have a file called hellowf.cs
class MyFirstApp {
static void Main() {
System.Windows.Forms.MessageBox.Show("Hello, Mono+WinForms!");
}
}
On Ubuntu 8.10, I do the following
gmcs hellowf.cs -r:System.Drawing.dll -r:System.Windows.Forms.dll
mono hellowf.exe
... and it looks like this:
alt text http://img136.imageshack.us/img136/4674/helloproblemuk5.png
The second part of the message is missing. Why is this happening? The same binary - hellowf.exe - works fine on Windows.
Update:
This is really annoying. Here are the mono versions I have had and tried to make this work on so far:
1.9.1 (from official ubuntu repo)
2.0.1 (from some some 3rd party repo)
2.2 (wiped every mono pkg and compiled myself)
My Current mono version:
mono --version
Mono JIT compiler version 2.2 (tarball Wed Jan 14 22:58:21 CET 2009)
Copyright (C) 2002-2008 Novell, Inc and Contributors. www.mono-project.com
TLS: __thread
GC: Included Boehm (with typed GC)
SIGSEGV: altstack
Notifications: epoll
Architecture: x86
Disabled: none
gmcs --version
Mono C# compiler version 2.2.0.0
... any clues?
Finally I have found a workaround. This seems to be a bug in Mono related to font rendering. It happens when "Full" hinting is turned on. I usually have it that way. Changing it to "Slight" or "Medium" in System->Preferences->Appearance->Fonts->Details fixes the problem. Thanks for the help!
Works OK on opensuse 11.0, mono 2.0.1.
Please, edit your question and put the mono version you are using.
stick an # in front of the "Hello, Mono+WinForms!" and see if it still happens.
Standard debugging advice:
Start making small, controlled changes, and see what happens.
This will help narrow down what the problem is.
Try removing the symbols: , + !
Try removing the space.
Try a variety of shorter strings, and possibly some longer strings.
Once you have a better idea of what the MessageBox will and will not print, you can start to debug that specific problem, instead of trying to debug, "It doesn't work!"
When you updated your packages and source code, did you update/compile libgdiplus? We have seen some funky graphical problems if the System.Drawing and libgdiplus versions get out of sync.
Related
I have installed mono version 4.2.1.60 on my CentOS operating system from this source by first downloading the tarball and then doing sudo ./configure, sudo make and sudo make install on the extracted source files.
Configure return this, which looks ok to me
Engine:
Host: x86_64-unknown-linux-gnu
Target: x86_64-unknown-linux-gnu
GC: sgen and Included Boehm GC with typed GC and parallel mark
TLS: __thread
SIGALTSTACK: yes
Engine: Building and using the JIT
oprofile: no
BigArrays: no
DTrace: no
LLVM Back End: no (dynamically loaded: no)
Mono itself runs fine this way with the major collector marksweep.
But now I want to run mono with the SGen garbage collector and it's major collector marksweep-par for some tests. This is what I do according to this description:
export MONO_GC_PARAMS=major=marksweep-par
mono-sgen testApp.exe
Unfortunately mono starts with this warning
Warning: In environment variable 'MONO_GC_PARAMS': Unknown major collector 'marksweep-par'. - Using 'marksweep' instead.
Of course this is not what I want. Google did not return an answer to me when looking for this warning. Now my question is, how I can get mono to run with marksweep-par.
What am I doing wrong? Any help is appreciated.
You are referring to a old man page (Mono 2.5) while you are running 4.2+.
You should review the man page installed on your system:
man mono
major=collector
Specifies which major collector to use. Options are marksweep for
the Mark&Sweep collector, and marksweep-conc for concurrent
Mark&Sweep. The non-concurrent Mark&Sweep collector is the default.
In trying to build NuGet3, I'm getting the following error:
~/Projects/NuGet3-dev/src/NuGet.CommandLine/project.json(22,46): error: The dependency fx/Microsoft.Build.Framework >= 14.0.0 could not be resolved.
I have no idea why it wouldn't be resolved, since according to
gacutil -l
I have it:
Microsoft.Build.Framework, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
I looked at everything I could find about this issue, but it's almost entirely Visual Studio and Windows based resolutions, and nothing seems to apply to my situation...
How to make this resolve?
(Assuming you are working on https://github.com/NuGet/NuGet.CommandLine ...)
How to resolve?
Use Windows. This project is not designed to be built on Mono. It is integrated with Windows tooling.
Under POSIX systems (thought, some true operating system):
In short, the dependency is resolved using DNX or dotnet (said M$ .Net Core), and its restore command.
The fx/ stands for framework, just drop the prefix, it should be the same. I sow these kind of notations disappear, when passing to DNX. Just try and install it using the DNX process.
since MSBuild targets and props for DNX are not available, the xbuild script from Mono won't work.
You'll have to use one of
the "deprecated" dnvm.sh script and dnx/dnu commands to restore and then build each sub project.
Note: that yet isn't anymore available at download, and the call to dnvm update-self relaces the script by a "404" ...
The "Microsoft .NET Core Shared Framework Host", "dotnet" (that I don't use)
It should mostly work, if you've got Dnx, try this command line, from the src sub-dir of the NuGet3 source code:
(for d in *; do (cd $d && dnu restore && dnu build); done)2>&1|tee build-all.log
For me, using Debian-8, there are build failures:
NuGet.CommandLine.XPlat
NuGet.Configuration, but it succeeds for the "net451" framework
NuGet.Packaging.Core
NuGet.Packaging
NuGet.Protocol.Core.v3, but it's OK #dnxcore50 (don't ask me why) ...
YANote: If code cannot be transformed anywhere but by M$, this is cannot be source code for me : I cannot not use it as a source. This is a secret code, a private code ... something to throw away, and that probably no one cares.
I was searching for answer many hours but I haven't found any solution.
I'm running sonar for C# project, I using Sonar 3.4 and sonar-runner 2.0 and C# plugins:
sonar-csharp-core-plugin-1.4
sonar-csharp-fxcop-plugin-1.4
sonar-csharp-gallio-plugin-1.4
sonar-csharp-gendarme-plugin-1.4
sonar-csharp-ndeps-plugin-1.4
sonar-csharp-squid-plugin-1.4
sonar-csharp-stylecop-plugin-1.4
and after running the analysis by sonar-runner I getting that exception
Exception in thread "main" org.sonar.runner.RunnerException: org.sonar.api.utils.SonarException: Fail to decorate 'org.sonar.api.resources.File#243e2c21[key=ApplicationName.cs,dir=,filename=ApplicationName.cs,language=C#]'
at org.sonar.runner.Runner.delegateExecution(Runner.java:288)
at org.sonar.runner.Runner.execute(Runner.java:151)
at org.sonar.runner.Main.execute(Main.java:84)
at org.sonar.runner.Main.main(Main.java:56)
Caused by: org.sonar.api.utils.SonarException: Fail to decorate'org.sonar.api.resources.File#243e2c21[key=ApplicationName.cs,dir=,filename=ApplicationName.cs,language=C#]'
at org.sonar.batch.phases.DecoratorsExecutor.executeDecorator(DecoratorsExecutor.java:84)
at org.sonar.batch.phases.DecoratorsExecutor.decorateResource(DecoratorsExecutor.java:70)
at org.sonar.batch.phases.DecoratorsExecutor.decorateResource(DecoratorsExecutor.java:63)
at org.sonar.batch.phases.DecoratorsExecutor.decorateResource(DecoratorsExecutor.java:63)
at org.sonar.batch.phases.DecoratorsExecutor.execute(DecoratorsExecutor.java:55)
at org.sonar.batch.phases.Phases.execute(Phases.java:92)
at org.sonar.batch.bootstrap.ProjectModule.doStart(ProjectModule.java:129)
at org.sonar.batch.bootstrap.Module.start(Module.java:68)
at org.sonar.batch.bootstrap.BatchModule.analyze(BatchModule.java:147)
at org.sonar.batch.bootstrap.BatchModule.analyze(BatchModule.java:141)
at org.sonar.batch.bootstrap.BatchModule.doStart(BatchModule.java:136)
at org.sonar.batch.bootstrap.Module.start(Module.java:68)
at org.sonar.batch.bootstrap.BootstrapModule.doStart(BootstrapModule.java:83)
at org.sonar.batch.bootstrap.Module.start(Module.java:68)
at org.sonar.batch.Batch.execute(Batch.java:106)
at org.sonar.runner.internal.batch.Launcher.executeBatch(Launcher.java:6
at org.sonar.runner.internal.batch.Launcher.execute(Launcher.java:61)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.sonar.runner.Runner.delegateExecution(Runner.java:285)
... 3 more
Caused by: org.sonar.api.utils.SonarException: Unknown metric: temp-method-lines
at org.sonar.batch.index.DefaultIndex.addMeasure(DefaultIndex.java:184)
at org.sonar.batch.DefaultDecoratorContext.saveMeasure(DefaultDecoratorContext.java:111)
at org.sonar.plugins.uselesscodetracker.decorator.TempMethodLinesDecorator.computeDistributionFromChildren(TempMethodLinesDecorator.java:58)
at org.sonar.plugins.uselesscodetracker.decorator.TempMethodLinesDecorator.decorate(TempMethodLinesDecorator.java:49)
at org.sonar.batch.phases.DecoratorsExecutor.executeDecorator(DecoratorsExecutor.java:79)
... 24 more
I don't know what this "temp-method-lines" metric can be, never heard of it...
Please install the latest version of the .NET & C# Plugins Ecosystem: version 2.0. Also, make sure you uninstall any other plugin that could have brought this unknown metric (maybe a custom plugin that you wrote??).
And please upgrade to Sonar 3.4.1 as version 3.4 suffers from a critical bug.
I am having to building mono from sources, since the Ubuntu package from badgerports is outdated (does not support .Net 4.0)
This is what I have done so far (mostly following instructions here):
cloned mono git repository
switched to branch tagged 2.6 (git checkout mono-2-6)
installed minimal mono on my machine so mono and mcs are available on machine
run ./autogen.sh --prefix=/usr/local
run make
After a few modules compile correctly, I get this error:
make[4]: Entering directory `/home/oompah/work/dev/mono/mono/mini'
CC mini.lo
CC liveness.lo
liveness.c: In function ‘mono_liveness_handle_exception_clauses’:
liveness.c:137: error: ‘MonoCompile’ has no member named ‘header’
make[4]: *** [liveness.lo] Error 1
make[4]: Leaving directory `/home/oompah/work/dev/mono/mono/mini'
make[3]: *** [all] Error 2
I have looked at the offending code, and indeed a header member is being accessed ...
void
mono_liveness_handle_exception_clauses (MonoCompile *cfg)
{
MonoBasicBlock *bb;
GSList *visited = NULL;
MonoMethodHeader *header = cfg->header;
...
}
Has anyone managed to build mono-2.6 (or later) on Ubuntu?
I've used the scripts provided at integratedwebsystems successfully to compile a recent version of mono on my system and run .net 4.0 applications.
an improved version of the script can be found on firegrass' github account
Joe Shields is packaging Mono 2.10 and is patching everything to default to .NET 4.0 for Ubuntu, you might want to poke him on twitter #directhex.
we are currently having serious problems running a pure c# application on mono 2.8.1 on debian 5.
We are using .net webservices as well as async sockets and probably found a race condition in the mono threadpool.
I would be thankful for every idea.
if someone has informations if mono 2.8.1 has known problems on debian 4/5 that might have something to do with this, please answer too:)
Assertion at mono-wsq.c:73, condition `mono_wsq_count (wsq) == 0' not met
Stacktrace:
Native stacktrace:
mono [0x48f582]
/lib/libpthread.so.0 [0x2abe8f8d2a80]
/lib/libc.so.6(gsignal+0x35) [0x2abe8fb12ed5]
/lib/libc.so.6(abort+0x183) [0x2abe8fb143f3]
mono [0x5cd042]
mono [0x5cd21a]
mono [0x5f271a]
mono [0x5924ca]
mono [0x58c24b]
mono [0x5bd83b]
mono [0x5e9ed6]
/lib/libpthread.so.0 [0x2abe8f8cafc7]
/lib/libc.so.6(clone+0x6d) [0x2abe8fbb064d]
Debug info from gdb:
=================================================================
Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================
I fixed this in mono 2.8.2. Someone has reported that they still see it in 2.8.2 (we don't see it in our servers any more) and we are working to debug it.