Got Mono? Visual Studio Does

khess 0 646 Views

Today, Tuesday November 10, 2009, Novell announces a Visual Studio plugin that allows support for non-Microsoft operating systems that use .NET code development on a platform known as via a new product called . This is not a cost free toolset. In fact, it's really quite --starting at $99 for the Professional (Individual) version. Of course, compared to the exorbitant price of Visual Studio, that's a mere pittance.

If you can afford Mono Tools, it's a powerful addition to your Visual Studio environment. Using Mono Tools, you can create and test your .NET applications directly on Linux--just as you would when using a Windows host. You can also build installable .NET packages for Linux and even bundle them with Linux appliances* for easy distribution.

The downside is that, it seems, you must be sold on the SUSE Linux distribution. From Visual Studio, you create your applications as SUSE rpm packages. I think that the tools should be distribution agnostic to appeal to a wider audience but perhaps that is a hangup that only I have. You should be able to select which type of package you want to use for your application and not live with the SUSE-only limitation.

Limitations (and pricing) aside, I think that Mono Tools for Visual Studio is an excellent set of tools for your Visual Studio development efforts.

What do you think? Do you think the SUSE-only limitation is too great for widespread adoption or do you think it's OK?

* Appliances are small, single task virtual machines.

Dani AI

Generated

rightly calls out the distribution-lock risk in a VS→Mono workflow, and ’s mention of Alien is a practical quick fix. The real decision is tradeoff-based: quick conversions get wider reach fast, but long-term support, updates and system integration favor native or runtime-contained delivery.

  • Build native packages for each target distro when long-term support and upgrade behavior matter. Native packages integrate with the host package manager, handle dependencies cleanly, and make upgrades predictable. Use automated builders and clean chroots/VMs so packages are reproducible.
  • Use package conversion (Alien) as a stop-gap for testing or small deployments. Converted packages often need manual fixes: maintainer scripts, dependency names, and filesystem layout can differ between formats.
  • Ship a distro-agnostic tarball or self-extracting installer for simple apps. This avoids package-manager complexity but gives up automatic upgrades and tight system integration.
  • Bundle the Mono runtime with the app (for example with Mono’s bundling tools) to reduce runtime dependency issues. This increases artifact size and requires attention to native library compatibility and licensing.
  • Provide an appliance or container image for full-stack reproducibility. Containers (or virtual appliances) deliver identical runtimes across hosts and sidestep most distro packaging differences.

Critical checklist before wide distribution:

  • Install the package on a clean, minimal image for each target to detect missing deps or bad scripts.
  • Verify pre/post install scripts and service units behave under the target init system.
  • Confirm dependency names and versions (RPM vs DEB naming often differ).
  • Test SELinux/AppArmor and filesystem permissions where applicable.
  • Automate builds and tests (CI) so each package is rebuilt and smoke-tested on every change.

In short: ’s Alien route is useful for rapid reach; for production, prefer either native packages per distro or runtime-containing artifacts (bundles or containers) to avoid brittle installs and to simplify ongoing maintenance.

Member Avatar for jbennet
jbennet 1,618 Most Valuable Poster

t seems, you must be sold on the SUSE Linux distribution. From Visual Studio, you create your applications as SUSE rpm packages. I think that the tools should be distribution agnostic to appeal to a wider audience

You could turn them into DPkg .deb packages with Alien for example.

And why pay? Cant you just use mono with visual studio anyway? I mean, it does support other compilers... I use Visual studio for C++ using the GNU Tools (MinGW/MinSys & CygWin)

And there is always the free SharpDevelop mono IDE which is basically Visual Studio anyway.

Edited by jbennet because: n/a
Member Avatar for khess
khess 95 Practically a Master Poster

Maybe the "official" Mono Tools goes to 11. Surely Miguel de Icaza knows about the free ones. He is the main guy for this toolset.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.

Edit Preview