My google-fu has failed me - can MonoDevelop be used on Windows? Preferably without having to compile from source?
It works well on my home Ubuntu box, and while I have Visual Studio at work, it seems there might be some advantages to having MonoDevelop too.
EDIT: I'm aware of SharpDevelop; I'd prefer to have MonoDevelop if possible, just because I've started to get familiar with the interface, and I believe the SharpDevelop and MonoDevelop are not so closely related any more.
Woohoo! MonoDevelop for Windows is a supported download.
It seems that MonoDevelop on Windows still has a number of outstanding problems, even when built from source (and can only be built on .NET, not on Mono). So obviously there is no installer yet either.
The answer to my question then is No, MonoDevelop on Windows is not ready for normal use.
I guess I'll make do with Visual Studio and SharpDevelop on windows and wait patiently (or maybe even have a look at the outstanding bugs...!)
UPDATE: MonoDevelop for Windows now has a preview installer which can be downloaded here
MonoDevelop has official support for Windows since version 2.2:
Windows Support
Windows now Officially Supported
Windows is now an officially supported
platform for running MonoDevelop. Many
Windows specific issues have been
fixed, and some add-ins such as
debugging and subversion support have
been written specifically for Windows.
Windows Installer
We are releasing a new Windows
Installer which includes almost all
you need to run MonoDevelop. The only
external dependency is gtk#, which is
provided in a separate installer.
You can download the latest stable release.
Try SharpDevelop . MonoDevelop is built on SharpDevelop's code base.
There was a recent blog entry about MonoDevelop on Windows. Now is probably the time to try it out.
Update: MonoDevelop have just been released for Windows and Mac. More from Miguel's blog.
It's possible, but not easy. There's certainly not an installer.
This is pretty much the only guide to getting it to work:
http://lists.ximian.com/pipermail/monodevelop-list/2006-September/004442.html
Related
On our PC (under Windows XP there is MiKTeX, and it have been working well for many years. However, several month ago, after installing the latest version (setup from 09/16/2017), dvipdfmx stopped working reporting something like 'it is not win32 application'. It has been appeared that the problem is arisen by mgs.exe (ghostscript for MiKTeX). The first thought was that a 64-bit version of mgs.exe was mistakenly included into 32-bit MiKteX. However, it is appeared not the bug: MiKTeX team says that it is worked under 32-bit Windows 7.
I do know that officially MiKTeX now requires Windows 7 or higher (so, XP is not supported). However. it was perfectly well until the latest update, and even now latex.exe, yap.exe and others still work. So, the question: is it possible to go the problem around within XP?
Without knowing what the actual problem is, its impossible to offer any advice. When quoting errors it is important to quote the exact error message.
"Something like 'it is not win32 application'" is not precise enough.
This is also not a Ghostscript question, because 'mgs.exe' isn't Ghostscript, its clearly a fork of some kind.
My guess is that its the fact you are using an ancient version of Windows, most likely the application is no longer compatible with such an old version, possibly because whoever built it is using a newer version of Visual Studio.
In order to build Ghostscript for Windows XP I think you need to use Visual Studio 2005 or earlier, a more recent version will create an executable that will not run on Windows XP.
The only solution to this would be to build 'mgs.exe' with an older version of Visual Studio, or try the pre-built executable 'gswin32.exe' which is available from the ghostscript.com website in the downloads section. Obviously that's not the same as mgs.exe, but I can't help you with a fork since I have no clue what's been done.
The first thing to try is running 'mgs.exe' from the command line, if that fails to work then its almost certainly because the developer who built it used too recent a version of Visual Studio.
If this is the case then no, you can't fix it within Windows XP, you need to do one of:
1) Upgrade to a newer OS
2) Downgrade your MikTeX and live with the older version until you are prepared to upgrade your OS.
3) Rebuild 'mgs.exe' yourself using an old version of Visual Studio. This could be challenging because I can't find anywhere on the MikTeX website where they make the source files available. I've been to their Github repository and I can't find anything from Ghostscript there either. I'm going to have to contact the developers, they are not using a stock version of Ghostscript, they do not appear to make their revisions available, ansd although they correctly reference Ghostscript as AGPL I cannot see anywhere in the install or their Github repository which lists Artifex as the owner or points to the Artifex website. They also don't copy the Licence or readme files (slapped wrists for them).
I was going to try using the regular Ghostscript instead of the modified version, but I don't have know anything about MikTeX so I have no way of testing whether that works. It looks to me like it probably would, since it appears that MikTeX forks Ghostscript as a process. So copying and renaming the 64-bit Windows version of Ghostscript's binaries would probably work.
As you note, the developers state themselves that they no longer support Windows XP.
I have a problem that Qt doesn't let me create Qt application - there is no such option in "New Project" - but only under my Windows. Under Linux it works like a charm.
I have installed package Qt+QtCreator from official Qt's download page.
I have already looked it up on google and I found answers here, on stackoverflow, but everybody suggest to add Qt to build toolkits in configuration. That's not problem in my case - QtCreator detects my Qt automatically and correctly:
This still doesn't let me create Qt app:
(it's in polish, but it says that only possible projects are non-qt and imported projects).
I have checked if qmake.exe pointed by the Qt that QtCreator is using works - yes, it works.
What else can I check/do?
Based on your comment, it seems that you are using Windows XP. That is not supported anymore. It was dropped a while ago. It may or may not work, but overall, it would be bad experience in the majority of the cases because things like your issue is also somewhat fundamental.
The currently supported Windows variants are Windows 7 and 8. I think it is a wise decision to upgrade if you can or look for an Integrated Development Environment that is still well supported on Windows XP. That means you could also get an older version of QtCreator, but it would probably be behind Qt 5 feature support now.
The problem here was the Windows XP. Using more recent Windows version fixes the problem.
You can downgrade Qt to latest version which supports Windows XP (OpenGL?), AFAIK v5.1.1. It can be installed via current online installer.
Edit: but I found it's pretty unstable (hence I using Qt running on Linux via VirtualBox).
Can someone give me a link where i can download a gtkmm 3.0 library for development without need to build it by myself?
thanks
http://live.gnome.org/gtkmm/MSWindows
That is the best I could find. It stops at 2.8, tough.
http://mail.gnome.org/archives/gtkmm-list/2011-April/msg00077.html
That is an email to the gtkmm mailing list from the windows installer developer. It seems that the dev doesn't have much time for it right now (or at least didn't on April 28, 2011).
Not much help, but that seems to be the state of gtk+ and gtkmm on windows right now.
The original question is old, but I post here for future visitors.
Apparently the link specified in senshikaze's answer is broken.
Windows installer (for both runtime and development stuff) is available from ftp.gnome.org
32-bit
64-bit
I built the gtkmm binaries over official gtk 3.6.4 binaries.
For 32 bit version you can download the binaries that I created, and there is also the (simple) procedure to create them yourself if you need 64 bit, everything on http://www.giuspen.com/2014/02/build-gtkmm-3-6-0-windows-binaries-on-official-gtk-3-6-4-bundle/
Gtk 3.0 library for windows is at hand from http://www.gtk.org/download/win32.php/
And you could find more optional dependence on http://win32builder.gnome.org/
But Gtkmm 3.0 hasn't have an official release, but some volunteer make it, I find a good one, http://sourceforge.net/projects/tview/files/gtkmm_bin_3_6.7z/download
I created a blog on how to install latest gtkmm on Windows (step by step) here:
http://gtkmm-installation.blogspot.com/
UPDATE:
I have just compiled everything with Visual Studio, You can download my gtkmm3 development binaries for Windows x64 from my GitHub page, I also made a wiki entry on how to compile everything on your own with Visual Studio.
All of the Visual Studio projects to compile everything can also be found on GitHub.
You can install it with vcpkg.
I'm using Microsoft Visual Studio 2008 (VC9) to compile a project that has a .dsw file. I already have the 2010 and would prefer to use it, but it seems this dsw was built for 2008.
I'd like to compile and produce a binary that's also compatible with Windows 7. My questions:
if I compile with 2008, will the resulting binary be compatible with Windows 7? I'm not sure at which version of VS did Windows 7 support start.
or does this have nothing to do with the VS version, and is instead related to the Windows SDK? If that's the case, can I use VS2008 with a newer Windows SDK?
Can someone please clarify.
Microsoft has a great backwards compatibility "story", so pretty much anything you compile with any version of Visual Studio/Visual C++ will be compatible with Windows 7. The same may not neccessarily apply in reverse, i.e. if you use an API that's introduced in Windows 7, your application will error when you try to run it on prior versions of Windows.
There are a couple of things to consider though:
If the project was originally written to target Windows XP or earlier, it may fall foul of UAC
There are changes to directory structures (such as %systemdrive%\Documents and Settings becoming %systemdrive%\Users) that are fairly well handled by the link that Windows 7 creates in the root of `%systemdrive%, but you may fall foul of these.
VS2010 includes version 7.0 of the Windows SDK and VS2008 does not. You need Windows SDK v7.0 if you want your app to take advantage of Windows 7 features like jump lists.
Since you already have VS2010 installed, you can just change your include file / lib file paths in VS2008 to point to the Windows SDK v7.0 instead of the default one provided with VS2008. This is assuming you need that version of the SDK.
You do not need the latest Windows SDK if you do not plan to use the latest Windows 7 features like ribbons and jump lists. If you are building your app for the lowest-common-denominator OS (i.e. Windows XP), then really you should be fine using VS 2008 with default settings.
The other concern is, if your code was originally written before Windows Vista came out, it is likely that it will not work properly on Windows 7 unless it is run in Administrator mode, which is something you want to avoid. The only way to fix that is to rewrite much of your code to avoid writing to certain protected directories and avoid using certain APIs that require Administrator privileges.
Windows SDK is well backward compatible. See binary compatibility report between Windows 6.0 and Windows 7.0 on x86_64 generated by the abi-compliance-checker tool for the detailed comparison.
Reports for other Windows versions are here: https://abi-laboratory.pro/index.php?view=windows
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed last year.
Improve this question
I started trying to play with Mono, mostly for fun at the moment. I first tried to use the Visual Studio plugin that will convert a csproj into a makefile, but there seemed to be no version available for Visual Studio 2005. I also read about the MonoDevelop IDE, which sounded nice. Unfortunately, there's no pre-fab Windows package for it. I tried to follow some instructions to build it by combining dependencies from other semi-related installs. It didn't work, but that's probably because I'm a Windows-oriented guy and can barely spell "makefile".
So, my question is this: What's the lowest-energy way to get up and running to try some Mono-based development on Windows?
I'd recommend getting VMWare Player and using the free Mono development platform image that is provided on the website.
Download Mono
Setup time for this will be minimal, and it will also allow you to get your code working in .NET and then focus on porting issues without a massive hassle of switching machines and the like. the VMWare Player tools will allow you to simply drag and drop the files over to copy them.
I'm looking to take a couple of my .NET apps and make them Mono compliant, and this is the path I'm going to take here shortly.
A year later and the answer to this has change greatly. You can now use MonoDevelop on Windows, or if you are more comfortable in Visual Studio you can use the Visual Studio Tools to write everything and then debug on in VM to make sure it is working on Linux.
#Chris I have found that Visual Studio is the best IDE for developing against .NET -- I think the best way to target Mono is really just to develop and build in Visual Studio under Windows then just run those binaries directly on Linux (or whatever other Mono platform you are using). There are free versions of Visual Studio if licensing is a concern. If you are developing under Linux, the best software is probably Eclipse with a Mono plugin (see The Mono Handbook - Eclipse for installation instructions) but keep in mind it doesn't have near the amount of features or language integration Visual Studio has.
#modesty Mono is a 3rd party open source implementation of the .NET framework which allows you to run .NET applications on platforms other than Windows.
One of the best things you can do if developing with Visual Studio for Mono is to get MoMA http://www.mono-project.com/MoMA. This will inspect any number of assemblies that you build and generate a report showing potential Mono problems (e.g., methods not implemented in the mono library). It can be run from a GUI or the command line for use in automated builds.
Miguel had a post about debugging Mono running on linux with remote debugging on Visual Studio. This may be something you want to look into... Using Visual Studio to debug Mono. There is also a new project called CloverLeaf whose goal is enabling debugging Mono on Windows in Visual Studio.
There's just no reason to build your app using Mono; the whole point of the .Net CLR is that the compiled output is cross-platform.
So you can simply build it using your favourite IDE (and if you like IDEs, Microsoft's is the best one to use) and then test it on Mono. Even if you get Mono working on Windows, it wouldn't be a very good test of your app's portability: what if your app does silly things like assuming filenames have backslashes in them, or that there's something special about a folder called Program Files? The best way to do portability testing is to actually test your app on the target platform.
And that's pretty easy to do with a Linux VMware player like the one at http://www.go-mono.com/mono-downloads/download.html.
Personally, I'm just compiling in Visual Studio 2008 as if it were for .Net 2.0 and then running in Mono (VS2008 on Windows in a VirtualBox, Mono on OSX). All the problems come up at runtime, anyway, so the system works perfectly.
I just found this very new link, which is amazing and shows you how to set up Visual Studio 2008 for Mono.
At the same time, setting up Mono on OpenSuse or Ubuntu inside a VirtualBox (Sun's product) is easy, painless, and doesn't force you to abandon whatever platform you normally live in.
This is not relevant to your question, but I might note that I just got into Mono and I'm amazed at how much of .Net is implemented, including much of the Winforms stuff.
My first instinct would be the rather unhelpful "Install Linux". You are somewhat swimming against the current to try and develop in mono under windows. Installing GTK and everything is a bit of a bother in my experience.
If you do feel like using linux, then you could Try Ubuntu
Otherwise:
There's some information here: http://www.mono-project.com/Mono:Windows and it seems the cygwin toolchain might be your best bet. I don't think you're going to be able to avoid makefiles, sadly. I found a slightly more explicit tutorial from O'Reilly.
#modesty: Mono provides the necessary software to develop and run .NET client and server applications on Linux, Solaris, Mac OS X, Windows, and Unix. Sponsored by Novell (http://www.novell.com), the Mono open source project has an active and enthusiastic contributing community and is positioned to become the leading choice for development of Linux applications. -- From the Mono site.
Eclipse plugin for Mono is dead. On Linux use MonoDevelop or X-Develop if you like good commercial support (although MonoDevelop is closing on them fast feature-wise). On Windows SharpDevelop has custom MSBuild targets for compiling the code against Mono.
As Mono and MonoDevelop are changing fast, be sure to use the latest released versions, even if they are not marked as stable yet (e.g. versions shipped with stock Ubuntu are terribly outdated).
The VMWare image is a great way to start testing Windows-developed code on Linux. Don't touch cygwin unless you are already very conformable with it.
I liked the idea of trying to use MonoDevelop mostly just to make sure my stuff would work against the Mono runtimes. I guess it would also be possible to get crazy with msbuild and write some custom targets that tried to build against Mono, but that's basically emulating the now-defunct plug-in's functionality which I assume was non-trivial to build. I do have minor experience with cygwin, and I am happy typing "configure" and "make" all day long, but when a problem occurs in that process, I'm virtually screwed. I'll probably try to play with all this again, but if it takes me more than a couple hours to come up with a way to build comfortably against the Mono runtimes, I'll probably just bail.
I will try the Eclipse idea. I use that for Java, so I might be able to get the c# stuff to work. We shall see...