Posted by jpluimers on 2015/11/25
Code Analysis in Visual Studio objects against using very generic exception types:
CA2201 Do not raise reserved exception types
‘BusinessClass<T>.StopProcessing()’ creates an exception of type ‘ApplicationException’, an exception type that is not sufficiently specific and should never be raised by user code. If this exception instance might be thrown, use a different exception type.
Company.Departement.Functionality BusinessClass.cs 157
Indeed ApplicationException and SystemException are bad (both mapping to also very generic COM HRESULT values COR_E_APPLICATION / -2146232832 / 0x80131600 and COR_E_SYSTEM / -2146233087 / 0x80131501).
Using InvalidOperationException is much nicer in this case. It still maps to a COM exception (in this case COR_E_INVALIDOPERATION / -2146233079 / 0x80131509).
Posted in .NET, .NET 3.0, .NET 3.5, .NET 4.0, .NET 4.5, C#, C# 3.0, C# 4.0, C# 5.0, C# 6 (Roslyn), Development, Software Development | Leave a Comment »
Posted by jpluimers on 2015/11/24
A while ago, I came across a class having (among other members) two methods named like this:
Within one of the other members of the class, I had to (temporarily) Stop processing, then Start it again.
But I couldn’t, as neither Start, nor Stop would make a record of the state it left the instance in.
Always ensure you know the state of an instance.
So I added the state, and tests to ensure a Stop/Start change was indeed not breaking things.
Posted in .NET, .NET 1.x, .NET 2.0, .NET 3.0, .NET 3.5, .NET 4.0, .NET 4.5, C#, C# 1.0, C# 2.0, C# 3.0, C# 4.0, C# 5.0, C# 6 (Roslyn), Delphi, Delphi 10 Seattle, Delphi 2007, Delphi 2009, Delphi 2010, Delphi XE, Delphi XE2, Delphi XE3, Delphi XE4, Delphi XE5, Delphi XE6, Delphi XE7, Delphi XE8, Development, Software Development | 1 Comment »
Posted by jpluimers on 2015/11/17
If you ever need a universal Android ADB driver for Windows, then use this one: koush/UniversalAdbDriver.
I never noticed it was there until Koushik Dutta posted about a signing trick on Google+.
Windows drivers need to be signed, so what he does is generate a self signed certificate on the fly during installation, sign the driver install it, and drop the private key of the certificate.
Each installation has its own key, Microsoft is happy, and it is proven the driver signature mechanism in Windows has a hole.
If you want to do similar things, then this commit is what you are looking for: Use a self signed, self destructing signing cert. · e8b78fe · koush/UniversalAdbDriver.
It isn’t rocket science, but not trivial C# either, so this is a great example of something that works.
Posted in .NET, Android, C#, Development, Mobile Development, Software Development | Leave a Comment »
Posted by jpluimers on 2015/11/04
From a chat with a co-worker a while ago:
So even if you expose such a property as read-only, it can still get its writeable fields overwritten.
That is a pain when those are part of the state of the underlying object.
In other words: encapsulate your state changes.
Here we solved it by making
- the type of the property immutable
- the property writeable
- react on state changes during the write
In this case it was a project mixing C# and Delphi, but you can easily apply the above to any language featuring classes and properties.
Another solution would have been to extend the type of the property so it can expose an event that fires during change. Much more convoluted.
Posted in .NET, C#, C# 1.0, C# 2.0, C# 3.0, C# 4.0, C# 5.0, C# 6 (Roslyn), Delphi, Delphi 10 Seattle, Delphi 2007, Delphi 2009, Delphi 2010, Delphi XE, Delphi XE2, Delphi XE3, Delphi XE4, Delphi XE5, Delphi XE6, Delphi XE7, Delphi XE8, Development, Software Development | 2 Comments »
Posted by jpluimers on 2015/11/03
Lazy<T> is not constrained to static contexts.
Instance field initialisers cannot use instance references (but can use static references) as they run outside of the constructor.Though there are arguments for instance field initialisers too., I think this is a good reason to initialise fields inside the constructor: there you do have access to instance references (but should not call virtual instance methods or properties) which leads to another reason: consistency as field initialisers run in the opposite hierarchy order as constructors (incidentally causing this virtual method restriction).
Boy, that was a long sentence (:
Posted in .NET, .NET 1.x, .NET 2.0, .NET 3.0, .NET 3.5, .NET 4.0, .NET 4.5, C#, C# 1.0, C# 2.0, C# 3.0, C# 4.0, C# 5.0, C# 6 (Roslyn), Development, Software Development | Leave a Comment »