Would moving the mojoPortal.Net namespace into the mojoPortal.Web assembly break your code

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.
8/23/2011 2:12:31 PM
Gravatar
Total Posts 18439

Would moving the mojoPortal.Net namespace into the mojoPortal.Web assembly break your code

Hi All,

For several reasons I would like to move the mojoPortal.Net namespace from its own project into the mojoPortal.Web project.

Basically moving the Email.cs and SmtpSettings.cs and other classes into the mojoPortal.Web project in a folder under /Components

One reason for this is because I'm working on file system abstraction as part of web farm support so that the user uploadable files could be stored in Windows Azure Blob storage for example as an alternative to local disk storage.

So the problem is in how file attachments are handled in email. Currently we just pass in paths to the attachments so this is strongly coupled to the disk file system. I want to change it so that we pass in an object that implements a new IFileSystem interface and then create attachments from a stream returned from IFileSystem rather than directly accessing the file from disk. To do that I would need to add a reference in the email class to mojoPortal.FileSystem namespace which lives in mojoPortal.Web project. But I can't do that because it would be a circular reference between the mojoPortal.Web project and the mojoPortal.Net project.

The solution is to move the mojoPortal.Net classes into the mojoPortal.Web project so they can easily access mojoPortal.FileSystem. This would also reduce the number of projects in the solution by one which also would be beneficial in terms of reducing the time to load or build the solution in Visual Studio.

But my concern is this could be a breaking change for custom features that others have built if you send email in your features. So I wonder how many of you see it as a problem to change your feature by removing any reference you have to the mojoPortal.Net project and only reference mojoPortal.Web. Actually I think if your use of this namespace is in places that already reference both mojoPortal.Web and mojoPortal.Net projects then it might not be a problem. I could keep an empty class in the mojoPortal.Net project and then it should not break as long as you have a reference to both projects in the places where you send email.

But for some projects such as those from developers who develop against the dlls instead of working against the mojoPortal source code it might break the feature.

Fixing it would be very simple, just removing the reference to the mojoPortal.Net project or dll as the case may be and reference mojoPortal.Web project. Since we would keep the namespace as mojoPortal.Net no actual changes to your code would be needed, only the reference changes.

If I proceed with this change then I would also need to package an empty mojoPortal.Net.dll in the upgrade so it would overwrite the older version on disk, otherwise it would cause an error because of having the same namespaces and classes in 2 assemblies.

So my question for those of you who read this forum is what do you think, would this be a huge problem or an easy adjustment for you?

Thanks for any feedback.

Best,

Joe

8/23/2011 2:34:22 PM
Gravatar
Total Posts 18439

Re: Would moving the mojoPortal.Net namespace into the mojoPortal.Web assembly break your code

Never mind, I've decided this would probably cause enough problems that I should avoid it.

Instead I will add an overload for sending email that allows passing in a List<Attachment> and I will handle creating the attachments from the file system abstraction layer in feature code that uses attachments instead of directly in the Email.cs class.

Best,

Joe

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