Porting Inversion part 2

Things have progressed and I think it’s time to write up and highlight a few items.

Choices of what to port

There are some things which I have chosen to abandon for now. These include my Inversion.Web.Razor extensions in inversion-razor, and the ConfigurationHelper and Pipeline models for service containers in Inversion.Extensibility.

In the case of the Razor extensions, I think I will need to rewrite this entirely in light of the AspNetCore support for Razor. I’d much rather be integrated with that than remain off-piste with Antaris RazorEngine.

Regarding ConfigurationHelper and Pipeline interfaces, the configuration options are so starkly different in .Net Standard, and so much easier to deal with, that there’s no point having a shim to pull configuration from a database etc when the new methods are so much more accessible.

Publishing to NuGet

I’m not sure which sociopath designed the web UI for NuGet, but they need their head examining; they’re clearly insane. It’s not quite as bad as the Visual Studio interface though, at least.

Having fought through the various stuff it puts in your way to prevent you getting a clean package uploaded, the various repos - inversion-dev, inversion-data, inversion-data and inversion-messaging - have been made available. The assemblies that make up those repos are available separately in order to keep project tech hierarchies segregated, e.g. Inversion.Data base library is separate to Inversion.Data.AmazonSQS which is separate to Inversion.Data.Redis etc. Don’t cross the streams unless you have to.

The versions are in the 1.0.x range and the references of child packages to their parents are currently set to 1.0.* as I was pretty shocked how stupid the management of minor versions was in the NuGet CLI. Anyway, working now.

GitHub organisation

The main libraries are now under the newly formed inversion-org GitHub organisation - https://github.com/inversion-org

Guy, Rob and myself are owners.

Here you will find:

• Inversion.Data
• Inversion.Extensibity
• Inversion.Messaging

The main Inversion library hasn’t moved yet but this will be its home in the future. You can still find it here:

• Inversion

Other libraries, such as Inversion.Ultrastructure will also be moved into the organisation shortly.

Adding Travis automation

Some Travis automation has been added to build and publish the NuGet packages, which it does sort of blindly as it doesn’t check first if the version already exists and so seeks forgiveness rather than permission when it fails to upload. I suppose there might be ways to automate incrementing the patch number on the .csproj file, but at the moment it is manual.

Things to do next:

• add unit tests (with automation for commit status updates)
• test the libraries work!
• create basic application that uses the libraries via NuGet and can be deployed as a container

Porting Inversion

Just recently I have been porting the Inversion libraries over to .Net Standard, such that they will be able to support the existing set of behavioural applications that make up the image delivery part of the Digital Library Cloud Service (see https://dlcs.info).

To do this I received some initial help from Robert Stiff (@UatecUK) to prove that the basics would work in the new execution environment, since it is vaguely exotic, having been based around the Reactive Extensions for .Net. Once we had ported the OWIN-based hello-world website across, I was convinced that I would be able to port across almost the entire application.

Last weekend I set about taking the ported versions of the libraries in https://github.com/guy-murphy/inversion-dev, giving them some basic metadata and publishing them to NuGet as .Net Standard 2.0 packages (and yes, I have Guy’s explicit permission to do this). This included the new web code that Robert and myself tested the proof of concept with which has been added as the Inversion.Web.AspNetCore package.

Next, I ported and published the libraries in Inversion.Data (https://github.com/fractos/inversion-data) into separate NuGet packages. This means that the different storage dependencies will remain separate in a target application.

Inversion.Extensibility (https://github.com/fractos/inversion-extensibility) was ported and published next, with a separate package for Inversion.Extensibility.Web.

Finally, I ported Inversion.Messaging (https://github.com/fractos/inversion-messaging) and packaged it separately, just as I had done for Inversion.Data.

It should be noted that each of these repositories has a separate "dotnetcore" branch for this code.

Things to do next:

• add unit tests
• add Travis CI scripting to build, pack and publish to NuGet
• test the libraries work when imported!

Bending the world so log4net can work

log4net.

Firstly, why the Hell would you change the public key of a strongly named assembly between versions?

Secondly, WHY THE HELL WOULD YOU CHANGE THE PUBLIC KEY? Jesus.

Yes, I've read http://logging.apache.org/log4net/release/faq.html#two-snks and that just reeks of the development team having some kind of argument with people outside of their anointed circle of coders.

Anyway, there's a requirement on some old CMS code in a project I'm working on, and the DLLs have got a reference to log4net 1.2.10 while the rest of the world is staring down the barrel of 1.2.13.

Incidentally, I think it's really bad form to put numbers into assembly names, and, further, to have version 1.2.13 to be a completely different NuGet version (2.0.3). Seriously, what the fuck?

I found this post which really helped - you can reference two different versions if they use a strong name as long as you stick them in different folders, whilst keeping a reference in the project to the later one but setting Copy Local to false. I also added a pre-build event on the website which would make the folders if they didn't exist and copy the appropriate DLLs into each.

http://stackoverflow.com/questions/3158928/referencing-2-differents-versions-of-log4net-in-the-same-solution

However, the finishing touch was that since this was an endpoint - i.e. a website where lots of DLLs are bundled up together - then it needed to have the right path; in this case, it needed "bin\" prepended to it:


Currently reading: