Category: Software

For our Slido integration with Microsoft PowerPoint on macOS we used the Sparkle library to do automatic updates of our main Slido application. Our code also runs inside PowerPoint and we need to do checks if new versions are available. Unfortunately we cannot use the full Sparkle framework because of technical limitations for add-ins running in Office apps on macOS.

Sparkle framework uses the Appcast format for updates. This is an RSS document with additional Sparkle data to facilitate minimum system requirements, critical updates and delta updates information. Sparkle is written in ObjectiveC language and it does not provide a library target just for the Appcast implementation in their Swift package definition.

Our app and addin code is written mostly in Swift and we would prefer to integrate a Swift code for parsing Appcast documents. The authors of Sparkle project would like to keep it Objective C only for compatibility with very old OS X versions. Otherwise we would provide class-by-class migration from Objective C to Swift pull requests back to the Sparkle project.

Individual library

I have decided to write a new Appcast parsing library in pure Swift. The original Appcast code is very stable so the new library can be kept compatible with Sparkle code.

The RSS format and Sparkle extensions are quite simple and the original Appcast code in Objective C is small so rewriting it in Swift was easy.

The first preview release will parse the Appcast document and provide simple data in the AppcastItem structure. This proves we can create modern library which works in our Slido integration with Microsoft PowerPoint.

Integration tests

Sparkle framework has a large integration tests suite for parsing Appcast files. Their integration tests are in a single large test suite. To get better picture about features implemented in the new Appcast library I had to refactor large tests into small test function focused to just do single and focused checks.

I have followed the Definition of a Unit Test from Roy Osherove when refactoring tests. The The Art of Unit Testing book is a great guide for writing tests, refactoring legacy code and ensuring the trustworthiness of tests.

Refactoring of tests is available in the slidoapp/Appcast@test/appcast branch.

What's next?

The new library needs to implement the same logic for resolving the best available update in the Appcast file to match the behavior of Sparkle framework. As we don't need the delta updates (our DMG is just 8MB large) we will skip implementing information about delta updates in first releases.

TLDR: To fix this issue, migrate your project to use our official packages which are named NetOfficeFw and are published by netoffice account.

> This bug does not exists in the NetOfficeFw.Core v1.7.4.11 package and it is not a bug in the official NetOffice source code.

Symptoms

When you use packages like NetOffice.Word, NetOffice.Excel, NetOffice.Oulook and others published by netofficedotnet on NuGet.org, you will encounter error System.NullRe­ferenceExcepti­on: ‚Object reference not set to an instance of an object.‘ when using NetOffice code. (Note the missing Fw in package names.)

In Output window you will see an exception is thrown when calling NetOffice code:

Exception thrown: 'System.NullReferenceException' in NetOffice.dll
Object reference not set to an instance of an object.

This exception is thrown by method NetOffice.Core.TryLoadAssembly(string fileName):

NetOffice.dll!NetOffice.Core.TryLoadAssembly(string fileName)
NetOffice.dll!NetOffice.Core.Initialize(NetOffice.CacheOptions cacheOptions)
NetOffice.dll!NetOffice.Core.CreateKnownObjectFromComProxy(NetOffice.COMObject caller, object comProxy, System.Type wrapperClassType)
ExcelApi.dll!NetOffice.ExcelApi._Application.Workbooks.get()

Cause

There are fake packages on NuGet published by Erika LeBlanc (GitHub account erikaleblanc88, NuGet account netofficedotnet). These fake NetOffice assemblies does not work properly. That account is doing a lot of shady stuff in the https://github.com/netoffice organization (rewriting code history, deleting comments and issues, to name a few).

Because the published packages contain fake assemblies, you will encounter this exception by using NetOffice.Core v1.7.4.11.

Read more in our NetOffice Migration Guide

Official Releases

You will find official releases wither on NetOffice on OSDN or at GitHub

NetOffice is a great .NET library which can be used to develop solutions for Microsoft Office apps. The library supports automation and extension scenarios.

Automation

Use the NetOffice library to automate Microsoft Office apps. You can generate Office documents, transform and print them.

You can automate repetitive actions like adding signatures and pictures to Word documents, or generating Excel spreadsheets which must use the same Excel formulas you would manually create.

Extensions

NetOffice has first class support for Microsoft Office Add-ins – rich extensions which can modify user interface inside Office application and allow users to access complex features.

NetOffice add-ins are written in managed .NET code so the development is easy, productive and you can debug them from Visual Studio.

NetOffice documentation is available at https://netoffice.io/ and you can join the development community on GitHub at https://github.com/NetOfficeFw

gitattributes.io is a service for generating .gitattribute files from templates. The service is inspired by gitignore.io where you can quickly bootstrap your .gitignore files.

Choose templates on web interface, or use the very simple API to list template names and generate new .gitattribute file content.

To generate .gitattributes file for you web project, just call:

https://gitattributes.io/api/web

Working on a C++ project in Visual Studio? Separate multiple template names with a comma:

https://gitattributes.io/api/c++,visualstudio

The list of all template names is available at api/list endpoint:

https://gitattributes.io/api/list

This service was made possible by the project from alexkaratarakis who created the original alexkaratarakis/gi­tattributes repository with .gitattributes templates. You can contribute to gitattributes.io project at github.com/gi­tattributes

Jedným z najúspešnejších článkov môjho blogu je Číslovanie strán od určitej strany v MS Word, ktorý má najvyššiu návštevnosť hlavne v apríli, keď najviac študentov píše diplomové práce.

Tento článok však dlhú dobu nemal dostupné obrázky znázorňujúce kontrétne kroky v Microsoft Word 2003 pre nastavenie číslovania strán, pretože som pri aktualizácii WordPress systému zabudol presunúť niektoré obrázky zo starého priečinku do nového.

Dnes je už chyba opravená a študenti majú dostupný celý manuál, ktorý im pomôže v očíslovaní ich diplomoviek a iných záverečných prác. Teraz už chýba iba príručka ako nastaviť číslovanie v nových verziách Word-u, ktoré majú ribbon rozhranie.

V bývalej práci som sa naučil, že je výborné mať na softvérovom projekte bug tracker (používali sme, a ešte stále používam(e) FogBugz), verziovanie zdrojového kódu (Subversion alebo Mercurial Hg) a automatické buildy (CuiseControl­.NET). Mám skúsenosť s tým, že firmy používajú repozitár so zdrojovým kódom a bug tracker systém, ale málokedy majú nainštalovaný a funkčný systém, ktorý zautomatizuje kompiláciu a nasadenie aplikácie. Súvisí to aj s tým, že buildovacie systémy sa komplikovane nastavujú a treba sa o ne starať viacej, ako Subversion repozitár či bug tracker.

Pri mojich prvých automatických buildoch, ktoré som mal možnosť konfigurovať, som používal NAnt. Kolega bol expert na Ant, NAnt a ostatné veci okolo projektového manažmentu a pred niekoľkým rokmi bol NAnt jediný spôsob, ako jednoducho napísať skript, ktorý skompiluje zdrojový kód, spustí unit testy, vytvorí balíček aplikácie (ZIP so súbormi webovej aplikácie, alebo spustí nástroje pre vytvorenie inštalačného balíčku) a zarchivuje výsledný build. Toto sú základné veci, ktoré sa zídu snáď na každom projekte a v dobe .NET 1.0 a 1.1 bolo v NAnt-e potrebné skriptovať kompiláciu na úrovni jednotlivých zdrojový súborov a manuálneho volania. V prípade C# projektu to znamenalo zobrať všetky .cs súbory a použiť csc.exe kompilátor, nájsť výslednú DLL/EXE assembly a niečo s ňou spraviť. Nevýhoda tohto postupu bola, že treba všetko ručne písať a Visual Studio robilo vlastnú kompiláciu podľa projektového súboru .csproj a NAnt robil druhú podľa vlastných nastavení. Bol to však vynikajúci a silný nástroj, ako celý proces zautomatizovať.

S .NET Frameworkom 2.0 prišiel systém MSBuild, ktorý sa stal základom pre kompiláciu nielen zdrojového kódu, ale celého projektu. MSBuild spracuváva projektové súbory (.csproj, .vbproj) vo formáte XML a okrem kompilovania dokáže aj spracovať resource súbory .resx, XAML súbory, digitálne podpísať assemblies a skopírovať výsledné súbory do výstupného priečinku. MSBuild obsahuje pre každý typ projektu vlastnú sadu úloh, ktoré vedia, ako správne konkrétny typ projektu spracovať. Windows aplikácie teda dokáže správne pripraviť na Click-Once nasadenie a webové aplikácie zase zabaliť do balíčku, ktorý je možné poslať na IIS a nasadiť tak aplikáciu na web. A ani poslanie tohto balíčku nemusíte robiť ručne – MSBuild obsahuje úlohu, ktorá automaticky pošle balíček na IIS server.

Visual Studio a MSBuild sú spolu integrované a preto čo zmeníte vo Visual Studiu, to sa prejaví v projektovom súbore a MSBuild ho rovnako spracuje aj pri spustení z príkazového riadku. Vývojári teda po zmene nastavení projektu môžu zmenený projektový súbor uložiť do repozitáru a keď sa na serveri spustí automatický build, tak si môžu byť istý, že bude spustený s novými nastaveniami a nemusia pracne prekonfigurovávať a prepisovať buildovacie skripty. MSBuild je súčasťou základnej inštalácie .NET Frameworku a nie je potrebné mať nainštalované Visual Studio pre jeho použitie. Toto sa však týka použitia základných úloh dostupných v MSBuild. Po nainštalovaní si Visual Studia a Windows SDK sa do MSBuild pridajú nový typy úloh, ktoré vedia pracovať s novými funkciami potrebnými pre správne zbuildovanie projektov (napr. sa nainštalujú nástroje pre kompiláciu Entity Framework súborov). Na build serveri teda je potrebné mať nainštalované Visual Studio a Windows SDK a udržiavať ich aktuálne – podľa toho, ako to vyžadujú použité funkcie v projektoch – ale integrácia s build systémami je veľmi jednoduchá, pretože na skomplikovanie projektu stačí spustiť msbuild.exe z príkazového riadku.

Priamu podporu pre MSBuild má CruiseControl.NET a aj TeamCity a samozrejme Team Foundation Server (a určite aj ďalšie systémy, ja však poznám iba tieto).