It isn't that difficult, so obviously you are not doing something correctly or doing something incorrectly. But I'm not a mind reader so I have no idea what you are doing or what your custom code is doing. Therefore if you want help you need to explain in detail what you are doing and what problem you are having then maybe someone can help you.

Be specific about what kind of changes you are making and what you think is supposed to happen.

You should not be expecting it to run any scripts more than once and should not be trying to make it do so. If you need to make modifications to the database after deploying a feature you need to use upgrade scripts and not modify scripts that already ran.

If you cloned an existing feature then you need to make sure you used a new featureGuid for your clone otherwise changes in FeatureDefinition files will update the mojoPortal feature instead of your clone.

Best,

Joe

You should keep your own features in your own projects and they should have no relation to mojoPortal.Features set of projects.

The mojoPortal.Features set of projects is no different than what you do for your own custom projects, it works the exact same way. mojoPortal.Features.UI is never run directly, it copies the files up to Web in post build events the same as you should do for your own features. So the structure of the mojoPortal.Features projects is the same as how you should structure your own projects, it just has a bunch of features in the same set of projects.

The WebStore set of projects is also implemented the same way as anyone would implement a custom feature, but it only has one feature. So you can have a set of projects per feature or you can have multiple features in the same set of projects. The main idea is to keep the feature code separate from mojoPortal core projects, The feature projects can depend on the core projects but never should the core depend on the features.

If we had separate projects for each of the features in the mojoPortal.Features set of projects it would just be a huge solution with lots of projects and would get a bit unwieldy, so it is convenient to bundle those features together in one set of projects. But for example with my add on projects I use a separate set of projects foe each product because I want to be able to package them separately for sale. So the decision of whether to bundle features into one set of projects or not depends on whether you want to be able to package the features separately or not. If not it is more convenient to bundle them and deploy them together.

The main reason I did not include WebStore in the mojoPortal.Features projects but made it separate is because in order to do that it would have to support all the database platforms whereas keeping it separate allowed me to not have to implement it for every database. I may one day implement the other data layers but I don't want to do it until the WebStore feature is more mature and stable.

Hope that explanation gives some insights.

Best,

Joe