GPIO support is not fully launched in dotnet core 3 currently

I’m developing using dotnet core on Raspberry Pi.

After the dotnet core 3 launched finally, I rushed to the released version from the preview one. Some package I used, like System.Devices.Gpio, was published in dotnet-corefxlab under myget. Now I can find it on nuget.

But, sadly, the current version of System.Device.GPIO (not Devices, but Device) in nuget seems contains only abstract classes. The UnixSpiDevice, GpioPin and something useful are missing in the version of nuget. Now I have to turn back to use the preview version on myget.

Good thing to know is, the preview version of Gpio supports dotnet core 3 with no problem.

MSDN Magazine

It says MSDN Magazine is ended.

Here is the MSDN Magazine collection. All files are mainly downloaded from official site.

The issues listed below are replaced by the versions from emails due to reason specified.

  • 2018 Jan version: Wrong link to 2017 Jan.
  • 2018 Connect(); Missing link
  • 2019 July: 404 link
  • 2019 October: Not published yet.
  • 2019 November: Not published yet.

Bug and workaround in dotnet MEF — The export is not assignable to type .

Today, while writing an app use netfx 4.8 with MEF support based on System.ComponentModel.Composition 4.5 from nuget, a strange bug hit me.

Because I’m not treat MEF as essential, I’d like to write the main code in a project and create MEF wrap in another one like:

  • In Project A: class Real : InterfaceA
  • In Project B: class MEFWrap : Real, and marked with Export attribute.

Certainly, Project A is referenced by Project B.  While building the solution, both dlls generated from Project A and Project B are placed in the output folder of Project B.

While trying to use MEF to load the class from Project B, the funny thing happened:

  • If AssemblyCatalog is chosen to create the object, from the assembly object loaded by LoadFrom method, nothing is wrong, but
  • If AggregateCatalog is used with all assemblies loaded from the folder (Project A and Project B) at the same time, an exception raised while calling ComposesParts:

    The export InterfaceA is not assignable to type InterfaceA.

I don’t know why it’s happened but here are 2 ways to get avoid of it.

  • Only load assembly Project B, not both of them, if it’s possible, when you know the name or name pattern while searching files, or
  • Using AssemblyCatalog for each file, instead of using AggregateCatalog as a whole, will also works.

 

 

Multiple Low-end bar code scanners support for dotNet

Adds support for low end bar code scanners, which work as a keyboard only. By using this library, you can receive code from multiple scanners with the scanner handle id or name (seeing demo on Github).

Platform: dotNet Framework 4 on Windows x86, or x64 with 32-bit compiling (need 32-bit due to WinAPI calling)

Package: Nuget

Source code: Github

License: Demo and Test projects are licensed under MIT. Main and other libraries are licensed under LGPLv3.

All I want, is write a lock…

Today, I need to use an instance of synced version of HashSet in C#, aka, ConcurrentHashSet<T> in tech language.

First, I dig some in GitHub and NuGet. I found 2 solutions contains this solution, as they described. One has the exact name of ConcurrentHashSet, but it’s not implemented the ISet<T>. Another is a big set which contains this class with the name, which is written using ConcurrentDictionary<T>, with no ISet<T> implemented either.

Hmm, it seem that if I really need ISet<T> support, I have to do it myself. Let me create class inherited HashSet<T> to write some overridden methods and properties with lock… Wait a minute, only 3 methods from Object is allowed for overriding? Wtf.

If I cannot stand on the shoulders of HashSet<T>, let me dig the HashSet<T> first. Luckily, Microsoft released the source code of the entire dotNet framework. HashSet<T> is included as well. All I need to copy the whole code into mine and… Uhh? What’s the license of the file?

By asking a lawyer friend, I’m told that I MAY have right to use this code in my program but I’m NOT GRANTED to publish the ConcurrentHashSet<T> I wrote separately. That maybe the reason why I failed in the first step — Microsoft didn’t finish their job and don’t allow anyone to fix it for them.