Importing support files from a separate / external solution

Bryan Drenner asked on April 13, 2015 17:53

I'm not a fan of developing my web application by customizing the Kentico-Installer-generated solution. Customizing vendor code just seems like a bad idea. Kentico's solution has a rigid and proprietary structure which can't be rearranged without breaking upgrades and other features. It includes many uncompiled components of the Kentico product, which Visual Studio wants to consider when searching or refactoring. It muddles the process of storing your own code in source control, because your own code is mixed in with Kentico vendor files.

I would like to keep my models, services, UI controls, etc., in a solution separate from the Kentico-Installer-generated solution. Then I'll treat the Kentico solution like any other application's directory, into which I import my custom components in a modular fashion. This means I'll need to manually copy the assemblies, aspx, ascx, etc. files into the Kentico solution's CMS project, perhaps by some script. Could anyone share their experiences or advice about this kind of arrangement?

Correct Answer

Charles Matvchuk answered on April 19, 2015 19:07


I develop my own assemblies when it makes sense. It all depends on the functionality that I need and what the scope is. With modules I typically develop within custom assemblies. For unit testing I actually use multiple external tools as well as self created. I use Devexpress controls and use their Test Café, as well as Automation Anywhere, which enables the creation of any type of automation task and I create some pretty cool testing scenario's. Finally I create my own unit tests with debug within visual studio ultimate 2013 and the various tools available there.

As far as a web site vs. web application, I prefer Kentico with web site. You lose some functionality when you use it as a web application. See the documentation and install models. Finally it is easier for me to deploy modules, web parts and assemblies to the production system when it is a website.

I do not hold a rigid development model. I tend to look at the situation and the scope and use the right tools and methodologies for it.

1 votesVote for this answer Unmark Correct answer

Recent Answers

Brenden Kehren answered on April 13, 2015 18:22

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!

0 votesVote for this answer Mark as a Correct answer

Bryan Drenner answered on April 13, 2015 19:25

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.

1 votesVote for this answer Mark as a Correct answer

Charles Matvchuk answered on April 13, 2015 19:31

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.

0 votesVote for this answer Mark as a Correct answer

Bryan Drenner answered on April 13, 2015 20:37

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?
1 votesVote for this answer Mark as a Correct answer

   Please, sign in to be able to submit a new answer.