[Mono-devel-list] Visual Studio Addin for Mono

Daniel Morgan danielmorgan at verizon.net
Tue Jun 22 20:28:15 EDT 2004


I like the idea for testing Mono stuff in vs.net.  I already do this.
:-)

I have a vs.net solution that has various assemblies built, mostly for
testing and debugging System.Data and its data providers.

Two big reasons why I use vs.net to do Mono stuff: debugger and editor.
...since there is no Mono debugger on Windows.

Wouldn't it be cool if someone created a Glade addin?  This way we could
visually design gtk# apps in vs.net.

Somone may have already created a Nunit GUI addin for vs.net, so getting
that to work for testing Mono would rock!

I know SharpDevelop has an Nunit GUI integrated. 

-----Original Message-----
From: mono-devel-list-admin at lists.ximian.com
[mailto:mono-devel-list-admin at lists.ximian.com] On Behalf Of Francisco
T. Martinez
Sent: Saturday, June 19, 2004 5:45 PM
To: mono-devel-list at lists.ximian.com
Subject: [Mono-devel-list] Visual Studio Addin


Hello you all:

I decided to also create a native .NET Framework 1.1 version of 
prj2make-sharp.  As with the 100% Mono version, there will be to 
executable assemblies, a console exe and a GUI exe.  Today 
prj2make-sharp code base is also the bases for prj2make-sharp-lib the 
addin that permits importing VS .NET solutions in the MonoDevelop IDE.

I believe that advances in Mono and GTK# have reach a point in which we 
may want to create native VS addin that:

    * Generate Makefiles
    * Create MonoDevelop solutions
    * Give you the ability to "Test on Mono"

As I am studying these possibilities I have come a cross some issues 
(perhaps inconsistencies?) in the way that we handle Mono/GTK# in 
Windows from the way we do it in Linux.  I am fully aware that there are

great differences in both operating environments, but I for one think 
that we can draw on some common denominators or at least find a solution

that is platform specific but permits the honoring of some established 
operating conventions.

For example, we had agreed on the use of pkg-config *.pc files for the 
source of information like what version of Mono/GTK# is installed but 
most important what would be the base path for the all to important 
lib/GAC etc.

I am so grateful for the work that Gonzalo has done with the Windows 
installer for Mono.  I also know that John Luke had begun doing or 
updating the Windows installer for GTK# -- great job and thanks John 
Luke -- , but heard that Erik Dasque was in contact with someone at 
Novell that was now crating the GTK# installer.

In a Windows environment I readily see to use cases ( I am sure there 
could be more), one where there is absolutely no cygwin on the computer 
and one where there is.

If cygwin is present there is likely pkg-config and also a different 
world of path separator characters and other UNIXisms.  Right now Visual

Studio and cmd.exe are not necessarily privy of that environment and I 
would like to work under the assumption that it is not there.  Indeed, 
my suggestion is that upon installation of the Mono runtime and SDK, we 
populate a registry entry with the location of the base path for the lib

and GAC.  This is already being done by Gonzalo's installer.  Look below

for what my registry looks like:

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

Later, GTK# and other third party libraries that will require and/or 
want to participate from the Mono GAC can query this values during the 
running of their respective installation routines and supplement or just

consume those registry entries.

I just want it to get some dialog going on this subject.  Obviously, I 
am in the best disposition to help and or cooperate to solve and improve

these awesome thing we are doing called Mono :)

Paco



_______________________________________________
Mono-devel-list mailing list
Mono-devel-list at lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list




More information about the Mono-devel-list mailing list