I started getting this error this morning in my Sitecore logs:
System.InvalidOperationException: Ensure definition type did not complete successfully. StatusCode: 500, ReasonPhrase: ‘Internal Server Error’, Version: 1.1
I noticed this ‘cos analytics stopped working overnight:
What gives? Continue reading “Sitecore: System.InvalidOperationException: Ensure definition type did not complete successfully”
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.
Following up my last post about Troy Hunt and breached passwords, I thought I’d look at something it mentioned – zxcvbn password strength estimation. Password strength estimators are, as a rule, crap. Usually it’s simply “is there a number, is there a capital”, etc., so passwords like “P@ssword1234” can come out as being ‘strong’, which is clearly wrong.
zxcvbn (awful name) attempts to make a smarter estimate of password strength. Basically, it looks at your password, and tries to estimate its strength based on appearances in dictionaries, structure, and entropy. It’ll then give an estimated “time to crack”, and tell you any matches that were achieved. For example (and neither of these are good passwords – score goes up to 4, and you want to get at least 3):
Yup, that’s pretty cool.
It’s available as a Nuget package (and is implemented in some form in most frameworks). The original zxcvbn was intended to run solely within the browser – but it still had a 0.5 Mb of dictionary files to download. That’s built into the assembly for the Nuget.
Testing a password – that’s simple:
var result = Zxcvbn.MatchPassword(“Squeamish Ossifrage”);
Neat. Worth considering if you’re implementing a password change or registration feature.
Bonus observation: http://gavinmiller.io/2016/a-tale-of-security-gone-wrong/