Importing support files from a separate / external solution

So how do you plan to reference any of Kentico's API information from within your external solution? When you add the references into Kentico, won't it create a duplicate reference for any of the already created Kentico dlls? If you don't plan to use any of the Kentico API, then it would just be another project. If you're following what Kentico recommends, they state to not customize the installed files but to create clones and or your own copy of the files and reference them that way. If you're following the standards and best practices, as with any software package, the process works as expected. I'd recommend against trying to recreate the wheel.

I've ran through several upgrades at different version and different complexities of sites and the sites which were the worst to upgrade at the ones who didn't follow standards and best practices. Some of those sites only had 30-50 pages but took way longer to upgrade than the highly customized and integrated solutions with hundreds pages of content.

Just my 2 cents, take it or leave it. Either way, good luck!

Thanks, Brenden.

To answer your question: My solution will reference Kentico, but not the other way around. My proposed copy-script will simply drop my solution's build output into Kentico's standard locations. This seems like a best practice to me: To encapsulate my custom components in the project and directory structure of my choice, with only the necessary dependencies, without intruding upon the Kentico instance. My components will access Kentico data via interface, and therefore be unit testable. The implementations will wrap Kentico's static (yuck) API classes.

The alternative is to mix my custom code among vendor code within a vendor solution, to be compiled as part of the vendor product. I'd have to manage my custom components by digging around in 30+ root-level directories, ignoring the vast majority which correspond with untouchable vendor implementation. My code would be less testable, as it would be compiled with the entire UI layer of the application. This would be grotesque engineering.

As I see it, the main challenges are trivial: I must update my solution's Kentico assembly references whenever I upgrade or hotfix Kentico. I must provide a script to copy my build output to the correct locations within the Kentico CMS project. This is only a little complex, and I actually like that it formally declares the relationship between my solution and the Kentico application structure. Finally, the layer of indirection loses some of the in-place editing capability of web site projects, which I think it's safe to say very few ASP.NET developers use anyway.

Bryan, I understand what you are feeling. I too have put a lot of thought into this. Kentico is somewhat rigid. I can develop and code complex sites and applications from scratch and create a lot of functionality in a short time that to do in Kentico takes a great deal of time and requires heavy customization. BUT, Kentico provides, in theory a modular architecture if you want to think about it that way. It provides all of the scaffolding that I prefer not to recreate as well as the ability for users grow the website/application through the use of the Back End (Desk, Admin).

After going around and around with this and architecting out several mock systems, I came to the following conclusion. Use the strength of both within a modular plug type architecture. My services, code, controls, modules, etc. co-exist nicely within the Kentico application rather than separating them out. I clone all Kentico web parts if they need modifications and I keep a dictionary of them for reference on upgrade. I also develop my code to be as dynamic as possible, rather than rigid where an upgrade could cause an error. Additionally I create modules and keep my developed web parts in that part of the directory structure so I can move them or copy into the production system when needed.

Just my thoughts.

Charles, thanks for your advice. That is basically how I'm doing things now, and it's definitely how Kentico's documentation encourages it. In fact, I've taken Brenden's advice from a different thread, and I've started using the Portal Engine as opposed to ASPX for page templates.

However, this breaks down as I implement business-specific features. My pages must consume features of a UI-agnostic application services layer, various domain models, services for proprietary in-house data APIs, and complex responsibilities for maintaining details of the session state and other spontaneous business events. I can wrap these concerns in user controls / web parts, but the UI layer itself is ultimately thin. Without creating my own assemblies, I'm forced to keep all this application code in the UI layer's assembly under /App_Code or /Old_App_Code, and I have to compile it all at once along with, well, all of Kentico. That's not a viable development process, especially for an application of ours' size and complexity.

I have some followup questions for you:

• Do you forgo developing in your own assemblies?
• How do you represent subdomains and bounded contexts?
• How do you exposes your business models and services for unit testing?
• Would you recommend installing the Kentico instance as a web site project or as a web application project?