I want to contnue yesterday's discussion on the Visual Studo Add-in that I am working on.
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, Todd Berman, yes this is the bases for “Export to VS .NET” menu option.
One of the issues I always have with using the word “Export” or “Import” is that I end up having a mental image that the original item before the export begun is no longer available, has change locations, or has mutated in any way shape or form. So I tend to stay away from those particular choices of words and favor more “Generate” or “Create” as my menu entry labels. Prj2make-sharp always generates a new file or files without affecting the original source or even its location. Maybe this is the transition point to talk about the creation of MonoDevelop file type from the currently open solution.
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, I think :S) 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.
Off to work but will continue tomorrow. Who knows I may even finish and moveon.org to coding already :)
Posted by martinf at June 25, 2004 06:40 AM