Annotate viewer broken under mixed-DPI about ankhsvn

[PhilJollans]

My check in comment on the initial changes to AnkhSVN2019 outlines why I made a new implementation.

Work in progress on annotate command

I have given up hope that I can repair the original implementation of the Annotate function. The original version places a WinForms user control inside a document window and embeds a text editor in that user control.

So far as I can tell, it is no longer possible to place a WinForms user control directly in a document window.

The approach taken to embedding a text editor in the user control is designed to work in Visual Studio going back to version 2005. I suspect that it is much more complicated than it needs to be in Visual Studio 2019.

For these two reasons I have started restructuring the implementation using a WPF control and instantiating the editor in a completely different manner.

This is long way from being finished, but it is the bones of a working implementation.

However, I am still considering whether the annotation margin should be implemented as an editor margin. Fundamentally I think that would be a good idea, but I still have some open questions about how to implement that.

If I went that way, it would require more restructuring.

The implementation works fairly well, by I never found a set modify the caption in the tab on the editor window. Just from the tab, is looks like a normal editor window. At the time, I posted a question on StackOverflow, but never found a workable solution.

There is an open issue about handling the zoom level, but I guess this can be fixed.

I never paid any attention to older versions of Visual Studio. If this repository is the version in VS Marketplace which supports VS 2017 and VS 2019, it will probably work.

I have not tried to compile the version from this repository. If it is easy, then I could try to integrate my version of the Annotate viewer into this repository (or a fork of it). However, I will definitely not have time before October.

I found compiling from the original CollabNet repository anything but easy.

[PhilJollans]

Hi Bert,

I have forked your repository with the intention of moving my implementation of the Annotate viewer into this version.
I have hit a problem which I don't understand and I don't know how to fix.

My implementation uses a WPF UserControl, which I would move into the project Ankh.UI. For this I have added references to PresentationCore, PresentationFramework, System.Xaml and WindowsBase.

If I now select Add / New Item / WPF / UserControl(WPF), then it adds a new control UserControl1.xaml to the project. So far, there is no code from me.

If I now build the project, I get the following error:

1>C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Microsoft.WinFx.targets(268,9): error MC1000: 
Unknown build error, 'Could not load type 'SharpSvn.Implementation.SvnLibraryAttribute' from assembly 
'SharpSvn, Version=1.14001.54.0, Culture=neutral, PublicKeyToken=d729672594885a28' 
because the method '.ctor' has no implementation (no RVA).' 

I think RVA is probably Relative Virtual Address.

If I exclude UserControl1.xaml from the project, the error goes away. I can see no connection whatsoever between the WPF control and this error message.

I don't know if this is a problem which has to be fixed in SharpSvn or AnkhSvn, but for now, I am completely stuck.

[rhuijben]

This appears to be an issue with the reference assembly created by the Sharpsvn build... The designer should have picked the actual binary instead of the reflection only version.

[PhilJollans]

Is there anything I can do to get around the problem, or is it something which has to be fixed in SharpSVN?

[rhuijben]

Looks like this is/was an issue in https://github.com/JetBrains/Refasmer, which is used for creating the reference assembly.
I'm building a new SharpSvn and will publish it in NuGet.

[rhuijben]

@PhilJollans I just updated the SharpSvn reference with some fixes via a newer Refasmer used there. If this doesn't fix this we should probably switch to a mock assembly instead of a reference assembly for this case, though I would hope not every reference assembly has this problem.