Make XenCenter compile / run with mono
hoerup opened this issue · 40 comments
XenCenter is a great tool unfortunately it's windows only. It would be greate if it could compile and run on mono so it can be used on OS X and Linux.
(I tried during the weekend and with Mono 3.0.12 + a few modifications I got the source to compile but didn't succeeed in getting the binary running)
Could you post what you did to make it compile, and the specific error
message you get when you try to run it? Thanks!
On Monday, July 15, 2013, Torben H. Nielsen wrote:
XenCenter is a great tool unfortunately it's windows only. It would be
greate if it could compile and run on mono so it can be used on OS X and
Linux.(I tried during the weekend and with Mono 3.0.12 + a few modifications I
got the source to compile but didn't succeeed in getting the binary running)—
Reply to this email directly or view it on GitHubhttps://github.com//issues/3
.
Dave Scott
With this commit it at least compiles:
https://github.com/hoerup/xenadmin/commit/dca9a0e80069d10c7a74fcf76cdd016ddc08e47e
XenCenterLib/Win32.cs +
XenAdmin/Core/Drawing.cs
and other modules with DllImports doesn't exactly improve portability
ComponentResourceManager::ApplyResources also has troubles under mono
#if !MonoCS
resources.ApplyResources(this.tableLayoutPanel1, "tableLayoutPanel1");
#endif
This is more of a mono bug than a XenCenter issue but the call to Properties.Settings.Default.Save();
in Settings.Cs :: TrySaveSettings() dies in a NotImplementedException() thrown in https://github.com/mono/mono/blob/master/mcs/class/System/System.Configuration/SettingValueElement.cs Unmerge() function.
This has the effect that all attempts to save data fails (and the function aborts)
In my first assembly also had problems with the character case and exception types. Now do rebuild with mono 3.1 and monodevelop 4.1.4. Maybe things will improve.
Built, but now when running:
Unhandled Exception:
System.TypeInitializationException: An exception was thrown by the type initializer for XenAdmin.Program ---> System.NullReferenceException: Object reference not set to an instance of an object
at XenAdmin.Program..cctor () [0x0009b] in /home/oleg/proj/xenadmin/XenAdmin/Program.cs:101
--- End of inner exception stack trace ---
[ERROR] FATAL UNHANDLED EXCEPTION: System.TypeInitializationException: An exception was thrown by the type initializer for XenAdmin.Program ---> System.NullReferenceException: Object reference not set to an instance of an object
at XenAdmin.Program..cctor () [0x0009b] in /home/oleg/proj/xenadmin/XenAdmin/Program.cs:101
--- End of inner exception stack trace ---
bump for awareness
What the hey, I'll bump it too. :)
We (the maintainers) would be very happy if anyone wants to look at this! We saw this as one of the possible benefits when we open-sourced the code.
+1 It would be great to have XenCentre run under OSX, currently our admins have to run windows VM's and pay for licenses to Microsoft just so we can run XenCentre.
+1 it would be great implementation.
Jahsis sammcj natecarlson and krono: Bump's or +1's doesnt do anything helpfull to get this resolved. The only helpfull thing to do is creating patches / pull requests
Here are the package requirements for mono under linux: (Add->Add packages in mono develop)
XenCenterLib:
- DotNetZip
- log4net
XenCenterVNC:
- log4net
XenModel
- log4net
- XML-RPC.net
XenOvfApi
- log4net
XenOvfTransport
- log4net
- Discutils
Anyone who tries this is welcome to post how far they got on this thread. (There are also some observations in thread #106, mentioned above).
@hoerup mentioned in that thread:
One thing is getting the thing to compile - getting it running is a whole other task.
The case correction is a first and mandatory change to get it compiling. In order to get the thing running all DllImport'ed functions must be replaced by native .net functions - which is a major task and that's where I stranded
which matches what I've heard: that people have got it to compile, but no-one has actually got it working. But maybe with a combined effort, we may get further.
This looks like it could be a useful tool to see what areas would require attention to make XenCenter portable: http://mono-framework.com/MoMA
MoMA turns up some interesting results and points out quite a few non-portable functions used. You can grab a copy here: http://www.unixzen.com/patchwork/MoMA%20Scan%20Results.pdf
Looks like 100% of the problems are from Microsoft.ReportViewer
BTW, if you need to manage XenServer now from Linux, https://github.com/OpenXenManager/openxenmanager is working pretty well.
Since the release of XenCenter 6.5 I've tried mono again. I had to add a dllmap for uxtheme to one provided by wine. As far as I can tell it's finding everything else it needs.
Does it still need DotNetZip and XML-RPC.net? I don't have those, but I didn't see an attempt to load them either.
I ran MONO_LOG_LEVEL=debug mono XenCenterMain.exe and the last message was:
[ERROR] FATAL UNHANDLED EXCEPTION: System.TypeInitializationException: An exception was thrown by the type initializer for XenAdmin.Program ---> System.NullReferenceException: Object reference not set to an instance of an object
at XenAdmin.Program..cctor () [0x00000] in :0
So still no luck.
Thanks for trying, Michael. We certainly need XML-RPC.NET for communicating with xapi: that's the wire protocol. DotNetZip is used for certain input and output operations (e.g., OVFs, and Server Status Reports), but you might not come across it if you didn't try everything.
By the way, all the dependencies are available at https://github.com/xenserver/dotnet-packages.
Yeah, I'm trying to run the Windows binary from Ubuntu 14.04 with mono. Took a bit of poking around, but it looks like all the dependancies are included.
I guess the next step would be trying to compile from source. But OpenXenManager is working well enough for now, there is a package for it in Ubuntu. Next time I have nothing else to do I can give it a try.
Here is the current failure in mono.
@kallisti5: I hacked this error somehow (sorry, don't remember now), but after compiling I'm getting the same result as when @mdhafen runs it via Wine. I compiled Debug build, but I've got no line text nor line number where NullPointer was raised ;\
I dont know if this helps. But I was able to get this working on ubuntu 15.10 following these steps.Link
I downloaded the source about 2 weeks ago and step by step compiled the various modules, adding dependencies as I went along. All compiles worked, but on the final step (compiling XenAdmin), the compile succeeded, but the link failed. It seems to be a Mono library bug and I reported it as such. The error follows:
Tool /usr/lib/mono/4.5/resgen.exe execution started with arguments: /useSourcePath /compile "Dialogs/ConfirmVMDeleteDialog.resx,obj/Release/XenAdmin.Dialogs.ConfirmVMDeleteDialog.resources"
/usr/lib/mono/4.5/Microsoft.Common.targets: error : Tool exited with code: 1. Output: Error: Exception has been thrown by the target of an invocation.
Inner exception: Member 'ListViewItemCount' was not found.
I got the idea of searching source code and source code of dependencies (XML-RPC, log4net, dotnetzip and discutils) in the hope to find ListViewItemCount in order to attempt a workaround. Unfortunately it seems not to be referenced anywhere.
Build output is attached. If anyone knows about a workaround, I'll be glad to hear about it.
build-output.txt
My setup:
Ubuntu 14.04 x86 with latest updates
MonoDevelop 5.10
Mono 4.2.3.4
That's great, @johnbester. I think you've got further than anyone else has managed. Let us know what the Mono developers say.
The bug I reported with mono / xamarin can be found here: https://bugzilla.xamarin.com/show_bug.cgi?id=40237
+1 any update on this? OpenXenManager hasn't really progressed at all and is very unstable, it's really annoying having to run a Windows VM just for XenCentre
Update on my attempt to build XenAdmin using MonoDevelop. I was looking for the ListViewItemCount in sources but could not find a reference to it. So I downloaded the sources for the various 3rd party dependencies and built them individually using MonoDevelop. (I should not that I installed mono 4.5.1 and used that as runtime where I could). Then I built XenAdmin dependencies (projects that forms part of XenAdmin) and finally I build XenAdmin. The log output is different and there is a NullReferenceError caused by System.Windows.Forms.ListViewGroup. I have tried to comment out all code that seems to reference ListViewGroup in some way (ConfirmVMDeleteDialog.cs and ConfirmVMDeleteDialog.Designer.cs) and did a rebuild hoping that I would have a XendAdmin with one dialog not working properly. But this dit not work unfortunately. I have updated the bugreport on mono bugzilla mentioned in a precious post.
Some more news. If you take out out "XenAdmin/Dialogs/ConfirmVMDelete.*" from the project source and delete references to it from the XenAdmin.csproj, the project builds without errors or exceptions using Mono 4.5.1. However, no exe is produced. I did specify a main class, but I'm afraid my MonoDevelop / C# skills are too limited to know where to go from here. My skills lie mostly in Java and PostgreSQL, so if there is someone who can assist with MonoDevelop or mono build, maybe we can get a running version - even if you cannot delete vms.
johnbester: I filed a pull request to get the Mono build a lot further. The issue with XML-RPC was that it required 2.5.0 XML-RPC.NET vs 3.0.0
As for the ListViewItemCount issue, did Mono ever respond to that bug? I don't have "permissions" to see it in their bug tracker which is really quite odd.
As a matter of fact, no they have not responded. I posted 3 follow-ups on that bug but have not heard anything. However, I am almost certain the ListViewItemCount bug was fixed in the latest Mono version I tested (4.5.1). (I do think I tried to build it before I took out ConfirmVMDialog and got the Null reference exception and not the ListViewItemCount problem). On the permissions issue, I cannot not see the bug report until I have logged in using my Bugzilla account.
I have found a small issue for which there is a simple workaround. I have managed to compile an exe on Ubuntu by commenting out some code. When I started the app, I got a null pointer exception on Progam.cs on line 107. This can easily be avoided by changing FormFontFixer on line 105. Simply change "null" to SystemFonts.DefaultFont.
Another problem I found in Linux is that the uxtheme library cannot be loaded, which means IsAppThemed() fails. What I did to get round this is to wrap the call to IsAppThemed() in a try-catch block and set IsThemed to fails in the catch section (line 177). This gets us past that problem, but the next problem is that GuiGetResources is not found. I have not read up on this yet.
I have made some more progress. The exe was never built - even though there were no errors during the build. I found that I had to install both mono-complete as well as msbuild for an exe to be built. I used grep to determine the names of all native dlls loaded dynamically and found versions of them provided by Wine. I built the exe, created an NSIS installer and installed the app in PlayOnLinux. I think the native dlls that are used makes it unlikely that XenCenter will run only using the mono virtual machine. I have been able to start XenCenterMain.exe from PlayOnLinux (you have to install dotnet40 libraries - for some reason dotnet45 did not work - hash sum mismatches and install seems to freeze at some point). The main screen appears but adding a server does not work (connection just times out). So to go further, I think I need to be able to debug the app from MonoDevelop when it runs under PlayOnLinux. I am new to MonoDevelop, so any assistence in this regard would be very much appreciated. If someone else is willing to put it some time, I'd be happy to help with the project setup.
There currently are two issues that makes changes to the source code necessary. The VMDeleteDialog causes a compile issue that I have mentioned before, but it has not been rectified in Mono yet. So you have to comment out some code in order to not include this dialog. The second issue is the Export class used in ExportVMAction. I initially thought it was a circular dependency to XenOvfTransport, but it seems more likely to be the Export class in System.ComponentModel.Composition.Primitives. When I add a "using" clause, the Export class is found, but not the methods of that class that are used. So either I have the wrong export or the Export class has not been fully implemented for Linux, or the Export class that should be used simply does not exist for Linux at all yet.
These two (Mono) issues aside, it would be very handy to have precompiler directives in the master branch to exclude code not working in Linux. This at least would allow Linux contributors to periodically check if there is any progress. I could also contribute the nsis build script to build an installer for PlayOnLinux.
I have a proposal about native DLLs. In stead of using DllImport all over the place, I suggest that native methods be wrapped in an adapter class that loads and calls the operating system functions. This will bascially allow a Linux contributor to do a linux wrapper functions that will in the end allow the app to be run in Linux directly in stead of Wine or PlayOnLinux. I am not an expert in Linux native calls, but I have written many adapters and could contribute the code to have a Windows implementation and an empty Linux implementation where others can contribute to call the correct Linux native method if possible.
The only reason my whole team currently has to run a Windows VM is for XenCentre - I'm definitely keen to see this happen!
There is some "progress": xcp-ng#23 (comment)
I decided run the XenCenter on Wine, after some difficulties, i got and decided to share it. If are interested https://github.com/aldebaranbm/xencenter-playonlinux.
Stability: For me, it is very stable, I make some imports and exports (files ~ 300gb with export verification), create new VMs, manage network, apply updates and use console without errors. In this week i upgraded my server with XCP-ng 7.6 (before it's XenServer 7) and the XCP-ng Center works normally.