The type initializer for 'Markdig.Wpf.MarkdownViewer' threw an exception #248

New Issue

claunia · 2026-01-29T14:31:38Z

claunia commented

2026-01-29 14:31:38 +00:00

Originally created by @FoggyFinder on GitHub (Dec 16, 2018).

The code below doesn't compile with new version of markdig (0.15.5)

open FsXaml

type TestWindowBase = XAML<"TestWindow.xaml">

type TestWindow(md) as self =
     inherit TestWindowBase ()

     do self.mdviewer.Markdown <- md

let sampleMD = """
| Tables        | Are           | Cool  |
| ------------- |:-------------:| -----:|
| col 3 is      | right-aligned | $1600 |
| col 2 is      | centered      |   $12 |
| zebra stripes | are neat      |    $1 |
"""

let window = sampleMD |> TestWindow 

[<EntryPoint>]
[<System.STAThread>]
let main argv =
    System.Windows.Application().Run window

where TestWindow.xaml is:

<Window xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:markdig="clr-namespace:Markdig.Wpf;assembly=Markdig.Wpf">
    <Grid>
        <markdig:MarkdownViewer Name="mdviewer" />
    </Grid>
</Window>

It works fine with 0.15.4 although.

Initally I opened issue in markdig.wpf. Still not sure where it should be open.

Originally created by @FoggyFinder on GitHub (Dec 16, 2018). The code below doesn't compile with new version of markdig (0.15.5) ```fsharp open FsXaml type TestWindowBase = XAML<"TestWindow.xaml"> type TestWindow(md) as self = inherit TestWindowBase () do self.mdviewer.Markdown <- md let sampleMD = """ | Tables | Are | Cool | | ------------- |:-------------:| -----:| | col 3 is | right-aligned | $1600 | | col 2 is | centered | $12 | | zebra stripes | are neat | $1 | """ let window = sampleMD |> TestWindow [<EntryPoint>] [<System.STAThread>] let main argv = System.Windows.Application().Run window ``` where `TestWindow.xaml` is: ```xaml <Window xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:markdig="clr-namespace:Markdig.Wpf;assembly=Markdig.Wpf"> <Grid> <markdig:MarkdownViewer Name="mdviewer" /> </Grid> </Window> ``` It works fine with 0.15.4 although. Initally I opened issue in [markdig.wpf](https://github.com/Kryptos-FR/markdig.wpf/issues/20). Still not sure where it should be open.

claunia closed this issue

2026-01-29 14:31:39 +00:00

claunia commented

2026-01-29 14:31:39 +00:00

@xoofx commented on GitHub (Dec 16, 2018):

Doesn't compile? What's the error? How do you want me to evaluate if this is a markdig issue?

@xoofx commented on GitHub (Dec 16, 2018): Doesn't compile? What's the error? How do you want me to evaluate if this is a markdig issue?

claunia commented

2026-01-29 14:31:40 +00:00

@FoggyFinder commented on GitHub (Dec 16, 2018):

Doesn't compile? What's the error?

The type initializer for 'Markdig.Wpf.MarkdownViewer' threw an exception

I can attach test project but let me check it on C# project first.

@FoggyFinder commented on GitHub (Dec 16, 2018): > Doesn't compile? What's the error? `The type initializer for 'Markdig.Wpf.MarkdownViewer' threw an exception` I can attach test project but let me check it on C# project first.

claunia commented

2026-01-29 14:31:41 +00:00

@MihaZupan commented on GitHub (Dec 16, 2018):

This is a runtime error

@MihaZupan commented on GitHub (Dec 16, 2018): This is a runtime error

claunia commented

2026-01-29 14:31:42 +00:00

@xoofx commented on GitHub (Dec 16, 2018):

Yes, likely a constructor has been changed in markdig, until 1.0, markdig API can break, so Markdig.Wpf has to be recompiled with latest version

@xoofx commented on GitHub (Dec 16, 2018): Yes, likely a constructor has been changed in markdig, until 1.0, markdig API can break, so Markdig.Wpf has to be recompiled with latest version

claunia commented

2026-01-29 14:31:43 +00:00

@FoggyFinder commented on GitHub (Dec 16, 2018):

This is a runtime error

@markheath no, it is a compile error here :-)

Yes, likely a constructor has been changed in markdig, until 1.0, markdig API can break, so Markdig.Wpf has to be recompiled with latest version

@Kryptos-FR can you check it again?

@FoggyFinder commented on GitHub (Dec 16, 2018): > This is a runtime error @markheath no, it is a compile error here :-) > Yes, likely a constructor has been changed in markdig, until 1.0, markdig API can break, so Markdig.Wpf has to be recompiled with latest version @Kryptos-FR can you check it again?

claunia commented

2026-01-29 14:31:43 +00:00

@xoofx commented on GitHub (Dec 17, 2018):

Yes, likely a constructor has been changed in markdig, until 1.0, markdig API can break, so Markdig.Wpf has to be recompiled with latest version

Note that markdig might be able also to provide backward compatibility on this constructor. PR welcome.

@xoofx commented on GitHub (Dec 17, 2018): > Yes, likely a constructor has been changed in markdig, until 1.0, markdig API can break, so Markdig.Wpf has to be recompiled with latest version Note that markdig might be able also to provide backward compatibility on this constructor. PR welcome.

claunia commented

2026-01-29 14:31:43 +00:00

@Kryptos-FR commented on GitHub (Dec 17, 2018):

It works for me with if I upgrade to 0.15.5. I did not try to just replace the dll (without recompiling) because I assumed minor versions would not break binary compatibility.
@xen2 maybe I should package with exact version instead of >= as a dependency?

@Kryptos-FR commented on GitHub (Dec 17, 2018): It works for me with if I upgrade to 0.15.5. I did not try to just replace the dll (without recompiling) because I assumed minor versions would not break binary compatibility. @xen2 maybe I should package with exact version instead of `>=` as a dependency?

claunia commented

2026-01-29 14:31:44 +00:00

@xoofx commented on GitHub (Dec 17, 2018):

I assumed minor versions would not break binary compatibility.

Yeah, I'm trying to follow semver2.0, specifically the item 4:

Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

So in your case, an exact version dependency might be better

@xoofx commented on GitHub (Dec 17, 2018): > I assumed minor versions would not break binary compatibility. Yeah, I'm trying to follow semver2.0, specifically the [item 4](https://semver.org/#spec-item-4): > _Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable._ So in your case, an exact version dependency might be better

claunia commented

2026-01-29 14:31:44 +00:00

@Kryptos-FR commented on GitHub (Dec 18, 2018):

Just FYI the culprit was the UseAutoLinks() extension method that now has a second optional parameter.

@Kryptos-FR commented on GitHub (Dec 18, 2018): Just FYI the culprit was the `UseAutoLinks()` extension method that now has a second optional parameter.

claunia commented

2026-01-29 14:31:45 +00:00

@MihaZupan commented on GitHub (Dec 18, 2018):

Effectively this: https://stackoverflow.com/a/23517490/6845657
Source level compatibility is kept but dlls aren't binary compatible

@MihaZupan commented on GitHub (Dec 18, 2018): Effectively this: https://stackoverflow.com/a/23517490/6845657 Source level compatibility is kept but dlls aren't binary compatible

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/markdig#248