Adds Post-Processing feature. Related issue #144#148

3F · 2020-04-28T13:17:05Z

Closes #144
Continues direction of PR #146

Explanation and details:

This also updates MvsSln (core of this PR) to 2.5.2 since current PR was based on features that were updated in 2.5.2:

https://github.com/3F/MvsSln/releases/tag/2.5.2

Part of #144

…ironment: Format: $(SolutionPath);$(MSBuildThisFileFullPath);...populated property names...;.... ``` <Target Name="DllExportPostProc">  </Target> ```

3F · 2020-04-30T21:12:11Z

I implemented backend logic with configurable environment. ANY properties can be populated like for parent projects (depend on) and/or current dependencies where processed.

Currently no GUI but it's planned. Later.

How to play with this today:

We need to define DllExportProcEnv property:

Format: $(SolutionPath);$(MSBuildThisFileFullPath);...populated property names...;....

For example:

<PropertyGroup>
  <DllExportProcEnv>
    $(SolutionPath);$(MSBuildThisFileFullPath);
    TargetDir;
    AssemblyName;
    TargetPath;
    ...
  </DllExportProcEnv>
</PropertyGroup>

We need callable target, named as DllExportPostProc:

<Target Name="DllExportPostProc">

    <!-- Now we can access the following properties and items:
    
    $(DllExport)     - version
    $(DllExportSln)  - full path to .sln which controls current project
    $(DllExportPrj)  - full path to current project where processed .NET DllExport
    
    @(DllExportDirX64)    - $(TargetDir)x64\*.*
    @(DllExportDirX86)    - $(TargetDir)x86\*.*
    @(DllExportDirBefore) - $(TargetDir)Before\*.*
    @(DllExportDirAfter)  - $(TargetDir)After\*.*
    
    @(DllExportDependents + populated property name) 
       - each populated properties from DllExportProcEnv, 
          e.g. DllExportDependentsTargetDir
       
    @(DllExportDependencies + populated property name) 
      - each populated properties from DllExportProcEnv, 
          e.g. DllExportDependenciesTargetDir

    @(DllExportSeqDependents + populated property name) 
       - each populated properties from DllExportProcEnv, 
          e.g. DllExportSeqDependentsTargetDir
      
    -->

</Target>

Enjoy.

@NickAcPT

Can you confirm this solution for your case? For example, for the case with #144 we need like this:

<Target Name="DllExportPostProc">

  <Copy SourceFiles="@(DllExportDirX64)" OverwriteReadOnlyFiles="true"
      DestinationFolder="@(DllExportDependentsTargetDir->'%(Identity)x64\')" />

  <Copy SourceFiles="@(DllExportDirX86)" OverwriteReadOnlyFiles="true"
      DestinationFolder="@(DllExportDependentsTargetDir->'%(Identity)x86\')" />

</Target>

Let me know if any bugs.

update: DllExportInvokedPoint renamed as DllExportProcEnv [?]

update2: new DllExportSeqDependents... items [?]

update3: future updates will be on the new wiki page: https://github.com/3F/DllExport/wiki/PostProc#post-processing

NickAcPT · 2020-04-30T21:50:36Z

@3F Thanks for your work so far.

I've been having some trouble reproducing your results on my side, but it appears to be because I have something misconfigured.

I'm a bit unsure on which project I need to put the DllExportPostProc target into, and what is the best configuration for the DllExportInvokedPoint property.

I'd appreciate for you to explain a bit more on your answer.

Here's my project structure:

ProjectA (.NET Framework project; uses DllExport; x86+x64)
ProjectB (.NET Core 3.1 project; depends on ProjectA)

3F · 2020-04-30T22:04:38Z

@NickAcPT

Any modification should be only where DllExport is installed.

That is, for your case:

DllExportPostProc should be placed only for ProjectA (where DllExport)
After, MvsSln will calculate required data (that was mentioned in Question regarding depending on the DllExported dlls on another project #144) and populate it inside DllExportPostProc target.
Now DllExportPostProc can be used for many cases including yours. Bonus: Both directions.

and what is the best configuration for the DllExportInvokedPoint property.

Minimal for the case when @(DllExportDependentsTargetDir->'%(Identity)x64\') is $(SolutionPath);$(MSBuildThisFileFullPath);TargetDir

+Checking the existence of our entry point

That is, *! Some Post-Proc features are not yet available in GUI. But you can already configure it with msbuild.

3F · 2020-05-02T19:27:31Z

Please note: DllExportInvokedPoint renamed as DllExportProcEnv. I also updated my example above

3F · 2020-05-02T19:42:44Z

@NickAcPT I added basic GUI support for predefined options, please check this out. It covers at least your case.

That is, today some Post-Proc features are not yet available in GUI. Only manual configuring with msbuild as I said before.

Since this PR is mainly for adding an Post-processing support, full GUI will be considered through a new one, and seems like not for 1.7.1. Of course anybody can open PR to get this ASAP. Welcome.

NickAcPT · 2020-05-03T00:29:11Z

@3F Sorry for the huge delay. Haven't had much time to mess with this for a while.

Thanks a lot for the work you've done. I've ran across a problem when using Fody.Costura (haven't tried yet with your ILMerge post processing step).

Exception

DllExportMod:
  Found method: WinTabby.Hooks.ManagedHook..method public hidebysig static native int 'CaptionPaintBlockHandler'(int32 'nCode', native int 'wParam', native int 'lParam') cil managed
  	exporting as CaptionPaintBlockHandler and index 1
D:\Visual Studio - Projects\WinTabby\packages\DllExport.1.7.0\tools\net.r_eg.DllExport.targets(76,5): error : The given key was not present in the dictionary. [D:\Visual Studio - Projects\WinTabby\WinTabby.Hooks\WinTabby.Hooks.csproj]
     at System.Collections.Generic.Dictionary`2.get_Item(TKey key)
     at net.r_eg.MvsSln.Core.ProjectReferences.<>c__DisplayClass15_0.<InitMap>b__0(Item i) in C:\projects\dllexport-ix27o\MvsSln\MvsSln\Core\ProjectReferences.cs:line 114
     at System.Collections.Generic.List`1.ForEach(Action`1 action)
     at net.r_eg.MvsSln.Core.ProjectReferences.InitMap() in C:\projects\dllexport-ix27o\MvsSln\MvsSln\Core\ProjectReferences.cs:line 114
     at net.r_eg.MvsSln.Core.ProjectReferences..ctor(ISlnPDManager slndep, IEnumerable`1 xprojects) in C:\projects\dllexport-ix27o\MvsSln\MvsSln\Core\ProjectReferences.cs:line 90
     at net.r_eg.MvsSln.Core.SlnParser.Parse(StreamReader reader, SlnItems type) in C:\projects\dllexport-ix27o\MvsSln\MvsSln\Core\SlnParser.cs:line 159
     at net.r_eg.MvsSln.Core.SlnParser.Parse(String sln, SlnItems type) in C:\projects\dllexport-ix27o\MvsSln\MvsSln\Core\SlnParser.cs:line 106
     at net.r_eg.MvsSln.Sln..ctor(String file, SlnItems type) in C:\projects\dllexport-ix27o\MvsSln\MvsSln\Sln.cs:line 55
     at RGiesecke.DllExport.MSBuild.PostProc..ctor(String raw, TaskLoggingHelper log) in C:\projects\dllexport-ix27o\RGiesecke.DllExport.MSBuild\PostProc.cs:line 82
     at RGiesecke.DllExport.MSBuild.ExportTaskImplementation`1.ExecutePostProc(Boolean ret, TaskLoggingHelper log) in C:\projects\dllexport-ix27o\RGiesecke.DllExport.MSBuild\RGiesecke.DllExport.MSBuild\ExportTaskImplementation.cs:line 508
     at RGiesecke.DllExport.MSBuild.ExportTaskImplementation`1.Execute() in C:\projects\dllexport-ix27o\RGiesecke.DllExport.MSBuild\RGiesecke.DllExport.MSBuild\ExportTaskImplementation.cs:line 482

I'll update this comment if I find anything else.

3F · 2020-05-03T10:05:05Z

@NickAcPT Thank you for the important information!

What build or commit have you tried? Is this a new error after #148 (comment) ?

Can you please use /v:diag to show more details after DllExportMod: Found method: lines?
Or better, can you attach WinTabby.Hooks.csproj file?

3F · 2020-05-03T10:12:06Z

Actually I'm watching ProjectReferences problem in your stack trace, ie. more like MvsSln part. I need some details from your .csproj related to ProjectReferences for reproducing on my laptop.

Or it could be a problem with new flags in MvsSln: SlnItems.ProjectDependenciesXml | SlnItems.LoadMinimalDefaultData

Because I tested only this:

https://github.com/3F/MvsSln/blob/9c3949825db5bc2a8863ab103d87c4a181a1a514/MvsSlnTest/Core/ProjectReferencesTest.cs
- https://github.com/3F/MvsSln/tree/9c3949825db5bc2a8863ab103d87c4a181a1a514/MvsSlnTest/resources/ProjectDependenciesXml

+PostProc +PreProc

NickAcPT · 2020-05-03T11:13:24Z

@3F

I need some details from your .csproj related to ProjectReferences for reproducing on my laptop.

Sure, which details do you need?

3F · 2020-05-03T11:35:57Z

@NickAcPT

I need the following:

Full definitions of the all ProjectReference from WinTabby.Hooks.csproj, such as:

    <ProjectReference Include="ClassLibrary2.csproj">
      <Project>{64ad76ca-2c85-4039-b0b3-734cf02b2999}</Project>
      <Name>ClassLibrary2</Name>
    </ProjectReference>

I need definitions of the all ProjectGuid properties (if used) from in WinTabby.Hooks.csproj, such as:

<ProjectGuid>{6CE57BB1-4A6D-4714-B775-74A3637EC992}</ProjectGuid>

I need Project sections from your .sln, such as:

Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "ClassLibrary2", "ClassLibrary2.csproj", "{64AD76CA-2C85-4039-B0B3-734CF02B2999}"
EndProject

Also ProjectSection(ProjectDependencies) from .sln (if used) should be inside Project sections above.

Thanks,

…nces Related: 3F/DllExport#148 (comment) +Updated tests

3F · 2020-05-03T16:23:02Z

@NickAcPT I found and fixed two related errors in MvsSln project. Please try with 1bd7675

NickAcPT · 2020-05-03T21:23:25Z

@NickAcPT I found and fixed two related errors in MvsSln project. Please try with 1bd7675

I've tried it and came across this error.
Here is the project file along with the solution file.

3F · 2020-05-03T21:43:49Z

Thanks for the reply,

Just to be sure, can you show result for the command DllExport -build-info
About ProjectReference my bad, I meant the dependent project. More like WinTabby.DaemonWPF\WinTabby.Daemon.csproj. Can you attach this? or at least its ProjectReference record.

NickAcPT · 2020-05-03T22:02:09Z

Just to be sure, can you show result for the command DllExport -build-info
There we go:

    S_NUM_REV:          1.7.0.1056
    S_REL:
    bSha1:              a2a0c69
    bName:              master
    MetaCor:            netstandard1.1
    MetaLib:            v2.0
    Wizard:             v4.0
    Configuration:      PublicRelease
    Platform:           Any CPU
    cfgname:            Release
    revDeltaBase:       2016/10/12
    revDeltaMin:        1000
    revDeltaMax:        65534

    :: generated by a vsSolutionBuildEvent 1.14.0.36854

2. About ProjectReference my bad, I meant the dependent project. More like WinTabby.DaemonWPF\WinTabby.Daemon.csproj. Can you attach this? or at least its ProjectReference record.

Oh, no problem 😄
Here are the files:
WinTabby.Events.csproj depends on WinTabby.Hooks.
And then WinTabby.Daemon.csproj depends on WinTabby.Events.

3F · 2020-05-03T22:55:43Z

@NickAcPT Thank you for the detailed information. Yep, I didn't think first about obsolete projectguid in ProjectReference, but yes, MS avoids an obsolete projectguid in any modern places. My bad. And my issue btw: 3F/MvsSln#18

So, this is it, MvsSln expects this format:

<ProjectReference Include="..\WinTabby.Hooks\WinTabby.Hooks.csproj" Project="18816D42-416D-4D2B-83F5-1DF7353184AD" />

But the new is:

<ProjectReference Include="..\WinTabby.Hooks\WinTabby.Hooks.csproj" />

The error is controlled by 3F/MvsSln#26

…solete projectguid

3F · 2020-05-04T21:27:14Z

Added ProjectReference support without obsolete projectguid. Please confirm solution e638674

NickAcPT · 2020-05-05T02:00:38Z

Can confirm it builds now! Thanks a lot for all the work!

NickAcPT · 2020-05-05T02:07:18Z

I've noticed a problem that doesn't go away after cleaning and rebuilding when the solution is structured as this:

ProjectA (WinTabby.Hooks; .NET Framework 4.8; uses DllExport)
ProjectB (WinTabby.Events; .NET Core 3.1; references ProjectA)
ProjectC (WinTabby.Daemon; .NET Core 3.1; references ProjectA and ProjectB)

My end-goal with ProjectC referencing ProjectA is to have it so it also would copy the x64/x86 folders to the output of the ProjectC.

Edit: forgot to attach the build error.
out.txt

NickAcPT · 2020-05-05T02:26:41Z

I'm not sure if it is related to the PR, but on the Pre-processing tab there is a task to run ILMerge, even on .NET Core/Standard projects, but it only works on .NET Framework projects.
Would it be possible to make something that can work everywhere (without the need of changing the code of ILMerge)?

I've read here that there's a way to make .NET Core executables/dlls into one single file with some changes, but it requires publishing the project (dotnet publish).

3F · 2020-05-05T12:19:26Z

Well, I forgot about recursion for multiple destination in msbuild task :)

That is, instead of @(DllExportDependentsTargetDir->'%(Identity)x86\') we need to use, for example, like Outputs splitting etc.

Since DllExportPostProc is a common case for Post-processing feature and Outputs should not interfere with it, for the case like yours and so on, we'll use additional target like:

<Target AfterTargets="DllExportPostProc" Name="DllExportPostProcForDependent"
      Outputs="%(DllExportDependentsTargetDir.Identity)">

<Copy SourceFiles="@(DllExportDirX64)" OverwriteReadOnlyFiles="true"
        DestinationFolder="%(DllExportDependentsTargetDir.Identity)\x64\" />
        
        ...
</Target>

As you can see, any other custom targets can easily extend our DllExportPostProc

So, I'll update logic ASAP. You can also try it yourself to make sure before I start.

3F · 2020-05-05T12:20:58Z

I'm not sure if it is related to the PR, but on the Pre-processing tab there is a task to run ILMerge, even on .NET Core/Standard projects, but it only works on .NET Framework projects.

As I remember, I tested both types including .NET Core based projects. Or please clarify the case. Better to open a new issue if you found error related to the other planned Pre-processing feature.

* NEW: Activating ProjectReferences for existing ProjectDependencies (shallow copy) through new flag. Issue #25. ``` ProjectDependenciesXml = 0x0800 | ProjectDependencies | Env, ``` Covers ProjectDependencies (SLN) logic using data from project files (XML). Helps eliminate miscellaneous units between VS and msbuild world: #25 (comment) Requires Env with loaded projects (LoadMinimalDefaultData or LoadDefaultData). A core feature in .NET DllExport Post-processing: 3F/DllExport#148 * NEW: `ProjectReference` support without obsolete projectguid. Issue #26. * NEW: IXProject methods: ``` +IXProject.GetFullPath(string relative) ``` * FIXED: Fixed possible empty records in SlnParser.SetProjectItemsConfigs. * FIXED: Fixed `The given key was not present...` when different case for keys in Item.Metadata. * FIXED: Fixed protected XProject GetProjectGuid() + GetProjectName() when empty property. * CHANGED: Compatible signature update for `ForEach<T>` extension method: ``` IEnumerable<T> ForEach<T>(this IEnumerable<T> items, Action<T> act) ``` * CHANGED: Updated Microsoft.CSharp 4.7.0 (Only for: netstandard2.0 + netcoreapp2.1) * CHANGED: Updated Microsoft.Build 16.5.0 (Only for: netcoreapp2.1)

#148 (comment)

3F · 2020-05-06T12:21:26Z

I updated logic for generating derivative targets as I mentioned above.

@NickAcPT Try this 0b09916

NickAcPT · 2020-05-06T17:03:59Z

I tried it.

ProjectA (WinTabby.Hooks; .NET Framework 4.8; uses DllExport)

ProjectB (WinTabby.Events; .NET Core 3.1; references ProjectA)

ProjectC (WinTabby.Daemon; .NET Core 3.1; references ProjectA and ProjectB)

Was I supposed to see any changes on ProjectC? Don't think it created a task there.

Even if not. Tried it and on ProjectA, I see these two targets:

<Target Name="DllExportPostProc" Label="8337224c9ad9e356" />
<Target Name="DllExportPostProcForTargetDir" AfterTargets="DllExportPostProc" Label="8337224c9ad9e356" Outputs="%(DllExportDependentsTargetDir.Identity)">
<Copy SourceFiles="@(DllExportDirX86)" DestinationFolder="%(DllExportDependentsTargetDir.Identity)x86\" OverwriteReadOnlyFiles="true" />
<Copy SourceFiles="@(DllExportDirX64)" DestinationFolder="%(DllExportDependentsTargetDir.Identity)x64\" OverwriteReadOnlyFiles="true" />
</Target>

3F · 2020-05-06T17:18:29Z

Tried it and on ProjectA, I see these two targets:

It looks correct.

Any data should be configured only in ProjectA!

While ProjectB + ProjectC will magically receive x86+x64 folders from ProjectA.
Please attach /v:d log. For me it works well.

NickAcPT · 2020-05-06T17:31:09Z

There you go.
out.txt

3F · 2020-05-06T19:01:42Z

I get it, we're talking about different cases when you're talking about ProjectC ... references ProjectA and ProjectB

Because:

ProjectC -> ProjectA + ProjectB
ProjectB -> ProjectA

Is not the same to:

ProjectC -> ProjectB -> ProjectA

That's more complex way because it also can be as:

... ProjectE -> ProjectD -> ProjectC -> ProjectB -> ProjectA

And I have a lot of questions if this type. For example,

Do we need to copy to all places? ProjectE + ProjectD + ProjectC + ProjectB
What if only ProjectE + ProjectB ? or more specific, if for ProjectD we don't need to copy this due to custom environment, but for ProjectB we expect this?

Well, don't know...

…other projects

3F · 2020-05-07T11:20:02Z

Okay, I also added DllExportSeqDependents... items:

    @(DllExportSeqDependents + populated property name) 
       - each populated properties from DllExportProcEnv, 
          e.g. DllExportSeqDependentsTargetDir

This includes sequential referencing through other projects. For GUI find [ ] ++ button (0x10 bit in DllExportPostProcType)

See fc5344f

However, for other specific controls and options you need to open new PR. I will not personally consider this at least here.

NickAcPT · 2020-05-07T12:52:01Z

Can confirm that it works.
Thank you so much for all the work you've done. 👍

3F · 2020-05-07T15:47:30Z

Good! Thanks for the confirmation.

* NEW: Pre-Processing feature. PR #146. Related issue #40 Official ILMerge support; https://github.com/dotnet/ILMerge Quick integration with Conari for most easy access to unmanaged features; https://github.com/3F/Conari +Other related tools and assembly manipulations. Manual configuring: #40 (comment) * NEW: Post-Processing. PR #148. Continues direction of Pre-Processing feature. PR #146 Related issue #144 Explanation and details: https://ko-fi.com/Blog/Post/ILMerge---Conari---Debug-information---DllExport-=-O5O61MV8A 1.7.1 Provides only basic GUI support for predefined options. Thus, *! Some Post-Proc features are not yet available in GUI. But you can already configure it with msbuild: ``` <Target Name="DllExportPostProc">  </Target> ``` #148 (comment) * NEW: Optional copying of intermediate files + x86+x64 directories into output for projects that dependent on projects where used DllExport. Issue #144. Including sequential referencing through other projects: #148 (comment) * FIXED: Fixed #140 ... failed to create safe SSL/TLS context. * FIXED: Pack of fixes for .net.dllexport.targets. PR #147. * Fixed "Cannot modify an evaluated object originating in an imported file". * Fixed possible duplication in .net.dllexport.targets when configuring. * Adds removing TargetsFile if not used. * Fixed possible loss of settings in .targets when configuring. * FIXED: Fixed #143 'Microsoft.NET.Sdk' specified could not be found. * FIXED: A multiple empty `<PropertyGroup />` in project files during new configuration. * CHANGED: Wizard. Dropped support for ssl3 + tls1.0 + tls1.1 * CHANGED: Wizard. Simplified notification for stable versions. * CHANGED: Manager. Access to hMSBuild tool (packed) via `-hMSBuild` key. https://github.com/3F/hMSBuild Since it uses packed version (while GetNuTool is integrated inside), you need use -dxp-version to control specific version. * CHANGED: Updated Cecil 0.11.2 https://github.com/jbevain/cecil/releases/tag/0.11.2 * CHANGED: Updated MvsSln 2.5.2 https://github.com/3F/MvsSln/releases/tag/2.5.2

3F added enhancement netcore netfx labels Apr 28, 2020

3F added this to the 1.7.1 milestone Apr 28, 2020

3F marked this pull request as draft April 28, 2020 13:21

MvsSln up to rev 9c39498 due to 3F/MvsSln#25

bdc9a67

Part of #144

3F force-pushed the dev/postproc branch from 7490f86 to bdc9a67 Compare April 30, 2020 20:50

3F marked this pull request as ready for review April 30, 2020 21:12

3F added 5 commits May 2, 2020 21:53

Post-Proc. Added support of external .net.dllexport.targets

40168c6

PostProc usage has been moved into ExportTaskImplementation

7f28173

Fixed MSB4094 when using the same properties

65b6dd2

+Checking the existence of our entry point

DllExportInvokedPoint renamed as DllExportProcEnv

9a0cfc1

Basic GUI support for predefined options in Post-Proc feature

081a7dd

That is, *! Some Post-Proc features are not yet available in GUI. But you can already configure it with msbuild.

3F added 2 commits May 3, 2020 13:33

cleanup

cfa3759

Updated data in SimpleConfFormater.Parse()

5ce92f7

+PostProc +PreProc

3F added a commit to 3F/MvsSln that referenced this pull request May 3, 2020

Fixed The given key was not present... when activated ProjectRefere…

838fab0

…nces Related: 3F/DllExport#148 (comment) +Updated tests

MvsSln up to rev 838fab00dd /? #148 (comment)

1bd7675

3F mentioned this pull request May 3, 2020

ProjectReference records without obsolete projectguid 3F/MvsSln#26

Closed

MvsSln up to rev e07c5806dd: +ProjectReference support without ob…

e638674

…solete projectguid

3F added 2 commits May 6, 2020 15:13

Updated MvsSln 2.5.2

4f400d9

Added multiple destination support via derivative targets:

0b09916

#148 (comment)

+DllExportSeqDependents... Includes sequential referencing through …

fc5344f

…other projects

3F changed the title ~~WIP. Adds Post-Processing feature. Related issue #144~~ Adds Post-Processing feature. Related issue #144 May 7, 2020

3F merged commit 7d54260 into master May 7, 2020

3F deleted the dev/postproc branch May 7, 2020 16:01

3F mentioned this pull request Nov 21, 2023

Getting projects *in build order* from .sln 3F/MvsSln#60

Closed

Uh oh!

Conversation

3F commented Apr 28, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

3F commented Apr 30, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

NickAcPT commented Apr 30, 2020

Uh oh!

3F commented Apr 30, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

3F commented May 2, 2020

Uh oh!

3F commented May 2, 2020

Uh oh!

NickAcPT commented May 3, 2020

Uh oh!

3F commented May 3, 2020

Uh oh!

3F commented May 3, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

NickAcPT commented May 3, 2020

Uh oh!

3F commented May 3, 2020

Uh oh!

3F commented May 3, 2020

Uh oh!

NickAcPT commented May 3, 2020

Uh oh!

3F commented May 3, 2020

Uh oh!

NickAcPT commented May 3, 2020

Uh oh!

3F commented May 3, 2020

Uh oh!

3F commented May 4, 2020

Uh oh!

NickAcPT commented May 5, 2020

Uh oh!

NickAcPT commented May 5, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

NickAcPT commented May 5, 2020

Uh oh!

3F commented May 5, 2020

Uh oh!

3F commented May 5, 2020

Uh oh!

3F commented May 6, 2020

Uh oh!

NickAcPT commented May 6, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

3F commented May 6, 2020

Uh oh!

NickAcPT commented May 6, 2020

Uh oh!

3F commented May 6, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

3F commented May 7, 2020

Uh oh!

NickAcPT commented May 7, 2020

Uh oh!

3F commented May 7, 2020

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

3F commented Apr 28, 2020 •

edited

Loading

3F commented Apr 30, 2020 •

edited

Loading

3F commented Apr 30, 2020 •

edited

Loading

3F commented May 3, 2020 •

edited

Loading

NickAcPT commented May 5, 2020 •

edited

Loading

NickAcPT commented May 6, 2020 •

edited

Loading

3F commented May 6, 2020 •

edited

Loading