Net Core/Net 5 - Implementation #3197

amaitland · 2020-07-23T05:30:23Z

Track the progress remaining on actually compiling the project with .Net Core

Basic support for compiling with .Net Core was added with #3181 with additional commit (e8cf336) to get the core projects compiling/tests passing,

OffScreen

Add dependency to https://www.nuget.org/packages/System.Drawing.Common/4.7.0 (as uses System.Drawing.Bitmap)

The text was updated successfully, but these errors were encountered:

- Make Wpf/WinForms/OffScreen projects target AnyCPU Only the VC++ projects are platform specific now. - Remove BrowserSubProcess project reference Not needed as we now have a standalone exe - Add OffScreen example - Add WPF Example project - Fix some compile errors for main solution - Add BrowserSubProcess executable - JavascriptObjectRepository remove isAsync param Rather than throw exception remove the option - BrowserSubprocess Exclude the WCF specific code from the netCore project - Add some ifdef/ifndef to exclude the WCF specific implementation - Move WCF implementation into separate namespace

campersau · 2020-07-23T11:44:06Z

The CefSharp.BrowserSubprocess isn't copied into the output directory in netcore because the paths are different and the <Target> definition needs to be changed. Here my proposal:

diff --git a/CefSharp.Native.props b/CefSharp.Native.props
index d34636ef..521c31cf 100644
--- a/CefSharp.Native.props
+++ b/CefSharp.Native.props
@@ -1,12 +1,13 @@
 <?xml version="1.0" encoding="utf-8"?>
 <Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
-    <Target Name="AfterBuild">
-        <ItemGroup>
-            <!-- We only need the .exe and .pdb but I don't know how to express that easily with MSBuild... -->
-            <SubProcessFiles Include="$(SolutionDir)\CefSharp.BrowserSubprocess\bin\$(Platform)\$(Configuration)\CefSharp.BrowserSubprocess.*" />
-        </ItemGroup>
-        <Copy SourceFiles="@(SubProcessFiles)" DestinationFolder="$(TargetDir)" />
-    </Target>
+  <Target Name="CefSharpCopyBrowserSubprocess" AfterTargets="AfterBuild">
+    <ItemGroup>
+      <!-- We only need the .exe and .pdb but I don't know how to express that easily with MSBuild... -->
+      <!-- netcore -->
+      <SubProcessFiles Include="$(SolutionDir)\CefSharp.BrowserSubprocess\$(BaseOutputPath)\$(Configuration)\$(TargetFramework)\CefSharp.BrowserSubprocess.*" Condition=" '$(TargetFramework)' != '' " />
+      <!-- netframework -->
+      <SubProcessFiles Include="$(SolutionDir)\CefSharp.BrowserSubprocess\bin\$(Platform)\$(Configuration)\CefSharp.BrowserSubprocess.*" Condition=" '$(TargetFramework)' == '' " />
+    </ItemGroup>
+    <Copy SourceFiles="@(SubProcessFiles)" DestinationFolder="$(TargetDir)" />
+  </Target>

   <Target Name="CefSharpCopyLibs86" BeforeTargets="AfterBuild" Condition="'$(Platform)' == 'x86'">
     <Message Importance="high" Text="Copying cef.redist x86 files" />

See e8cf336#r40843407

amaitland · 2020-07-24T10:39:59Z

the <Target> definition needs to be changed

Thanks for the tip, was very helpful. I've created a new targets file for the copying as I anticipate additional changes in the future. This should be resolved in commit 4505fdf

- In preparation for adding a Net Core Specific XUnit project file Issue #3197

Issue #3197

amaitland · 2020-07-26T00:20:15Z

Remove hardcoded WindowsTargetPlatformVersion, replace with https://github.com/mjrousos/CppCliMigrationSample/blob/netcore/CppCliInterop/CppCliInterop.vcxproj#L27 as suggested in https://developercommunity.visualstudio.com/solutions/548052/view.html to use the latest installed SDK.

amaitland · 2020-07-26T00:39:49Z

Quickly revisiting the idea of using a symbol Nuget package, seems like that it's not possible for VC++ projects.

They do not currently support Windows PDBs (generated by VC++, or for managed projects that set build property DebugType to full)

As per https://github.com/dotnet/sourcelink#alternative-pdb-distribution

amaitland · 2020-08-05T10:50:58Z

Generate reference assemblies https://docs.microsoft.com/en-us/dotnet/standard/assembly/reference-assemblies

I've spent quite a bit of time on this and can generate source for the csproj based projects it doesn't appear to be possible to install GenApi (as detailed in #2796 (comment)) in a vcxproj file so we'll need to get creative.

It will be simpler to simply use the built in reference assembly generation for the csproj files, the downside being it will generate internal types. I'm thinking of creating a new csproj that reference CefSharp.Core simply for the purpose of manually invoking the GenApi targets.

What I've hacked together so far is at https://github.com/amaitland/CefSharp/tree/genapi (currently using GenApi to generate source for each of the csproj files). Not clear what properties the assemblies should actually have, should they be strongly signed? Need to investigate what .Net generates itself.

amaitland · 2020-08-05T22:53:14Z

If we create a CefSharp.Core.RefAssembly project, reference CefSharp.Core, install GenApi I'm wondering if we can execute GenApi as a prebuild step referencing CefSharp.Core and have the project in turn compile the generated source to produce a ref assembly. I'll try this next.

- Add ChromiumWebBrowser.Partial.cs and include in all three projects - Remove InternalsVisibleTo from Cefsharp.dll start moving code into the partial class (We don't want to publish our internals as part of our Ref Assembly so this goings together) #3082 #3197

- Produce ref assembly for Release builds only #3197

amaitland · 2020-08-12T03:13:09Z

JetBrains have a new tool for generating ref assemblies at https://github.com/JetBrains/Refasmer with an article on their blog at https://blog.jetbrains.com/dotnet/2020/08/05/generate-reference-assemblies-with-refasmer/

There doesn't appear to be a public set of nuget packages yet.

amaitland · 2020-08-12T04:23:50Z

Article on creating ref assemblies see https://claires.site/2018/07/03/create-and-pack-reference-assemblies/ and https://claires.site/2018/07/09/create-and-pack-reference-assemblies-made-easy/

amaitland · 2020-08-12T08:17:15Z

With commits 76c7918 and 159a45b we can now generate a ref assembly for the Net Core version of CefSharp.Core.dll. Still need to make one improvement as x64 is hardcoded in 159a45b#diff-49c51a579f9e8487c404651224bf7612R28

Remove the old win-x64/x86 packages as I'll hopefully get this approach working **Incomplete** Issue #2795 Issue #3197

Build Net Core projects using the VS 2019 build worker image. No custom build script yet, nuget packages are only created for our Net Full build Issue #3197

Issue #3197

dotnet restore doesn't like the vcxproj files, trying msbuild restore instead Issue #3197

dotnet restore and msbuild doesn't like the vcxproj files use nuget restore directly for the two vcxprojs Issue #3197

before_build is interpreting our commands as one, split them Issue #3197

amaitland · 2021-01-06T11:19:03Z

Switching to using System.Text.Json for the DevTools client implementation is taking a little longer than I had hoped, the work in process is at https://github.com/amaitland/CefSharp/tree/netcore/devtoolsjson

I'll hopefully finish this tomorrow/friday and release the first -pre release to Nuget.org

amaitland · 2021-01-08T04:37:00Z

C160 DLL characteristics
High Entropy Virtual Addresses
Dynamic base
NX compatible
Control Flow Guard
Terminal Server Aware

dumpbin /headers CefSharp.BrowserSubprocess.exe confirms that the exe is TSAware.

Issue #3197

amaitland · 2021-01-08T10:15:37Z

CEF has upgraded to Chromium 87.0.4280.141 (https://bitbucket.org/chromiumembedded/cef/commits/481a82af37bd1b0330abe60040bcf261374023e6)

A new build is available on https://cef-builds.spotifycdn.com/index.html so I'll upgrade before pushing out the first -pre release tomorrow.

amaitland · 2021-01-09T10:15:19Z

The first -pre set of NETCore/Net 5 packages are now on Nuget.org

The minimum required Nuget Client version is 5.0.0, the packages currently specify a minimum of 4.0.0, which is incorrect, I'll fix that shortly and will be included in the next release.

(Nobody had a better name, so sticking with NETCore for now, will likely move the current packages over to a Net452 naming suffix and change the older packages to be simple meta packages, select the correct implementation based on target framework).

kpreisser · 2021-01-11T09:46:41Z

Thanks a lot for your work on this! I'm using CefSharp.WinForms.NETCore 87.1.130-pre (with a self-hosted browser subprocess) in a .NET 5.0 application and it works without problems so far (as long as I specify a RuntimeIdentifier).

Without a runtime identifier, the main application itself starts successfully (it correctly loads libcef.dll from the runtimes/win-x64/native folder); however, the selfhost subprocess fails as it tries to load CefSharp.BrowserSubprocess.Core.dll from the runtimes/win-x64/lib/netcoreapp3.1 folder (but the file is placed in the native folder):

System.IO.FileNotFoundException: Could not load file or assembly 'C:\pro\CoDaBix\Sources\CoDaBix.Host.Wpf\Package\CoDaBix.Host.Wpf\Binary\x64\Debug\net5.0\runtimes\win-x64\lib\netcoreapp3.1\CefSharp.BrowserSubprocess.Core.dll'. The system cannot find the file specified.
File name: 'C:\pro\CoDaBix\Sources\CoDaBix.Host.Wpf\Package\CoDaBix.Host.Wpf\Binary\x64\Debug\net5.0\runtimes\win-x64\lib\netcoreapp3.1\CefSharp.BrowserSubprocess.Core.dll'
   at System.Runtime.Loader.AssemblyLoadContext.LoadFromPath(IntPtr ptrNativeAssemblyLoadContext, String ilPath, String niPath, ObjectHandleOnStack retAssembly)
   at System.Runtime.Loader.AssemblyLoadContext.LoadFromAssemblyPath(String assemblyPath)
   at CefSharp.BrowserSubprocess.SelfHost.Main(String[] args)
   at Codabix.Host.Wpf.EntryPoint.Main(String[] args)

However, this isn't a problem for us as we are OK with setting the RuntimeIdentifier.
Thanks!

amaitland · 2021-01-11T10:11:13Z

Without a runtime identifier, the main application itself starts successfully (it correctly loads libcef.dll from the runtimes/win-x64/native folder); however, the selfhost subprocess fails as it tries to load CefSharp.BrowserSubprocess.Core.dll from the runtimes/win-x64/lib/netcoreapp3.1 folder (but the file is placed in the native folder):

Thanks, great feedback. For the Net Core implementation we can add an extra property for the Core.Dll path into https://github.com/cefsharp/CefSharp/blob/master/CefSharp.Core/Initializer.cs#L51

I've added that to the TODO list above.

- Add Initializer.BrowserSubProcessCorePath which is calculated the same as BrowserSubProcessPath - Update SelfHost to use new path then fallback to old path. Details in #3197 (comment)

kpreisser · 2021-01-12T10:02:19Z

Note that placing PDB files in the native folder seems to cause the .NET SDK to add them to the .deps.json file of the application, which means the application will fail to start when they are missing. Package CefSharp.Common.NETCore 87.1.130-pre now contains the CefSharp.BrowserSubprocess.Core.dll and .pdb files in the runtimes/win-xyz/native folder, whereas in version 87.1.11-ci3823 they were placed in the runtimes/win-xyz/lib/netcoreapp3.1 folder.

For example, the generated .deps.json will look like this:

"CefSharp.Common.NETCore/87.1.130-pre": {
        "dependencies": {
          "chromiumembeddedframework.runtime": "87.1.13"
        },
        "runtime": {
          "runtimes/win-x64/lib/netcoreapp3.1/CefSharp.Core.Runtime.dll": {
            "assemblyVersion": "87.1.130.0",
            "fileVersion": "87.1.130.0"
          },
          "runtimes/win-x64/lib/netcoreapp3.1/CefSharp.Core.dll": {
            "assemblyVersion": "87.1.130.0",
            "fileVersion": "87.1.130.0"
          },
          "runtimes/win-x64/lib/netcoreapp3.1/CefSharp.dll": {
            "assemblyVersion": "87.1.130.0",
            "fileVersion": "87.1.130.0"
          },
          "runtimes/win-x64/lib/netcoreapp3.1/Ijwhost.dll": {
            "fileVersion": "3.100.1020.51903"
          }
        },
        "native": {
          "runtimes/win-x64/native/CefSharp.BrowserSubprocess.Core.dll": {
            "assemblyVersion": "87.1.130.0",
            "fileVersion": "87.1.130.0"
          },
          "runtimes/win-x64/native/CefSharp.BrowserSubprocess.Core.pdb": {
            "fileVersion": "0.0.0.0"
          },
          "runtimes/win-x64/native/CefSharp.BrowserSubprocess.dll": {
            "assemblyVersion": "87.1.130.0",
            "fileVersion": "87.1.130.0"
          },
          "runtimes/win-x64/native/CefSharp.BrowserSubprocess.exe": {
            "fileVersion": "87.1.130.0"
          },
          "runtimes/win-x64/native/CefSharp.BrowserSubprocess.runtimeconfig.json": {
            "fileVersion": "0.0.0.0"
          }
        }
      },

Notice the entry with "runtimes/win-x64/native/CefSharp.BrowserSubprocess.Core.pdb".
This means when you delete all .pdb files after publishing the application (when you don't want to keep them for debugging, as e.g. CefSharp.BrowserSubprocess.Core.pdb is about 6 MB in size), the app will fail to start with an error like this:

Description: A .NET application failed.
Application: app.exe
Path: C:\Program Files\app.exe
Message: Error:
  An assembly specified in the application dependencies manifest (app.deps.json) was not found:
    package: 'CefSharp.Common.NETCore', version: '87.1.130-pre'
    path: 'runtimes/win-x64/native/CefSharp.BrowserSubprocess.Core.pdb'

I think the issue is similar to this one in Microsoft.Data.SqlClient: dotnet/SqlClient#644 (comment)

This doesn't seem to happen when the .dll and .pdb files (CefSharp.BrowserSubprocess) are placed in the runtimes/win-xyz/lib/netcoreapp3.1 folder, where then the .pdb files aren't added to the .deps.json file.

Is it possible to not include the CefSharp.BrowserSubprocess.Core.pdb file in the package, or to move these files into the runtimes/win-xyz/lib/netcoreapp3.1 folder?
Thanks!

amaitland · 2021-01-13T01:22:37Z

Firstly pdb support is rather badly broken, it's been 3 1/2 years and nobody has fixed it see dotnet/sdk#1458 for background

The managed dlls have the pdb embedded into the dll. From a support point of view having a pdb included by default is a huge plus. Trying to get people to provide an actual stack trace is hard enough as it is.

Publishing a snupkg to Nuget.org is something I still need to look into.

Package CefSharp.Common.NETCore 87.1.130-pre now contains the CefSharp.BrowserSubprocess.Core.dll and .pdb files in the runtimes/win-xyz/native folder, whereas in version 87.1.11-ci3823 they were placed in the runtimes/win-xyz/lib/netcoreapp3.1 folder.

When no RuntimIdentifier is specified then the folder structure is fragmented, the CefSharp.BrowserSubprocess ends up in a different folder to libcef.dll
The CefSharp.BrowserSubprocess.runtimeconfig.json file isn't copied

Is it possible to not include the CefSharp.BrowserSubprocess.Core.pdb file in the package

For this release that might be the simplest option. Moving the files back into the lib folder requires extra entries in the targets to copy the .runtimeconfig.json file and code changes to CefSharp.BrowserSubprocess.exe so it can locate libcef.dll when it's not in the same folder.

Short term workaround for #3197 (comment)

…lder Leave the pdb in the lib folder for now, won't be copied, it will be in the package if required #3197 (comment)

kpreisser · 2021-01-13T09:33:46Z

Understood, thank you!

Short term workaround for #3197 (comment)

…lder Leave the pdb in the lib folder for now, won't be copied, it will be in the package if required #3197 (comment)

amaitland · 2021-01-13T09:39:35Z

Without a runtime identifier, the main application itself starts successfully (it correctly loads libcef.dll from the runtimes/win-x64/native folder); however, the selfhost subprocess fails as it tries to load CefSharp.BrowserSubprocess.Core.dll from the runtimes/win-x64/lib/netcoreapp3.1 folder (but the file is placed in the native folder):

This should hopefully be fixed in b5118b5

For this release that might be the simplest option. Moving the files back into the lib folder requires extra entries in the targets to copy the .runtimeconfig.json file and code changes to CefSharp.BrowserSubprocess.exe so it can locate libcef.dll when it's not in the same folder.

I've decided to just move the CefSharp.BrowserSubprocess.Core.pdb back into the lib folder. It won't be included as part of the build, it will be available in the package if required for debugging purposes. If I exclude it then there's the hassle of hosting it somewhere.

I'll release another -pre version to Nuget.org in a few days.

amaitland · 2021-01-15T06:28:53Z

The 87.1.131-pre packages are now on Nuget.org ready for additional testing.

PaulParau · 2021-01-27T18:10:51Z

Hi @amaitland

Thanks for putting in the effort to migrate CefSharp to .Net Core/.Net 5! I have some questions related to this:

do you have any timeline as to when a stable version will be available?
currently I see that you're targeting .Net Core 3.1, do you plan to upgrade to .Net 5 at some point?

Thanks

amaitland · 2021-01-27T19:14:01Z

do you have any timeline as to when a stable version will be available?

@PaulParau Likely in the next few days. Subscribe to release only notifications here on GitHub to be notified.

currently I see that you're targeting .Net Core 3.1, do you plan to upgrade to .Net 5 at some point?

See #3284

Also there are problems compiling the VC++ projects with .Net 5.0, so technically I cannot create a successful build.

As .Net 5.0 is backwards compatible with .Net Core 3.1 is there a specific reason you require an upgraded version?

PaulParau · 2021-01-28T17:51:35Z

@PaulParau Likely in the next few days. Subscribe to release only notifications here on GitHub to be notified.

Awesome, thanks!

As .Net 5.0 is backwards compatible with .Net Core 3.1 is there a specific reason you require an upgraded version?

I wasn't sure whether the .Net Core 3.1 version would be usable within a .Net 5 app, but it seems that they are compatible. So no specific reason to upgrade to 5 at this time.

amaitland · 2021-02-03T05:11:20Z

Further enhancements will be made as part of #3388

amaitland added the enhancement label Jul 23, 2020

amaitland self-assigned this Jul 23, 2020

amaitland mentioned this issue Jul 23, 2020

Add new projects targeting .NET Core 3.1 #3181

Merged

9 tasks

campersau mentioned this issue Jul 23, 2020

AppVeyor matrix build #3200

Closed

9 tasks

amaitland added a commit that referenced this issue Jul 24, 2020

Net Core - Split Binding Test into Sync/Async

22d494b

- In preparation for adding a Net Core Specific XUnit project file Issue #3197

amaitland added a commit that referenced this issue Jul 24, 2020

Net Core - Add XUnit Test Project

1af1065

Issue #3197

amaitland added a commit that referenced this issue Aug 7, 2020

Net Core - Produce reference assemblies for c# projects

e1ca2f0

- Produce ref assembly for Release builds only #3197

amaitland added a commit that referenced this issue Aug 14, 2020

Net Core - Add Net Core Specific packages

2f02c8e

Remove the old win-x64/x86 packages as I'll hopefully get this approach working **Incomplete** Issue #2795 Issue #3197

amaitland added a commit that referenced this issue Aug 14, 2020

Net Core - AppVeyor Matrix Build First Attempt

1ec3804

Build Net Core projects using the VS 2019 build worker image. No custom build script yet, nuget packages are only created for our Net Full build Issue #3197

amaitland added a commit that referenced this issue Aug 14, 2020

Net Core - AppVeyor Matrix Take 2

36b20a3

Issue #3197

amaitland added a commit that referenced this issue Aug 14, 2020

Net Core - AppVeyor matrix take 3

28b8f6d

Issue #3197

amaitland added a commit that referenced this issue Aug 14, 2020

Net Core - AppVeyor matrix take 4

b6a0e27

Issue #3197

amaitland added a commit that referenced this issue Aug 14, 2020

Net Core - AppVeyor matrix tabs to spaces

b036a3e

Issue #3197

amaitland added a commit that referenced this issue Aug 14, 2020

Net Core - AppVeyor matrix remove dash

33a4a44

Issue #3197

amaitland added a commit that referenced this issue Aug 14, 2020

Net Core - AppVeyor matrix remove dash

90ec510

Issue #3197

amaitland added a commit that referenced this issue Aug 14, 2020

Net Core - AppVeyor dotnet restore before build

be86a5b

Issue #3197

amaitland added a commit that referenced this issue Aug 14, 2020

Net Core - AppVeyor msbuild restore

5e69d57

dotnet restore doesn't like the vcxproj files, trying msbuild restore instead Issue #3197

amaitland added a commit that referenced this issue Aug 14, 2020

Net Core - AppVeyor nuget restore

54b60a5

dotnet restore and msbuild doesn't like the vcxproj files use nuget restore directly for the two vcxprojs Issue #3197

amaitland added a commit that referenced this issue Aug 14, 2020

Net Core - AppVeyor before_build

6045c68

before_build is interpreting our commands as one, split them Issue #3197

amaitland added a commit that referenced this issue Jan 8, 2021

Net Core - OffScreen Add System.Drawing.Common dependency

2406a45

Issue #3197

amaitland added a commit that referenced this issue Jan 13, 2021

Net Core - Don't include CefSharp.BrowserSubprocess.Core.pdb in Nupkg

980b6b0

Short term workaround for #3197 (comment)

amaitland added a commit that referenced this issue Jan 13, 2021

Net Core - Nupkg move CefSharp.BrowserSubprocess.Core.pdb into lib fo…

08f76eb

…lder Leave the pdb in the lib folder for now, won't be copied, it will be in the package if required #3197 (comment)

amaitland added a commit that referenced this issue Jan 13, 2021

Net Core - Don't include CefSharp.BrowserSubprocess.Core.pdb in Nupkg

c43d9e5

Short term workaround for #3197 (comment)

amaitland added a commit that referenced this issue Jan 13, 2021

Net Core - Nupkg move CefSharp.BrowserSubprocess.Core.pdb into lib fo…

3c253b9

…lder Leave the pdb in the lib folder for now, won't be copied, it will be in the package if required #3197 (comment)

amaitland mentioned this issue Jan 15, 2021

Release Notification - 87.1.x #3343

Closed

14 tasks

amaitland modified the milestones: 87.1.x, 88.1.x Jan 29, 2021

amaitland mentioned this issue Feb 3, 2021

Net Core/Net 5 - Enhancements #3388

Closed

5 tasks

amaitland modified the milestones: 88.1.x, 87.1.x Feb 3, 2021

amaitland closed this as completed Feb 3, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Net Core/Net 5 - Implementation #3197

Net Core/Net 5 - Implementation #3197

amaitland commented Jul 23, 2020 •

edited

Loading

campersau commented Jul 23, 2020 •

edited by amaitland

Loading

amaitland commented Jul 24, 2020

amaitland commented Jul 26, 2020 •

edited

Loading

amaitland commented Jul 26, 2020

amaitland commented Aug 5, 2020

amaitland commented Aug 5, 2020

amaitland commented Aug 12, 2020

amaitland commented Aug 12, 2020

amaitland commented Aug 12, 2020

amaitland commented Jan 6, 2021

amaitland commented Jan 8, 2021

amaitland commented Jan 8, 2021

amaitland commented Jan 9, 2021 •

edited

Loading

kpreisser commented Jan 11, 2021

amaitland commented Jan 11, 2021

kpreisser commented Jan 12, 2021 •

edited

Loading

amaitland commented Jan 13, 2021

kpreisser commented Jan 13, 2021

amaitland commented Jan 13, 2021

amaitland commented Jan 15, 2021

PaulParau commented Jan 27, 2021

amaitland commented Jan 27, 2021

PaulParau commented Jan 28, 2021

amaitland commented Feb 3, 2021

Net Core/Net 5 - Implementation #3197

Net Core/Net 5 - Implementation #3197

Comments

amaitland commented Jul 23, 2020 • edited Loading

campersau commented Jul 23, 2020 • edited by amaitland Loading

amaitland commented Jul 24, 2020

amaitland commented Jul 26, 2020 • edited Loading

amaitland commented Jul 26, 2020

amaitland commented Aug 5, 2020

amaitland commented Aug 5, 2020

amaitland commented Aug 12, 2020

amaitland commented Aug 12, 2020

amaitland commented Aug 12, 2020

amaitland commented Jan 6, 2021

amaitland commented Jan 8, 2021

amaitland commented Jan 8, 2021

amaitland commented Jan 9, 2021 • edited Loading

kpreisser commented Jan 11, 2021

amaitland commented Jan 11, 2021

kpreisser commented Jan 12, 2021 • edited Loading

amaitland commented Jan 13, 2021

kpreisser commented Jan 13, 2021

amaitland commented Jan 13, 2021

amaitland commented Jan 15, 2021

PaulParau commented Jan 27, 2021

amaitland commented Jan 27, 2021

PaulParau commented Jan 28, 2021

amaitland commented Feb 3, 2021

amaitland commented Jul 23, 2020 •

edited

Loading

campersau commented Jul 23, 2020 •

edited by amaitland

Loading

amaitland commented Jul 26, 2020 •

edited

Loading

amaitland commented Jan 9, 2021 •

edited

Loading

kpreisser commented Jan 12, 2021 •

edited

Loading