Chris Cyvas

In my last post, I profiled what you would need to do to get Visual Studio to use the Mono compiler for compiling your Mono projects. I also created 3 basic Mono project templates that are available for download.

Apparently, they have some appeal as they have been downloaded a couple of hundred times, so that’s good. Also, it looks as though Mono is getting some additional traction and good looks from others in the Microsoft community. That is good, it should.

I have also made it a priority for dashCommerce to run on Mono in future revs as I think this is a huge win for software products in general, but especially so for open source projects.

But, one thing that I left out of the previous post was some Mono item templates. Specifically, some standard stock templates because if you add a stock item (like a Web Form) to your project that references .NET assemblies, you will get this lovely little creature when you compile:

Which is basically telling you that Mono has no idea what the heck the referenced assembly is! So, how to fix it? Well, you need some item templates that reference the Mono assemblies and not the .NET assemblies.

I have gone ahead and created the following templates for use in your Mono projects:

• Class
• Interface
• Master Page
• Web Content Form
• Web Form
• Web Service
• Web User Control

You can download these item templates from here (as well as the Project Templates). Once you download them, you can put them in My Documents\Visual Studio 2008\Templates\ItemTemplates\Visual C#\Mono and you should be good to go.

That being said, there was a recent Beta release of MonoDevelop 2.0 and I am hearing good things about it, so all this may be for naught if it is a solid IDE, but I am easing into this and frankly, I think MS and Visual Studio should support development on the Mono platform. But maybe that’s just me.

As it stands, Visual Studio does not allow you to explicitly target a framework other than the .NET framework. I cover that in this post, so if you are curious about that, then you may want to go read that first to understand where this post is coming from. But thankfully, Jason left me a comment that pointed me to this post by Jonathan Pobst. It was a big help in researching this post and basically set me on the right path to getting things to where I wanted them.

The goal was to get some Mono project templates working with Mono assemblies and the Mono compiler in Visual Studio. The trick was to do it in a way that would be able to survive upgrades of Mono installations. I think I pulled it off. The end result is a series of project templates that you can put in your \My Documents\Visual Studio 2008\Templates\ProjectTemplates\Visual C#\Mono directory that will give you the following New Project options:

Notice the Mono option on the left hand side of the dialog and the Mono project types in the right hand side. Yep, that’s the little Mono monkey there too.

In order to use these, you are going to have to do a few things:

1.) Download and install Mono. I installed the current release (2.2) to C:\Mono\2.2

2.) Add a MonoPath environment variable and have it point to C:\Mono\2.2\bin

3.) Add a MonoLibPath environment variable and have it point to C:\Mono\2.2\lib\mono\2.0

4.) Reboot so the environment variables will be recognized

5.) Grab the download at the end of this post and unzip it. In it, you will find 3 project templates and 1 file called Mono.CSharp.targets.

6.) Place the 3 project template files (.zip) in the \My Documents\Visual Studio 2008\Templates\ProjectTemplates\Visual C#\Mono directory. You’ll have to create the Mono directory.

7.) Now, grab the Mono.CSharp.targets file and place it in the C:\Mono\build directory. Again, you will have to create the build directory.

8.) Now, fire up Visual Studio and bring up the New Project dialog. You should see something similar to the New Project Dialog above. (Note: If you don’t see the Mono option in the left side of the dialog then you may need to add the Mono directory to the \My Documents\Visual Studio 2008\Templates\ItemTemplates\VisualC#\ directory as well – see here – otherwise, you may only see them at the top level C#.)

9.) Now, go ahead and select one. You will get prompted with the following prompt from Visual Studio. Make sure you select the Load Project Normally option.

That should about do it. You will now be creating Visual Studio projects that reference the MonoPath and the MonoLibPath, so as you upgrade and wish to move from version to version, all you should have to do it change your environment variables and you will be compiling against the latest version of Mono and using the Mono compiler. (Presumably something like C:\Mono\2.4)

Now, some may point out that Mono is binary compatible with .NET so what’s all the fuss? The answer is that they are in different stages of development, so if you target the .NET framework and then try to run on Mono, you may end up with some gotchya’s. For example, a class or method call that is not yet implemented in Mono. Whereas if you target Mono, then you can be pretty assured, when referencing a System.*.dll it will be implemented in .NET. Also, if you use any of the Mono.*.dll assemblies in your projects, you’ll can just drag them around like any other referenced assembly. There are about 20 Mono.*.dll assemblies, so there is bound to be some goodies in there.

If you already have Mono installed somewhere, then you should be able to point your environment variables to the relative locations of your installation and you should still be good to go.

 Download.

  While writing this, I was listening to "Jane Says" by Jane’s Addiction

In my planning to get ready for Mono development, I’ve been looking at different ways to get up and running. I’ll be putting together a screen cast of this work, all distilled down so hopefully you will be able to avoid some of the pain, musings, and cursing that occur during this process. Although, I can say, from my experience, that this is a characteristic that has served me well professionally: I don’t mind muddling through the uncharted stuff. BUT, it is an enormous PITA, and I can sympathize greatly with those that are not too eager to do it. I also understand it really is a matter of how interested you are in figuring it out; it being the task at hand.

The first thing we have to look at is getting an infrastructure in place that supports our development. In the Windows / Visual Studio world, a lot of that is pretty simple to get running, especially now that VS ships with a built in web server. I have always used IIS as much as possible, but the built in web server works ok for local development.

I’ve got Mono

But in Mono world, we have some different opportunities to extend our development experience. For instance, you can run Mono and Linux in a virtual machine. Here you have several options; you can pull down a Linux distribution, install it to the VM and then install Mono via the Linux Repositories. For those of you just getting into the Linux world, the Repositories are central locations from which you can choose to install other open source software packages. When I read about the Linux Repositories that immediately gave me pause, because that’s a pretty huge win for Linux. Unfortunately, I don’t think Windows could ever execute on anything like that because of the nature of the Windows ecosystem.

Another option is to install the VM from Mono that is a full openSUSE Linux distribution with Mono and MonoDevelop already installed. For those looking for speed in getting up and running, this is probably the best way to get up and running.

In my first attempts, I went with the first route because I was curious to learn some more about Linux and I wanted to see how far the distributions had come since the last time I worked with them – back in 2000.

Well, let me tell you, they have come a long way, baby.

If you’ve got the time or inclination, I highly recommend picking a virtualization software package and running some Linux distro installs and playing with them. So far I have openSUSE, Ubuntu, Ubuntu Server, and I think I have CentOS queued.

But, I do like Visual Studio and I am comfortable with it. I’ve looked at other IDE’s and for whatever reason; I don’t find them as good as Visual Studio. I recognize that may not be the case, it may be my hang up. So, I’ll be actively bouncing around IDE’s to challenge myself a bit on the IDE front. So, I’ve got a bit of a conundrum. I like Visual Studio, and I’d like to continue to develop in it, but I need a setup in my Windows environment that can support my preferred development experience. So, I started digging into how to get Mono running on my host Windows OS and what other tools I will need to support that development process.

My initial take was to look at using the XSP2 web server that is included with the Mono install. This is probably something akin to the web server that is installed as part of Visual Studio. I got things setup and working ok, but it’s a very small application and is not very robust (their words, not mine). For e-commerce I wanted to make sure I had something that was of the same caliber as IIS or better. This brings me to Apache. I’ve installed the Apache HTTP server and the install was painless and all good. I did have to turn off my IIS service because they both wanted to hog port 80. You can probably configure this to be different, and I may yet do that, but I want to “disable” my old habits as much as possible. Sometimes you have to force yourself to learn. It looks like I’ll be able to target the Apache HTTP Server for use by Visual Studio as well, since this is in the Project Properties dialog:

Finally, I want Visual Studio to use the C# compiler for Mono, not .NET, so I figured I could do that by changing the target framework. My hope was that Visual Studio would allow me to target Mono as the development framework, and use the Mono compiler as part of that targeting process. Alas, that does not appear to be possible at this point:

So, I think I have to dig in a little deeper to find out how to control what C# compiler Visual Studio uses to see if I can change that. Presuming I can, I then need to setup the virtual directories and such in Apache so that my development experience is as seamless as possible. I don’t want to “feel” these changes, but I know there is some work to do to get the development experience to be something close to what I am used to. Note to the VS.NEXT Team – I know you’re using MEF and MSBuild under the covers, so you should be able to allow this pretty easily.

So far, all of this has been pretty painless and has been more of an exercise in “figuring things out” than anything else. The installs have been painless and have caused me no grief. Things appear to be pretty stable so far.

If anyone is going to “walk the walk” with me, I’ll be putting up some screen casts that go into more detail on all of this stuff, so you may find more info there. I’m waiting on a few key pieces for my screen cast setup that I want before I start pushing things out, but they’ll be coming pretty soon – within the next few weeks.