Here is some notes, possibly for Microsoft folks, if they want to make the older csproj files work on the updated code.

• in general, removed parts (Win32APIs, WinVerifyTrustAPI, truetype.NET, fscaler) are replaced by the Compat module.
• the new code no longer needs the COM/ActiveX mshtml primary interop reference assembly and friends.

So just by removing most reference to mshtml and changing references to all the removed bits to 'Compat' should work; of course a new csproj file for the Compat module needs to be added.

After the DSIG work, there is a slight complication - there is circular dependency where the DSIG part of Compat uses OTFontFile . So the Compat module is built twice, once without the DSIG stuff then later with. One way of solving this is to build the Compat.2nd part with OTFontFile or OTFontFileVal if one is to make the whole thing buildable with visual studio.

In a way the circular dependency is artificial - it comes from trying to separate replacement things I wrote and things from Microsoft; so one part I wrote also depends on Microsoft stuff, instead of most Microsoft stuff depending on my replacements. If one freely build my replacement stuff together with Microsoft stuff into single assembly, any circular dependent becomes just mutual dependencies within an assembly and therefore immaterial.

The mine/Microsoft divide is much blurred in the more recent work where whole parts are rewritten - the XML viewer code and the CFF tests, as well as the new SVG tests; so the divide does not need to be taken too seriously, at least for trying to get visual studio to build this.

Building with Visual Studio has been re-instated with the two commits:

14f5191

6082793

which depends on a pre-built Compat.dll (which replaces all the not-opened parts)

There is only one issue left: a new vc# project file for the Compat module. The 4 files added in the Compat.2nd GNU make target can go into OTFontFileVal project file. After these two tasks, reference to pre-built Compat.dll can be switched over to referenceproject.

@prepare @none53 : apologies I only saw your forks while I was preparing my FontVal talk last week. I should have pointed you two to this issues on my notes.

Hm. How about tossing Makefile and VS-specific build files and use CMake for cross-platform building? Microsoft has started supporting CMake a while ago.

Ok, so things seem to work differently in Microsoft's world. What at this point would prevent this project from going with just "solution" files and using MSBuild on Windows and Mono's xbuild everywhere else?

@prepare @none53 @madig : I just tagged FontVal-2.1.3 . It should be buildable with just msbuild from vs2008 (express) onwards. Tested the binaries (both GUI and command-line) with wine already and functionally identical to Linux/mono build.

@madig : found a few incompatibility issues on the way between msbuild/csc and xbuild/mono 4.x . Probably unimportant as mono 5.x deprecates xbuild, ships msbuild and also roslyn (ms's csc supposedly mostly). So the incompatibility will be immaterial when I upgrade my Linux box to mono 5.x

Argh, I forgot to update the readme before I tagged. Never mind, as long as people know that now it is supposed to work.

@prepare @none53 : apologies I never got round to look at your work - mostly I was looking for supporting the oldest vs without breaking mono-based build, so using the latest vs and/or moving source files around found in some of your work are not what I want. Now that I have completed vs2008 build-ability, I 'll go back and look at what you two did and see what can be merged, at some point.