I often come across the same questions when looking at introducing Glass Mapper to a team and thought I would write a short post covering off some of the more common ones.
One of my current clients is making the transition to Sitecore 8. This went reasonably well as we decided to do a fresh installation rather than follow the upgrade path and then copy any content in manually.
What we weren’t prepared for was a number of errors using Sql Server and IIS. Specifically we were getting heap exceptions with system.data.dll and ntdll.dll. However, what was funny was that these errors weren’t occuring on everyones systems. In fact the only repeatable thing was sporadic database issues with connectivity.
After some investigation we found that we were on .NET 4.5.1 and this has some known issues. So if you’re getting issues with IIS, the worker process or with the system.data dlls then this is one thing to look into.
Needless to say we did a test installation on a working system (well one with the least amount of issues) and this ran ok. Then we rolled it out to the other systems and this fixed our system. You can find out more about the list of known issues on the Microsoft support site.
The .Net 4.5.2 update is a web installer so you’ll need Internet access for any machine you’re updating.
In recent months I have been very busy working on the performance of Sitecore installations, this has included things like:
- Optimisations to the MVC pipelines – working closely with Sitecore support to improve some of the issues we found – shown in my posts on Strategies to optimise Sitecore MVC performance and Further strategies to optimise Sitecore MVC performance.
- Optimisations in Glass Mapper to achieve rendering times on par and even sometimes quicker than native Sitecore (this is amazing in itself!)
- Optimisations to our own code to help achieve the maximum performance out of it.
Traditionally it has been my opinion that (unless you use Ninject), the IoC container you choose would have little impact to your final solution. In traditional .net solutions, this TENDS to be the case; Indeed when using Sitecore with webforms, the impact TENDS to be less important, which means you are free to choose the IoC container based upon the feature set it provides (on webforms, property injection is a major nice to have for example).
During my Sitecore journey, my improving knowledge of Sitecore led me to better solutions around making the most of my IoC containers. This has led to things like resolve your Sitecore controllers from your IoC container, resolving configuration entries (pipeline) from your IoC container. I utilise these to great effect with Sitecore’s pipelines in particular, bringing various entries in using my container.
This has of course increased the level which the IoC container is relied upon, and in particular if you are using these techniques in the mvc.getModel, mvc.renderRendering or httpRequestBegin, this can easily result in a lot of leverage on your container.
As CardinalCore has just had a record month for traffic. I am firstly delighted that this blog has grown to this level so quickly having recorded close to 9,000 views in the 7 months since it’s launch.
In this, my 55th blog Post since this blog was launched in July 2014, I am delighted to announce that I have been approved as one of the very lucky 14 Sitecore MVPs for 2015.
EDIT: This post covers versions pre Sitecore 8.1.
In this post I will be describing pulling your controllers for use in controller renderings from an IoC container, in this case (again) Castle Windsor. The principle would apply to most containers in the same manner.
In my on-going quest to avoid the ‘new’ keyword in my Sitecore implementations, well – in fact more just to delegate the responsibility of dependency management to my IoC container. I remembered that we had pulled together from a few internet sources, a set of classes that allow the instantiation of Controllers from our IoC container. I wish I could credit the internet sources, but sadly as lazy developers, we gladly consumed and dutifully discarded them. I would also like to add that this was the collaboration of a couple of developers to finalise this solution, so not all my own handiwork on this occasion.