Is there a configuration setting somewhere telling mojoPortal.Web to look for those custom DLLs?

This forum is only for questions or discussions about working with the mojoPortal source code in Visual Studio, obtaining the source code from the repository, developing custom features, etc. If your question is not along these lines this is not the right forum. Please try to post your question in the appropriate forum.

Please do not post questions about design, CSS, or skinning here. Use the Help With Skins Forum for those questions.

This forum is for discussing mojoPortal development

This forum is only for questions or discussions about working with the mojoPortal source code in Visual Studio, obtaining the source code from the repository, developing custom features, etc. If your question is not along these lines this is not the right forum. Please try to post your question in the appropriate forum.

You can monitor commits to the repository from this page. We also recommend developers to subscribe to email notifications in the developer forum as occasionally important things are announced.

Before posting questions here you might want to review the developer documentation.

Do not post questions about design, CSS, or skinning here. Use the Help With Skins Forum for those questions.
This thread is closed to new posts. You must sign in to post in the forums.
2/17/2014 8:10:38 AM
Gravatar
Total Posts 3

Is there a configuration setting somewhere telling mojoPortal.Web to look for those custom DLLs?

Hi Joe,

  I created the dependency diagram (http://share.pho.to/4lqoS/gm/original) that shows how mycustom.Features.UI.dll references mojoPortal.Web.dll.  Normally, the startup project would reference what it needs and those assemblies reference what they need.  Instead, even though mojoPortal.Web.dll is the entry point of the process, the custom "feature" dlls reference it.  

Now I'm wondering... Since mojoPortal.Web does not reference the 4 "features(mycustomproj.feature.ui or business or data)" assemblies, how does it know to load them?  Just being in the bin directory doesn't cause them to be loaded.  Is there a configuration setting somewhere telling mojoPortal.Web to look for those 4 DLLs?   Or does the mojoPortal framework scan this directory looking for something that references it? 

Thanks,

Chandru

2/18/2014 10:11:38 AM
Gravatar
Total Posts 1204
Proud member of the mojoPortal team

Help support mojoPortal!
Add-on modules

Re: Is there a configuration setting somewhere telling mojoPortal.Web to look for those custom DLLs?

When you register your feature by either installing it manually, or using the mojoPortal Installation System, it tells mojoPortal that your feature is available to be used, and where the pieces of it are located.

Jamie

2/18/2014 12:52:12 PM
Gravatar
Total Posts 18439

Re: Is there a configuration setting somewhere telling mojoPortal.Web to look for those custom DLLs?

You should review the source code and consider the WebStore set of projects as an example of how to layout your own projects. .csproj files just tell VS which files to compile it has no bearing at runtime. At runtime all the matters is that your dlls are in the bin folder under the Web project and that your .ascx and .aspx files if any are also copied somewhere in a folder of the web project. You should use a post build event to copy the files and look at the post build of WebStore for an example.

The path to the .ascx file that is the starting point of your feature is the only thing mojoPortal knows about at all, and that comes from the feature definition file (see the link Jamie posted) if using one or else it is whatever you put in manually for the path to your control using the Administration > Advanced Tools > Feature Installation UI pages. Using the feature definition file just automates populating the info, the setup page process it for you. Again as far as configuration that path to your user control is the only thing mojoPortal knows about your feature, other than that the dlls must be in the bin of the web project and you make sure your internal links use SiteRoot + /yourpath/... based on wherever you decide to put your files (using the post build event)

If you feature has supporting pages then you would link to them from your .ascx so any links are internal to your feature, and like existing features the pageid of the cms page and the moduleid of your feature instance you would pass also in the url to your supporting pages so that you can use mojoBasePage methods to enforce role based security, again study the code for existing features for examples

Hope that helps,

Joe

2/22/2014 1:55:15 AM
Gravatar
Total Posts 3

Re: Is there a configuration setting somewhere telling mojoPortal.Web to look for those custom DLLs?

Thanks Joe, mojobasepage is really helpful for me to understand a lot more. mojoPortal loads the custom features but there is no compile time checking right?

2/22/2014 6:36:45 AM
Gravatar
Total Posts 18439

Re: Is there a configuration setting somewhere telling mojoPortal.Web to look for those custom DLLs?

visual studio compiles your custom feature code so any compile time checking happens at that time, your custom feature code will typically have dependencies on mojoPortal but mojoPortal has no dependencies on your code and isn't involved at all with compiling your code other than as a dependency that must be referenced by your code in order to use our base classes or other classes that can be useful to you when implementing custom features

You must sign in to post in the forums. This thread is closed to new posts.