June 26, 2004

Visual Studio Add-in Part 3 of 3 -- I don't think there were really 1000 parts

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:

[HKEY_LOCAL_MACHINE\SOFTWARE\Mono\Beta3]
"SdkInstallRoot"="C:\\mono\\Mono-Beta3"
"FrameworkAssemblyDirectory"="C:\\mono\\Mono-Beta3\\lib"
"MonoConfigDir"="C:\\mono\\Mono-Beta3\\etc\\mono"

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.

I think that this transitions us to the other point or functionality of the VS Add-in: '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 and run with Mono. This is for console and/or gtk# applications. Library assembies (*.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.

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.

I will make all three parts available in a sigle document.

Posted by martinf at June 26, 2004 08:24 AM
Comments