Hi,

you need to make sure you are using a post build event to copy any controls needed by your feature up to a location in the main web project.

Generally for developing features that you plan to package for others to use, you should use the installation system to configure your feature settings via xml config files, that is what all the included features do. But you can configure them manually as you are trying to do, th emistake is how you specify the path for an ISettingControl. The path should be relative to the root of the mojoPortal.Web project (Web folder) like this:

~/yourfolder/yourcontrol.ascx

The post build event in your project should copy it to the location specified in the path.

Note that to run or debug your custom feature, you need to run it in the context of mojoPortal so mojoPortal.Web must always be the startup project. You can set break points in your custom project and they will still work, but you don't launch your project by itself you use post build events to copy your files up to the main web project and you run the main web project.

For example the Flickr feature uses an ISettingControl for the theme, the control lives in mojoPortal.Features.UI/Flickr/FlickrThemeSetting.ascx, the configuration file lives at mojoPortal.Features.UI/Setup/applications/flickrslideshow/FeatureDefinitions/70001_FlickrGalleryModule.config

Hope it helps,

Joe

Yes, all your files should be in your own projects and those are the definitive copies of the files, but your post build event should copy the needed files up to the mojoPortal Web project and that is where they run from at runtime, if you make a change in your .ascx or .aspx file in your project you need to rebuild the project in order to copy it up again. You set breakpoints for debugging in your own project, it will still hit those break points even though the runtime copy is located up in the mojoPortal Web project.

You can study the post build event in mojoPortal.Features.UI or WebStore.UI

It is better to configure your feature settings aka module settings from a config file rather than from the web page UI. Your configuration files should live in your own project as well and should also be copied during post build up to the mojoPortal Web project at /Setup/[yourfeaturename]/ with sub folders structured the same way beneath that (basically conventions) You can see that is where the config files for features in the mojoPortal.Features.UI project live in that project but are copied by the post build events. Structure the folders in your project the same way so that when they are copied they land in the right places. Then visit the /Setup/Default.aspx page in the site and it will configure your default feature settings, run any sql scripts for your feature etc..

So the mojoPortal.Features set of projects as well as the WebStore projects are like examples of how to organize your own code, all the files for those features live in the feature specific projects, the needed files are copied up to mojoPortal.Web by post build events but are not part of the mojoPortal.Web project, but the run in the context of that project at runtime. Even though your files are not part of the mojoPortal.Web project, the files that get copied there (by the post build event) will be included if you Publish the mojoPortal.Web project, so you can produce a complete package with mojoPortal and your custom features.

Hope it helps,

Joe