So, I’ve blogged previously about my problems with the IClientApiService on a Content Management (CM) server. See https://andrewwburns.com/2018/08/15/unable-to-resolve-service-for-type-sitecore-emailcampaign-cd-services-iclientapiservice-while-attempting-to-activate/
Well, I asked Sitecore support about it, and they gave a really helpful response:
// This should be injected rather than calling the ServiceLocator
IMessageBus automatedMessageBus = ServiceLocator.ServiceProvider.GetService<IMessageBus>()
AutomatedMessage automatedMessage = new AutomatedMessage()
ContactIdentifier = contactIdentifier,
MessageId = emailCampaignId
Their reasoning for this was:
It is not recommended to add the configuration on CM since:
1) It is not enough to add only the <configurator> section, since it has dependencies on other configuration sections.
2) The CustomServiceConfigurator may change in the next release and the functionality will stop working.
Fair enough, seems sensible, though I’m now slightly at a loss for what the IClientApiService is actually for. I’ve tried the code they’ve send across, and it sends email correctly (and yes, I used DI, rather than a ServiceLocator).
I’ve tested this code locally, and it works nicely; I haven’t yet had a chance to try it on a scaled environment. I also decompiled the relevant assemblies, and yes, behind the IClientApiService implementations it seems to use a MessageBus<AutomatedMessage> object, so this should be equivalent.
I got this error while looking at a customer’s system, and weirdly, all renderings that used datasources had stopped working.
Sadly, I don’t still have the full stack trace, but it turns out the problem was a mis-configured URL for the SOLR service. Sitecore uses content search to find the datasource for a component.
This fact was a new one for me!
I think our URL lacked a /, or /#/. We corrected it, and the error went away – and our datasourced renderings started working again.
I found a reference on StackExchange after the fact.
A colleague had this error occur while setting up a production system. Everything had been fine in development, but Dependency Injection seemed to be throwing a wobbly when it tried to load the service we’d written for adding/removing contacts from a subscription list.
Edit: I raised this problem with Sitecore and got a helpful response: https://andrewwburns.com/2018/08/17/avoiding-the-iclientapiservice/
Continue reading “Unable to resolve service for type ‘Sitecore.EmailCampaign.Cd.Services.IClientApiService’ while attempting to activate…”
We all have to get zero errors when compiling solutions, but we all aim for zero warnings, too, right?
Supressing Code Analysis errors is easy enough – and I recommend using code analysis rules (though you don’t need to enforce ALL of them. Consider what rules are relevant.)
However – what do you do if you have errors like this, it can be a problem:
6> blah\Caching\TokenCacheItem.cs(39,48,39,65): warning CS0067: The event ‘TokenCacheItem.DataLengthChanged’ is never used
The thing is, I need DataLengthChanged to fulfil an interface. But yes, it isn’t used. Oh, the conundrum.
What I hadn’t realised was you can disable compiler warnings (steady – careful!). See: https://stackoverflow.com/questions/3820985/suppressing-is-never-used-and-is-never-assigned-to-warnings-in-c-sharp/3821035#answer-3821035
We’re instructing the compiler to disable the warning for rule 0067, which is the error given above, and then immediately after the problematic line, we’re re-enabling it.
And as noted on the post…
Caveat: As per the comment by @Jon Hanna, perhaps a few warnings is in order for this, for future finders of this question and answer.
First, and foremost, the act of suppressing a warning is akin to swallowing pills for headache. Sure, it might be the right thing to do sometimes, but it’s not a catch-all solution. Sometimes, a headache is a real symptom that you shouldn’t mask, same with warnings. It is always best to try to treat the warnings by fixing their cause, instead of just blindly removing them from the build output.
Having said that, if you need to suppress a warning, follow the pattern I laid out above. The first code line, #pragma warning disable XYZK, disables the warning for the rest of that file, or at least until a corresponding #pragma warning restore XYZKis found. Minimize the number of lines you disable these warnings on. The pattern above disables the warning for just one line.
Also, as Jon mentions, a comment as to why you’re doing this is a good idea. Disabling a warning is definitely a code-smell when done without cause, and a comment will prevent future maintainers from spending time either wondering why you did it, or even by removing it and trying to fix the warnings.
Roll on zero-warning compilations.
Finally, the web is really moving to using HTTPS (thank you Google/Chrome!) This change is long overdue, and it will be good to finally be able to eliminate the vulnerability of HTTP.
“But“, cry some customers, “I don’t wanna pay for certificates!“.
Bought TLS certificates, well, cost money, and often non-technical customers don’t see any value in them. All they see is cost. If only there were a free alternative.
Good news! LetsEncrypt freely offer free DV certificates for free. That is, in fact, their raison d’être. Bad news – they only last 90 days. Bugger. Our support team won’t dreadfully want to have to renew lots of certs every 90 days. If only this could be automated… Wait, it can be!
One of my colleagues mentioned using WinAcme to get/renew certificates with LetsEncrypt, so I thought I’d give it a go. How hard can it be? Continue reading “Using LetsEncrypt with IIS via WinAcme”
When rebuilding the Link Database for the Core database on Sitecore 9.0 Update 1 (XP0 configuration), I received 630 errors!
The Link Database rebuild continues, and appears to complete successfully. I didn’t see any problems arising from this, but 630 errors is quite a lot.
I was also able to replicate this on several different development systems for different customers. I even set up a new, unmodified Sitecore 9.0 Update 1 – XP0 instance locally, and replicated the problem. Each system shows 630 errors per Core’s Link Database rebuild. Rebuilding Master or Web databases does not cause this error.
It appears that the issue is to do with deserialising the layout field’s XML during Links Database rebuild. It seems some items must have a layout that is “:”.
I raised this with Sitecore and got a very quick response. Continue reading “Rebuilding Core’s Link Database on Sitecore 9.0 Update 1 generates lots of errors”
I was recently doing some token replacement of field values using a processor that I was adding to the RenderField pipeline. The problem was, it wasn’t running in Glass. Debugging in Visual Studio, the pipeline was never hit. Standard Sitecore rendering of the field was fine, but Glass – nope. Continue reading “Glass, ForceRenderField, and the RenderField pipeline”