Proposal for a Prj2make# Visual Studio Add-in

I have begun writing a Visual Studio .NET Add-in that will be a good companion for Mono and hopefully assist in the deployment of source code archives that can be compiled at their destinations without the need of having Visual Studio installed. My original design goals are modest and few. The add-in will:

• Be a self contained unit with as few external dependencies as possible.

• Create Makefiles suitable for nmake.exe and/or gmake.

• Import MonoDevelop Solutions.

• Generate or Export the current solution to MonoDevelop.

• Test in Mono.

• Provide a GUI facility to change settings and the like for the add-in itself.

SELF CONTAINED UNIT

Now let me do a quick elaboration on some of the points above. The first bullet talks about being self contained. By that I mean to have the MSI (or the more likely NSIS) package use to distribute and installed the add-in have nothing more than a single library assembly (.dll). I don’t want to have dependencies from binary versions of prj2make-sharp stand alone programs or conflicts with it if it resides on the same computer.

CREATE MAKEFILES

Nothing else is required, to create Makefiles that target the nmake.exe build tool. However, when generating Makefiles intended to be used by gmake in *NIX environments, I may provide a setting for users to specify the base directory where Mono 1.0 should be found. The setting will be pre-populated with /usr/lib.

IMPORT AND EXPORT MONODEVELOP FILES

The other very important option that will benefit both Visual Studio .NET users as well as MonoDevelop users is the “Import” of MonoDevelop solutions. My goal for this one is to present an Open File dialog box that will allow a user to select a *.cmbx (MonoDevelop solution or workspace file) or a *.prjx (MonoDevelop project file) for convert ion into the Visual Studio counterpart formats (*.sln and/or *.csproj) and subsequently open them as the current solution in the VS IDE.

I say that this will benefit the MonoDevelop user community because this will require for me to write a long overdue convert ion that prj2make-sharp needs in other to endow it's sister project prj2make-sharp-lib – the MonoDevelop Add-in that is used today to import Visual Studio solution and project files into MonoDevelop. So, yes this is the bases for “Export to VS .NET” menu option.

Prj2make-sharp has now been released incrementally quite a few times. I have tried to track the changes in Mono to the best of my abilities and limited time. One of the most traumatic changes – for me at least – in the short but very active history of the Mono project was the addition of the GAC.

Before the GAC was introduced (in Beta 1) Mono was able to find library assemblies based on the users PATH environment variable or even the MONO_PATH environment variable. If that has changed or not is not as important as to what is the correct way and/or place where core Assemblies are located, I am talking about things like System.dll, System.Windows.Forms.dll, gtk-sharp.dll, etc. There was a time where all of it went to /usr/lib or /usr/local/lib and that was that – of course I am talking about *NIX. Then came the GAC which we all new we had to support sooner or later because it is a good Idea – in principle – and it is also a big part of the Microsoft .NET Framework architecture.

I never thought that it would have caused so much headaches. For most users it was not such a big deal but for people who design tools for developers such as NAnt, MonoDevelop and prj2make-sharp it became a different ball game over night. I urge you too read this email message form Miguel de Icaza: [Mono-devel-list] GAC and third party libraries: post Beta planning. and maybe some or all of the discussion that followed.

There are many differences between the project description files that Visual Studio uses and the ones shared by #Develop/MonoDevelop. The most significant difference from prj2make-sharp perspective is that MonoDevelop assembly references are specific enough to distinguish between GAC type and others. Visual Studio csproj files do not make that clear of a distinction. This means that if I am reading from a csproj file to then generate a MonoDevelop prjx file I have to first check to see if such a file can be found in the GAC and then query it for its full assembly information.

But which GAC? Now we have the Microsoft GAC and the Mono GAC. Wait! If I am in Windows using Visual Studio but I intend to generate a MonoDevelop prjx file that will be used in Linux, I may not even have access to the GAC of that other system. This means that when the part of checking a particular assembly in the GAC to see if it exists comes up it may not be possible. We must also remember that the detail information that an assembly will emit (culture, version, key, etc) may not be the same across platforms.

For brevity I will tell you what I plan to do. I will look in the Window's registry to see if Mono for Win32 is installed. When I last performed the installation on my system it left these entries:

Using the value of FrameworkAssemblyDirectory I will append mono\1.0 and/or mono\gac as necessary to perform my search and draw complete assembly information for the purpose of generating MonoDevelop files. At that point, I can only hope that the generated output files will work when deployed to a Linux, FreeBSD or Mac OS X machine running MonoDevelop.

A topic that is very important for me is GTK# in Windows. When writing this piece, the gtk# installer package available for Win32 was not intended to work in conjunction with Mono Win32 installation but rather with Microsoft .NET Framework GAC implementation. I want to have a combined installation package that install Mono AND GTK# in one swoop. Maybe one alternative may be to give users in Win32 a mechanism to take the gtk# assemblies that are installed in the MS GAC and installed them in the Win32 Mono GAC. This last may keep the community from writing many different installation packages to distribute the same binaries.

TEST IN MONO

The steps that I plan to take to test the solution a programmer is working on Visual Studio are:

• Generate a Makefile.Win32
• Create a process that will have an environment suitable for Mono on Win32 (including gtk# in Mono's GAC)
• Compile with mcs.exe
• Run with Mono.

This is for console and/or gtk# applications. Library assemblies (*.dll), would not have the final run to them, unless we give an option to launch a driver application or NUnit sort of test to run them.

For Web/ASP. NET applications that would run in Mono. I would use pretty much all of the steps above but would use an xsp.exe instance followed with a browser of choice launch.

GUI FACILITY TO CHANGE SETTINGS

Finally, I want to create a tabbed dialog box that will allow to save all of the specific configuration settings for the Add-in. The user selected preferences will then be stored int the registry (HKEY_CURRENT_USER) to be read upon startup of the Visual Studio IDE or when changes are performed as signaled by having press the 'OK' button on the Options dialog box.