Numerous times in recent years I’ve had to use Reflector Pro to debug third-party dlls. While this works well and allows you to step through code as if it was your own the value of doing so can be completely lost if you cannot see critical object values due them being ‘optimized away’.
Recently I was stuck with a problem of optimization that refused to be disabled by the usual means that I’d used in the past. I stumbled onto a neat trick which finally did work, but it also clarified what happens when the web application, usually Sitecore CMS, restarts.
I setup a Mongo arbiter instance alongside two full instances for use with Sitecore 8 xDB database. Shortly afterwards I noticed the arbiter log was full of authentication failures. This isn’t a big huge problem, but it fills up the arbiter log and may cause concern wondering if there’s an underlying configuration problem.
Using the new Sitecore contentsearch api allows you search against a lucene index with very little effort. Examples are a bit short on the ground but using Linq you can find yourself doing something like this to search for an item by name, somewhere within a folder structure:
public void BadSearch(string searchTerm)
var webIndex = ContentSearchManager.GetIndex("sitecore_web_index");
using (var context = webIndex.CreateSearchContext())
var results = context.GetQueryable<SearchResultItem>().Where(i =>
i.Name == searchTerm &&
i.Path.StartsWith("sitecore/content/stuff/")); // don't do this!
This may well work. However you may also run into a Lucene error stating that you are using too many clauses, the default limit is 1024.
A quick post to say that I’ve finally uploaded my shared source ‘Redirect Manager’ module to http://trac.sitecore.net/RedirectManager/
This is part 2 of 2 posts on detailed Sitecore.Linkmanager configuration.
Whenever using Databound server controls with Sitecore need to be aware that Sitecore meddles with some controls. This nasty issue which can have you banging your head against the wall for hours (days?) has been previously blogged by Mark Cassidy but I guess it depends on what symptom you’re having first, and wether you relate it back to this obscure setting. In my case, I was previously aware of this issue but only relating to apparent loss of viewstate on controls. Unfortunately I didn’t think of it as affecting events too.
In my case most features worked, Edit buttons would invoke row editing mode, cancel button works fine, rowCommand event generally worked, but it wasRowUpdating that simply wasn’t working. Adding System.Web.UI.WebControls.GridView to <typesThatShouldNotBeExpanded> in web.config resolves this issue. your web.config would then look like :
This issue does now have a fleeting mention on http://sdn.sitecore.net/Scrapbook….. but requires login to view it.
While looking for that link, I also came across another blog post detailing the same issue and frustrations I’ve had with Gridview events that may have more detail.
In general ASP.net, this can be caused by calling DataBind() more than once on a databound control. Also be aware that this is influenced by automatic databind being on too.
Relating this to Sitecore CMS, you should be aware that Sitecore ships with the following line in web.config:
<!– AUTOMATIC DATA BIND
Indicates if the data bind function is run automatically
<setting name=“AutomaticDataBind“ value=“false“ />
This means that you will need to either call Databind whenever you need it, or you can simply set this value to true. This AutomaticDataBind setting will also cause problems with other types of databound controls, such as templated controls. It’s generally simpler to set it to ‘true’..
After installing Sitecore v6, you get the following error when viewing the website or sitecore UI:
Sitecore Could not load file or assembly ‘System.Data.SQLite, Version=188.8.131.52, Culture=neutral, PublicKeyToken=db937bc2d44ff139’ or one of its dependencies. An attempt was made to load a program with an incorrect format.
This is actually detailed in page 20 of the sitecore troubleshooting doc, but I missed it first time round. This is caused by the presence of System.Data.SqlLite in the bin folder when running on 64-bit OS. An alternative dll is available for 64bit OS from Sitecore.
Solution: If you’re are not using SQLite simply the delete the System.Data.SqlLite.dll from the bin folder and recycle your app to get back up and running. If you are using SQLite, download the alternative dll for 64bit OS.
You get a cross-domain web services warning when debugging your silverlight application. This can be caused simply by leaving the wrong project highlighted when you hit F5. Select your .web project or the project that contains the aspx file hosting the application. If you run debugger with the silverlight project (containing your page.xaml) selected, you get this error.
After rebuilding my DBML file with SQL metal, my DataContext class no longer has a parameterless constructor. This is due to differences between the was that Visual studio generates the DBML (with SQL metal) and how SQLMetal command-line does by default.
The parameterless constructor simply takes the connection string from web.config rather than requiring one to be passed in as an argument. There may be switches for SQLMetal to handle this, but in the mean time here is a quick solution (which is simply what VS2008 adds when using the DBML builder) :
Add the following method to the DataClasses.designer.cs
public MyDataClassesDataContext() :