[MonoDevelop] Separating AspNetAddIn functionality from the Project type

Michael Hutchinson m.j.hutchinson at gmail.com
Mon Jan 8 10:25:36 EST 2007

On 1/8/07, Lluis Sanchez <lluis at ximian.com> wrote:
> 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.

Okay, I guess that'll work. There could be a VS2005 project importer
subclass of the web project class.

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

I think that having a subclass probably does make more sense overall,
but there are a few case where I will still try to split off features
like I did with the CodeBehindProvider. The ProjectServiceExtension
would be a good way to implement the "web run" features, with plugins
like an XspProvider, ModMonoProvider, RemoteModMonoProvider etc, and
it could handle web browser configuration and selection as well.

> 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.

Yes, that makes sense. I'm kind of worried about my workload at the
moment anyway ;-) At any rate, it wouldn't really be the end of the
world if the project file format did change after MD 1.0.

Michael Hutchinson

More information about the Monodevelop-list mailing list