使用MonoDevelop在Linux for Windows中进行交叉编译 [英] Cross compiling in Linux for Windows using MonoDevelop

问题描述

每个人都过得愉快，



我最近切换到Linux Mint作为我的主要操作系统（实际上我还是在虚拟机中尝试它，但是我很快就会把它安装到我的电脑上，所以我不是那个领域的专家。



我正在为我的学校做一个学校项目Liceo的一年，我想通过使用IDE MonoDevelop在Linux中用C＃和Mono开发它，它被告知交叉编译Linux和Windows的代码。



根据此StackOverflow答案和其他一些资源，我发现了MonoDevelop为Windows生成可执行文件，如果我在Windows机器上复制可执行文件，它应该可以正常工作。实际上，我尝试了但没有尝试：应用程序在Linux中运行顺畅（它还打开了一个终端窗口，这是非常讨厌的东西，我想关闭它），但如果我在我的Windows 10系统上复制它不起作用：三秒钟后，流程停止，流程启动的事实只能在任务管理器中看到。



因为我有Visual Studio 2015安装在我的系统上我希望也安装了最新版本的.NET框架，所以根据前面提到的文章，可执行文件应该可以工作，但实际上它不适用于Windows。



该项目是使用Linux上的GTK＃图形库编译的。



任何帮助表示赞赏。



非常感谢。



EDIT2：我再次尝试在Mono中创建一个新应用程序，构建它然后在Windows上运行它。它不起作用，但我注意到我以前没有注意到的Mono References中的内容：没有找到GTK＃程序集，尽管应用程序在Linux上运行顺畅。

这是截图：屏幕截图



编辑：这是代码我试过：它只是一个简单的应用程序，在textview中显示一个文本文件（我想在开始开发更大的项目之前尝试更简单的事情）：

Good day everybody,

I've recently switched to Linux Mint as my primary operating system (actually I'm still trying it in a Virtual machine, but I'm going to install it on my computer very soon), so I am not an expert in that field.

I'm doing a school project for my last year of Liceo and I'd like to develop it in Linux with C# and Mono by using the IDE MonoDevelop which is told to cross compile the code for Linux and Windows.

According to this StackOverflow answer and some other resources I found out that MonoDevelop generates an executable for Windows and that if I copy the executable on the Windows machine it should work without problems. Actually, I tried it but nothing: the application runs smoothly in Linux (and it also opens a terminal window, which is something very annoying and I'd like to turn that off), but if I copy it on my Windows 10 system it does not work: after three seconds the process stops and the fact that the process has been started can be seen only in the task manager.

As I have Visual Studio 2015 installed on my system I expect to have installed also the latest version of the .NET framework so, according to the aforementioned article the executable should work, but actually it does not on Windows.

The project was compiled by using the GTK# graphics libraries on Linux.

Any help is appreciated.

Thanks a lot.

I've tried again by creating a new application in Mono, building it and then running it on Windows. It does not work, but I noticed something in my Mono References I haven't noticed before: no GTK# assemblies are found, though the application runs smoothly on Linux.
Here's a screenshot: Screenshot

Here's the code I've tried: it's just a simple application that displays a text file in a textview (I wanted to try with something simpler before starting developing a bigger project):

using System;
using Gtk;

public partial class MainWindow: Gtk.Window
{	
	public MainWindow (): base (Gtk.WindowType.Toplevel)
	{
		Build ();
	}

	protected void OnDeleteEvent (object sender, DeleteEventArgs a)
	{
		Application.Quit ();
		a.RetVal = true;
	}

	protected virtual void OnOpen(object sender, System.EventArgs e)
	{
		// Reset the logTreeView and change the window back to original size
		/*int width, height;
		this.GetDefaultSize( out width, out height );
		this.Resize( width, height );*/

		
		logTextView.Buffer.Text = "";

		// Create and display a fileChooserDialog
		FileChooserDialog chooser = new FileChooserDialog(
			"Please select a logfile to view ...",
			this,
			FileChooserAction.Open,
			"Cancel", ResponseType.Cancel,
			"Open", ResponseType.Accept );

		if( chooser.Run() == ( int )ResponseType.Accept )
		{
			// Open the file for reading.
			System.IO.StreamReader file =
				System.IO.File.OpenText( chooser.Filename );

			// Copy the contents into the logTextView
			logTextView.Buffer.Text = file.ReadToEnd();

			// Set the MainWindow Title to the filename.
			this.Title = "Nate's Log Viewer -- " + chooser.Filename.ToString();

			// Make the MainWindow bigger to accomodate the text in the logTextView
			this.Resize( 640, 480 );

			// Close the file so as to not leave a mess.
			file.Close();
		} // end if
		chooser.Destroy();
	} // end method OnOpen

	protected void OnClose (object sender, EventArgs e)
	{
		int width, height;
		this.GetDefaultSize( out width, out height );
		this.Resize( width, height );

		logTextView.Buffer.Text = "";

		// Change the MainWindow Title back to the default.
		this.Title = "Nate's Log Viewer";
	}

	protected void OnExit (object sender, EventArgs e)
	{
		Application.Quit ();
	}

	protected void OnAbout (object sender, EventArgs e)
	{
		// Create a new About dialog
		AboutDialog about = new AboutDialog();

		// Change the Dialog's properties to the appropriate values.
		about.ProgramName = "Nate's Log Viewer";
		about.Version = "1.0.0";

		// Show the Dialog and pass it control
		about.Run();

		// Destroy the dialog
		about.Destroy();
	}
}

GL

GL

推荐答案

您没有提供有关该项目的任何相关信息，因此我无法为您提供解决问题的方法，但有些事情您需要正确理解。



首先，这是不是交叉编译。这是使用不同编译器进行同一平台的编译。 .NET CLR和Mono是同一平台的不同实现。程序集以相同的方式运行而没有重新编译的事实只是这个事实的一个方面。



同时，在我个人为不同版本检测到的那些实现之间存在许多不兼容性。我有一段时间没有使用Mono，也无法告诉你有关最新版本的任何细节。但是，我看到的所有不兼容性都与某些FCL类型的实现有关，而且有些，但很少与BCL相关。例如，我在表单渲染中看到了相当大的不兼容性。

（请参阅：

https://en.wikipedia.org/wiki/Standard_Libraries_(CLI)#Base_Class_Library [ ^ ]，

https://en.wikipedia.org/wiki/Framework_Class_Library [ ^ ]。）



顺便说一句，违反标准的是双方，在Mono和微软上。当微软的实施是错误的（我遇到至少一个这样的情况）并且修复了错误时，它创建了不兼容性。



我没有发现它们之间的不兼容性针对不同操作系统的单声道实现（我使用的是Windows，Linux和Mac OS X），但不同操作系统上的运行时行为之间的某些差异是不可避免的。特别是，与控制台相关的系统架构部分在Linux和Windows中非常不同。命令行界面对于Linux（以及任何类型的* NIX）都是非常基础的，但不适用于Windows。



此外，.NET中控制台应用程序的概念以非常混乱的方式表达，尤其是在Visual Studio中。我不记得它是如何看待MonoDevelop的，但它的设计与VS非常相似。混淆导致认为应用程序被分类为窗口应用程序和控制台应用程序。事实并非如此。实际上，交换机只是说应该显示控制台。如果应用程序是控制台，则始终显示控制台，但应用程序可以同时是Windows应用程序，也可以是仅限控制台，或任何其他应用程序。如果应用程序类型不是控制台（而不是库），则控制台不会显示，但它可能会显示一个窗口，或者什么也不显示。请注意，在所有这些情况下，您可以使用 System.Console.Write ，只有没有控制台才能看到此类输出的结果。



我已经开发并测试了一些，比如说， System.Windows.Forms 应用程序，这些应用程序可以通过Mono和Windows通过Mono和Windows在Windows .NET，Linux上运行单声道以几乎相同的方式。他们没有在三个平台中的任何一个上显示任何控制台;和Mac OS X一样。你应该做正确的事情：找到合适的应用程序类型开关并按照你想要的方式使用它。



我希望我的笔记可以帮助您解决冗余/恼人的控制台问题。您没有提供任何相关信息，可以帮助我就您面临的其他问题提供建议。也许你应该在开发更大的应用程序之前利用早期的原型设计和测试。

-SA

You did not provide any relevant information on the project, so I cannot give you a recipe to overcome the problems, but there are things you need to understand correctly.

First of all, this is not cross-compilation. This is the compilation using different compilers for the same platform. .NET CLR and Mono are different implementations of the same platform. The fact that the assembly runs in the same way without recompilation is just one of the aspects of this fact.

At the same time, there is a number of incompatibilities between those implementations I've personally detected for different versions. I haven't use Mono for a while and cannot tell you any detail on the latest versions. However, all incompatibilities I saw are related to the implementation of some FCL types, and some, but very few of them were related to BCL. For example, I saw considerable incompatibilities in Form rendering.
(Please see:
https://en.wikipedia.org/wiki/Standard_Libraries_(CLI)#Base_Class_Library[^],
https://en.wikipedia.org/wiki/Framework_Class_Library[^].)

By the way, the violations of the standard was on both sides, on Mono and on Microsoft's. When Microsoft's implementation was buggy (I faced at least one such case) and the bug was fixed in Mono, it created the incompatibility.

I did not find the incompatibilities between Mono implementations for different OS (I used Windows, Linux and Mac OS X), but some differences between runtime behaviors on different OS are unavoidable. In particular, the part of system architecture related to the "console" are very different in Linux and Windows. Command line interface is very fundamental for Linux (and any kind of *NIX), but not for Windows.

Also, the notion of "console application" in .NET is expressed in a very confusing way, especially in Visual Studio. I don't remember how it looks for MonoDevelop, but its design is very similar to VS. The confusion leads to thinking that the applications are classified into "Window applications" and "console application". This is not so. In reality, the switch simply says that the console should be shown or not. If the application is "console", the console is always shown, but the application can be a Windows application at the same time, or console only, or anything. If the application type is not "console" (and not the library), the console is just not shown, but it may show a window, or nothing. Note that in all these cases you can use System.Console.Write, only the result of such output is not visible without console.

I've developed and tested a number of, say, System.Windows.Forms applications which worked on Windows .NET, Linux via Mono and Windows via Mono in nearly the same way. They did not show any console on any of the three platforms; and the same story was with Mac OS X. You should just do right thing: locate appropriate "application type" switch and use it the way you want.

I hope my notes can help you to sort out the problem with redundant/annoying console. You did not provide any relevant information which could help me to advise on other problems you faced. Perhaps you should utilize early prototyping and testing before developing bigger applications.

—SA

这篇关于使用MonoDevelop在Linux for Windows中进行交叉编译的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！