I am trying to embed managed c# code to c++ (with the help of tutorial in http://www.mono-project.com/Embedding_Mono and examples included in samples).
However I cannot get it to work. I think it is very possible that the problem is with a System.Net.Sockets.TcpClient object (for instance I can access values and methods of some other classes but if I add a TcpClient object to a class I encounter problems.
Here is some simple C# code I wrote to test just adding a TCPClient object
using System;
using System.Collections.Generic;
using System.Text;
using System.Net.Sockets;
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
}
static void TCPTest()
{
TcpClient TCPClient;
//Console.WriteLine("in tcp test");
}
}
}
And the c++ code is here: http://codepad.org/f9D5bg8u (it is a stripped down version of the mono embedding sample).
When I build the C# code like this,
mono_runtime_invoke (method, obj, NULL, NULL);
in the c++ side exits with code 1.
When I comment that out and try the console.writeline, that works.
I appreciate any suggestions,
Thanks...
Related
I just created my first .NET 6 console app, and instead of the default,
using System;
using System.Collections.Generic;
using System.Linq;
namespace MyApp
{
public class Program
{
public static void Main(string[] args)
{
Console.WriteLine("Hello World!");
}
}
}
I got:
// See https://aka.ms/new-console-template for more information
Console.WriteLine("Hello, World!");
And even when there's no class, the program runs! I took a look at the link provided in the comments, but I don't know if this is a new feature or an old one. If this is a new feature, does that mean C# will be allowing C-style programming hereafter?
It's a new feature of C# 9 or 10. Microsoft documentation says following:
Top-level statements enable you to avoid the extra ceremony required by placing your program's entry point in a static method in a class. The typical starting point for a new console application looks like the following code:
using System;
namespace Application
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Hello World!");
}
}
}
The preceding code is the result of running the dotnet new console command and creating a new console application. Those 11 lines contain only one line of executable code. You can simplify that program with the new top-level statements feature. That enables you to remove all but two of the lines in this program:
Console.WriteLine("Hello, World!");
I'm currently spending a bit of time making simple Console applications using Xamarin studio/monodevelop in C#. (On Mac OSX)
But for whatever reason, my audio code isn't working. A track never plays when the console opens, but I get no errors.
I'm sure the code is good:
using System;
using System.Media;
namespace Learnin
{
class MainClass
{
public static void Main(string[] args)
{
(new SoundPlayer(#"/Users/alasdairgorniak/Desktop/Take.wav")).PlaySync();
...
I know it is possible to code C# .NET apps in Linux using Mono. However, I am wondering about the process interfaces of Linux. Could I use services like getpid(), getppid() and fork() using C# and Mono and running on a Linux environment?
For getpid() and getppid() you could use Syscall in this way:
using System;
using Mono.Unix.Native;
namespace StackOverflow
{
class MainClass
{
public static void Main(string[] args)
{
int pid = Syscall.getpid();
int ppid = Syscall.getppid();
Console.WriteLine ("PID: {0}", pid);
Console.WriteLine ("PPID: {0}", ppid);
}
}
}
You need Mono.Posix.dll
For fork() you can use Process. See example here: creating child process with C#
Documentation about Process Class C#.
I'm experimenting with Dll rebasing on a small test solution running on .net4 consisting of one small .exe and three small .Dlls. The assembly references have been set up correctly and the program compiles and runs just fine.
The aim of this exercise is to examine how rebasing works so that I can tie it in with ngen and get performance increases in a massive project I'm working on.
I've tried many different methods of rebasing the Dlls and monitored the results using vmmap, the visual studio module debugger window and process explorer; nothing has been successful so far:
I've set the Build->Advanced->DLL Base Address setting to 0x41000000, 0x42000000 and 0x43000000 for Dll1.dll, Dll2.dll and Dll3.dll respectively. These addresses were definitely saved as the preferred base address in each of the Dlls, but for each run the Dlls rebased their images erratically to many different locations in memory.
I've tried using this application. The logs it generate show that the Dlls do indeed have the preferred base address (as selected by me) built in, however at runtime the results are still erratic
I've tried using ngen. This results in the .ni versions of the Dlls being loaded alongside the original Dlls, and all 6 of them having erratic memory locations nowhere near the ones I asked for.
I've tried sticking my images in the GAC. It was heartening to see that only the GAC'd versions of the Dlls were loaded, however their memory locations were still erratic.
I've tried what feels like every combination of the above. No success.
Poking around at runtime using VMMap shows that there is a massive gap of available memory in the address space between 0x10000000 and 0x50000000, so there should be no collisions and no need for Dll rebasing to occur. The Dlls are also very small and the 0x01000000 gap I'm leaving between them is extremely generous, so they shouldn't be colliding with each other.
What am I missing?
My main reference during this exercise has been this article, which is highly informative, but was written in 2006 for .Net2: Has something fundamental changed between then and now?
I seriously doubt it makes much difference, but here's the code I'm using just in case:
Program.cs:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading;
using Dll1;
using Dll2;
using Dll3;
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
Thread.CurrentThread.Name = "Poodle";
Console.ReadLine();
//Thread.Sleep(10000);
Blah();
}
static void Blah()
{
Console.WriteLine(Class2.shrooms(5, 'h'));
Class3.teenAngst();
Class1.Wait();
}
}
}
Class1.cs:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace Dll1
{
public static class Class1
{
public static void Wait()
{
Console.ReadLine();
Console.Write(" ");
}
}
}
Class2.cs:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace Dll2
{
public static class Class2
{
public static string shrooms(int argc, char argv)
{
return "Ranchdaddyx ";
}
}
}
Class3.cs:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace Dll3
{
public static class Class3
{
public static void teenAngst()
{
Console.Write("Belonging ");
}
}
}
It is not necessary to rebase JIT compiled code:
JIT-compiled code does not have a rebasing problem since the addresses
are generated at run time based on where the code is placed in memory.
Also, MSIL is rarely affected by base address misses since MSIL
references are token-based, rather than address-based. Thus when the
JIT compiler is used, the system is resilient to base address
collisions.
.NET assemblies and DLL rebasing
If I want to rebase my DLL's, how do I go about doing it?
http://msdn.microsoft.com/en-us/magazine/cc163610.aspx
http://support.microsoft.com/kb/969305
It turns out that ASLR (Address Space Layout Randomization) is the culprit of my confusions. Apparently you can turn it off, but you're sacrificing safety/making a lot of work for yourself. I consider the whole adventure a failed experiment.
.Net .dll's are a very different beast from their unmanaged equivalents. I honestly didn't think that rebasing was relevant.
Check out this MSDN article. Which, among other things, encourages you to NOT rebase. And gives at least one compelling reason NOT to (it could invalidate the signature of a strongly signed assembly). The article also discusses the potential benefits of NGEN (as does your link):
CLR Inside Out
Consider following piece of code:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace RemotingNonVirtualCall
{
class Program
{
static void Main(string[] args)
{
var domain = AppDomain.CreateDomain("Second Domain");
A extA = (A)domain.CreateInstanceAndUnwrap(typeof(A).Assembly.FullName, typeof(A).FullName);
Console.WriteLine(extA.CurrentDomain());
}
}
[Serializable]
sealed class A : MarshalByRefObject
{
public string CurrentDomain()
{
return AppDomain.CurrentDomain.FriendlyName;
}
}
}
Method A::CurrentDomain is non-virtual, class A is sealed. But CLR intercepts method call and redirect it to another instance. How it is possible? Is it some sort of voodoo magic? Does CLR make some exception in method calling for object inherited from MarshalByRefObject class? How is it performed?
Thanks for advance.
It's essentially magic, i.e. the ability to do this is built into the .NET runtime. The good news is that your code can also do this, if it needs to: http://msdn.microsoft.com/en-us/library/system.runtime.remoting.proxies.realproxy.aspx
The JIT compiler is keenly aware that it generates code for a proxy. You can have a look-see with the SSCLI20 source code, clr\src\vm\jithelpers.cpp, search for "proxy".