[MonoDevelop] Separating AspNetAddIn functionality from the Project type

Lluis Sanchez lluis at ximian.com
Mon Jan 8 09:56:57 EST 2007

El dt 19 de 12 del 2006 a les 14:17 +0000, en/na Michael Hutchinson va
> I am interested by the new ProjectserviceExtension AddIn, as this
> allows me to implement AspNetAddIn as extensions to normal project
> types (like MonoDevelop.GtkCore) rather than a project type itself.
> This will make it *possible* to add support for VS2005 web application
> project files, which is made  difficult at the moment because that
> VS2005 file support is also a project type. It will also make the code
> more reusable by other web project types.

A web project is a different kind of project, it follows different rules
for compiling, running and deployment. For me it makes sense to have a
project subclass. About VS2005 support, we can just add a dependency
from the importer to the ASP.NET add-in. We'll need it anyway if we want
to import some ASP.NET specific configuration information.

If the same behavior can be implemented using ProjectServiceExtension
I'm not against it, but still think a subclass may make more sense.

> Fortunately the deployment code is already separate to the project
> type (at least when it gets finished). The thing that may not be
> possible ATM is to override the compile directory. I'd also like to be
> able to hide option panels when the ASP.NET functionality is not
> enabled, and this would be useful for GtkCore as well (<Conditional
> activeExtensions="GtkDesignInfo">...?).
> If I'm going to do this at some point, it would make sense to sort it
> out before release so as not to change the project file format later
> on. However, this will probably make it not possible to hit the 1.0
> release. Is this a good idea?

1.0 will probably delayed, but in any case if what we have now works I
would spend the time we have in stabilizing it rather than rewriting it.


More information about the Monodevelop-list mailing list