Visual Studio Integration
From Mono
| Table of contents |
Design Considerations
Questions, questions
- What types of developers would be interested in deploying apps to linux through vstudio?
- Why?
- What types of devs would not be interested at all?
[jpobst] Taken from here (http://lists.ximian.com/pipermail/mono-list/2006-October/033221.html):
Covering the 80/20 case, I think the following assumptions can be made:
- Developers are primarily concerned with their apps running on Windows, but would like their apps to run on Mono/Linux if there is little to no additional development work required.
- Windows developers are not interested in switching to Linux, or SharpDevelop, or MonoDevelop. They want to program in Visual Studio on Windows, that is, using the tools they've used for years and are most productive in.
- Windows developers are not interested in learning how to use the various Linux tools like svn, make, yast, apt-get, rpm's, etc.
- Windows developers are not interested in Gtk#. Since the primary concern is their apps on Windows, Gtk# is not useful. (Gaim on Windows sticks out pretty bad.)
Obviously, there are exceptions to the above, but for the 80% case, it should work.
To that end, I can think of four options that would be helpful to VS developers trying to port their app to Mono.
- Scan 'Project/Solution' with MoMA - This is probably the first step a developer should be taking to being porting to Mono. At the least, the standard report would come up in a new VS window. Even better would be if the items from the report would show up in the Error List window where NIEX, MISS, and PINV would be placed on the Errors tab, and TODO would be placed on the Warning tab. Clicking any of these would take you to the place in code where you are using it.
- Run 'Project/Solution' with Mono - This step would be attempting to run the developer's app in Mono on Windows. This would work just like clicking the "Start Debugging" button in VS in that the app would run using Mono as the runtime. (Debugging of course would not be supported.) This allows the developer to find any differences between the MS and Mono class libraries. (I believe this is already available in prj2make.)
- Run 'Project/Solution' with Mono on Linux - This step is like the previous step, except the app would be copied over to a Linux real machine or virtual machine, and starts running there. This allows the developer to find any issues caused by differences between Windows and Linux.
- Debugging support - Use Visual Studio as the debugger for Mono on Windows or Mono on a remote machine. Make Visual Studio a front-end to the mdb debugger.
- Compile 'Project/Solution' with Mono - The next step a developer should probably take is trying to compile their app with Mono. This menu option would do just that, with the output showing up in the Output and Error List windows, just as if the compile was done by csc.
(Porting to Mono, there may be issues that are differences between MS and Mono (Mono bugs, etc.), and differences between running on Windows and Linux (case sensitivity, permissions, etc.). Having 3 and 4 as discrete steps breaks down the possible issues into smaller steps.)
Implementation How-to
Objectives
- Develop a system of deploying Visual Studio .net projects to Linux
- Develop a system to use Visual Studio to debug applications build with Mono on a local or remote machine.
Visual Studio Add-in
The most difficult piece of a visual-studio add-in is the debugger support. To do this, it is necessary to create a Debug Engine (http://msdn2.microsoft.com/en-us/library/bb145934(VS.80).aspx).
Linux Support
The Visual Studio add-in will need to communicate with the Linux system. We could connect with ssh or another custom protocol and launch a server that can be used to transfer files, debug information or executables to be ran on the target system.
Deploying Web Projects
Deploying web projects is essentially copying the entire project tree and all the files contained within, except source code files (unless the user wants to copy those too by selecting the appropriate option in the add-in).
Before doing any deployments, the user needs to configure the directory on the linux side that will receive the projects. The daemon should have a configuration mode that will create the directory and configure (optionally) a samba share.
Daemon Actions
- Samba configuration - root directory where the web project tree will reside
- Apache configuration (vhosts)(?)
When the add-in is run, the following options should be available to the user:
Add-in configuration / options
- Copy method (samba, ssh)
- Destination machine (name or ip)
- Destination directory (by default, project name)
- Copy source /y/n)
After the project is copied over, the add-in opens a web browser with the site.
Deploying Winforms Projects
Deploying winforms projects means copying over the content of the output directory (all dlls, images, etc) of the main project in the solution (Startup project). Optionally, the add-in can also copy the source files and project files, if the user chooses the Copy Source option.
An extra feature that might be interesting as well is to convert the PDB files into the MDB format (using pdb2mdb, perhaps?), and copying those as well.
Either the add-in or the daemon could create a wrapper script to make it easier to launch the application.
When the add-in is run, the following options should be available to the user:
Add-in configuration / options
- Copy method (samba, ssh)
- Destination machine (name or ip)
- Destination directory (by default, project name)
- Copy source /y/n)
- Copy debug files
Powered by MediaWiki