While poking around in the shared source RSS module for Sitecore, I found that several aspects of the “static feeds” feature loose language context during publishing. This only effects static feeds whereby the rss.xml file(s) are written to disk and linked-too directly. The processes is kicked-off my hooking into the publishing-end event.
While the similar method Context.Database.GetItem retrieves an item in the same language as the context item, it appears that SelectItems(selector, predicate) does not. So if you are in a language other than ‘en’ English, you will probably retrieve the ‘en’ version of your non-‘en’ language items, resulting in large areas of missing data.
I’m not sure if this only effects SelectItems() when run outside of the context of a web request, or if it happens all the time, but the work-around is to explicitly change your context.language before calling SelectItems().
ContextItem.Database.SelectItems(selector, predicate); …..will return ‘en’ language items regardless.
Instead you must use:
Sitecore.Globalization.Language.Current = ContextItem.Language;
….which then retrieves items in the same language of contextItem.
The standard lightweight version of SQL Express 2005 is missing files that are required to install on Sever 2008 x64. You cannot install the lightweight version on server 2008 / 64-bit windows OS. Instead you must simply download the full package including advanced features. This more complete version will install fine on Server 2008. Bear in mind that you don’t actually need to install the advanced features.
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() :
Can be caused by the SQL server browser service being disabled. Set to automatic and start the service. Restart the ‘add connection’ wizard from Visual studio and the local SQL server host and databases should be discoverable again.
SQL server browser service