Closed houstonhaynes closed 9 months ago
The library builds fine. It's the example apps that are blowing up.
I did have to upgrade to the latest version of Avalonia recently, so that probably broke the sample. I’ll take a look!
if you’re open to it, I’d suggest setting up CI in github. It keeps the build honest and protects against bitrot. Avalonia moves so quickly it’s hard to keep versions straightAm 10/23/23 um 6:48 PM schrieb Jordan Marr @.***>: I did have to upgrade to the latest version of Avalonia recently, so that probably broke the sample. I’ll take a look!
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>
The library builds fine. It's the example apps that are blowing up.
There was a global.json file that was preventing me from even loading. After modifying that, I was able to build and run the AvaloniaExample
project.
Now I'm waiting for dotnet workload restore
to finish so I can try the AvaloniaXPlatExample
project.
if you’re open to it, I’d suggest setting up CI in github. It keeps the build honest and protects against bitrot. Avalonia moves so quickly it’s hard to keep versions straight
I am bad about putting off build automation because I have so many projects. But you're right - it always is nice to have once setup.
I’ve managed a bunch of software efforts and the barrier (mental and organizational) always seems high but it’s a real time saver long term. I’ve found the automation in github pretty good too. They help with crafting config files and it was relatively painless. Might be harder if you’re trying to build simultaneously for 4 platforms. Was also thinking that if there’s a way of hosting the wasm version statically you could put the pipeline build output on web site as a demo. Am 10/23/23 um 7:15 PM schrieb Jordan Marr @.***>:
if you’re open to it, I’d suggest setting up CI in github. It keeps the build honest and protects against bitrot. Avalonia moves so quickly it’s hard to keep versions straight
I am bad about putting off build automation because I have so many projects. But you're right - it always is nice to have once setup.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>
I definitely setup build pipelines for all of my professional projects, but those are all on Azure DevOps. I have avoided .yml files at all costs up to this point in my career.
Now, 15m and 6+ commits into setting up a basic build for this repo and still cannot figure out how to specify the root. lol
I always use FAKE to do my builds because I despise the commit > wait > build > wait > pray > review error log
cycle.
So much better to quickly iterate on your own machine and then the extent of your final pipeline configuration is a one-liner to call your build app/script.
I've actually been wanting to try Fun.Build for a while. Maybe now is the time!
Feel free to help with the build. I've tried for the last 45 minutes to do the most basic yml build script. Maybe I'm just missing where it "helps" with creating the build, because it seems like I'm editing a text file with no intellisense.
On Mon, Oct 23, 2023 at 08:02:24PM -0700, Jordan Marr wrote:
Feel free to help with the build. I've tried for the last 45 minutes to do the most basic yml build script. Maybe I'm just missing where it "helps" with creating the build, because it seems like I'm editing a text file with no intellisense.
Will take a look - interesting - it almost forced me to do my last one, offering a basic template that almost worked out of the box. yml without intellisense is evil. I have to admit I wasn't wild about the gitLAB version but when it worked it was nice. One day they changed the semantics of variable expansion and allowed dollar signs to expand within the values of other dollarsign variables, and unfortunately one of our build passwords had a dollarsign in it and hilarity ensued... I'll take a look
Darren
On Mon, Oct 23, 2023 at 09:34:14PM -0700, daz10000 wrote:
On Mon, Oct 23, 2023 at 08:02:24PM -0700, Jordan Marr wrote:
Feel free to help with the build. I've tried for the last 45 minutes to do the most basic yml build script. Maybe I'm just missing where it "helps" with creating the build, because it seems like I'm editing a text file with no intellisense.
Will take a look - interesting - it almost forced me to do my last one, offering a basic template that almost worked out of the box. yml without intellisense is evil. I have to admit I wasn't wild about the
This was the one I did for another project
I think I just clicked on github actions, made a new action and then let it make a guess based on the type of project.
Got to github actions, new actions. From the getting started panel, pick .Net continuous integration
FWIW, this is what it suggestions on my fork of the repo
name: .NET
on:
push:
branches: [ "main" ]
pull_request:
branches: [ "main" ]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: ***@***.***
- name: Setup .NET
uses: ***@***.***
with:
dotnet-version: 6.0.x
- name: Restore dependencies
run: dotnet restore
- name: Build
run: dotnet build --no-restore
- name: Test
run: dotnet test --no-build --verbosity normal
`
Darren
I sent you a PR. I only needed one small change to get it running
https://github.com/JordanMarr/Elmish.Avalonia/pull/25
Darren
Thank you! It's been a long day of solving problems.
Now that you got that working, I went ahead an setup Fun.Build, just for fun: build.fsx I'll try adding the other sln tomorrow. 😴
First attempt to download workloads failed: error
I always use FAKE to do my builds because I despise the
commit > wait > build > wait > pray > review error log
cycle. So much better to quickly iterate on your own machine and then the extent of your final pipeline configuration is a one-liner to call your build app/script.I've actually been wanting to try Fun.Build for a while. Maybe now is the time!
Right now I'm setting up miniscaffold for my project and then going into the "src" it builds to "new up" an Elmish.Avalonia project by hand. The entire reason I started this was I was expecting to just copy over the XPlat example and then wire it into the build infra.
First attempt to download workloads failed: error
Is there a wrinkle with .NET7 and mobile workloads? In most cases I've retreated to .NET6 but that's just a reflex/abundance of caution.
I tried changing all the projects to net6, but there is still an issue with the workloads. To be fair, I haven't really taken the time to properly vet out the build error messages yet.
As of now, the dotnet.yml
, global.json
and all the xplat fsproj
files specify net 6.
Yet I still spotted some a few "net7" references in the build. Not sure if that has anything to do with it. 🤷♂️
OK - I'm out-of-office for the next handful of hours - the weather is just too good and I've got some things to do that require daylight. 🌞 But I'll circle back to this after I get to a notch point. Thanks for looking into it. @daz10000 @JordanMarr 👍 👍
I got everything updated to the latest Avalonia v11.0.5. XPlat sln now builds. CI build now successfully builds the XPlat sln as well. (Not sure why it took 18m though.)
https://github.com/JordanMarr/Elmish.Avalonia/actions/runs/6635424599/job/18026327450
nice! It probably has to install the workload from scratch and do all the setup each time. That’s wonderful in terms of maintenance. I’mabout to start a couple more projects with the framework so it will get some more exercise. Thanks as alwaysDarrenAm 10/24/23 um 8:58 PM schrieb Jordan Marr @.***>: I got everything updated to the latest Avalonia v11.0.5. XPlat sln now builds. CI build now successfully builds the XPlat sln as well. (Not sure why it took 18m though.) https://github.com/JordanMarr/Elmish.Avalonia/actions/runs/6635424599/job/18026327450
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>
Yeah it definitely has to install the workloads, but it was the build of the xplat sln that takes 11m! I wonder if building in Debug mode would be faster.
I ended up spending some time last night with Jimmy Byrd's miniscafflod to grok its structure.
He just added a feature to be able to dovetail additional projects and wire them up to use the scaffold.
https://github.com/TheAngryByrd/MiniScaffold/pull/283
While I'm still picturing hand-jamming Elmish.Avalonia's XPlat sample with copied files/folder structure, it inspired me to scout out the differences in tooling to see if there's a "paved path" that can be made. That's part of what I'm mucking around with this morning.
So I got the XPlat project to build and run after refreshing my local repo to the latest. But... the Chart view is super-broken. Nothing works other than the init - and the non-Xplat demo just gives a transparent/acrylic window and title bar - nothing else.
Weird - cleaned and rebuilt the library and the XPlat CHart is OK - but the "simple" sample is still just rendering a transparent window.
there was a residual bug for me on the cross platform version that if I click away from the chart and then come back to it, it stops working. The terminate background seems to be permanent. I didn’t have that problem with the desktop only version. I haven’t checked the latest build, but I wanted to debug that at some point.Am 10/25/23 um 4:50 PM schrieb Houston Haynes @.***>: Weird - cleaned and rebuilt the library and the XPlat CHart is OK - but the "simple" sample is still just rendering a transparent window.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>
Looks like building xplat in Debug mode did shave a lot of time off:
Weird - cleaned and rebuilt the library and the XPlat CHart is OK - but the "simple" sample is still just rendering a transparent window.
The regular "AvaloniaExample" project "transparent window" issue should be fixed now. I just had to update to the latest Avalonia version 11.0.5.
there was a residual bug for me on the cross platform version that if I click away from the chart and then come back to it, it stops working. The terminate background seems to be permanent. I didn’t have that problem with the desktop only version.
The issue occurs on the XPlat version because you changed the tab mechanism to use the Avalonia TabControl
which changes the behavior to "singleton" style views.
In the original AvaloniaExample "MainView.axaml", there is a single ContentControl
to display the current tab content.
Clicking a tab (button) changes the ContentVM
, and then the ViewLocator
Build
method dynamically loads the corresponding view based on convention. In effect, this means that every time you change to a new tab, the ViewLocator
constructs a new view. (The views are "transient".)
<DockPanel LastChildFill="true">
<StackPanel Classes="nav" Orientation="Horizontal" DockPanel.Dock="Top" HorizontalAlignment="Stretch">
<Button Classes="tab" Content="Counter" Command="{Binding ShowCounter}" />
<Button Classes="tab" Content="Chart" Command="{Binding ShowChart}" />
<Button Classes="tab" Content="File Picker" Command="{Binding ShowFilePicker}" />
<Button Classes="tab" Content="About" Command="{Binding ShowAbout}" />
</StackPanel>
<ContentControl Content="{Binding ContentVM}" />
</DockPanel>
Example:
ChartView
and click the Auto Update button to start the chartterminateOnViewUnloaded
is triggered and the subscription stops (as it should)ChartView
, and the ViewLocator
re-initializes the ChartView
again.In your XPlat example, you used the TabControl
. The difference here is that the tabs are hidden, but the view is still preserved.
This means that the view is not going to be reconstructed by the ViewLocator
when you go back to that tab.
However, since you still have |> ElmishViewModel.terminateOnViewUnloaded Terminate
, the VM is terminated (but never reinitialized). (ElmishViewModel.terminateOnViewUnloaded
calls AvaloniaProgram.withTermination
to terminate the Elmish loop for your VM).
So, if you want to use the TabControl
, you can't call ElmishViewModel.terminateOnViewUnloaded Terminate
because it will terminate your vm
and your view is essential a singleton that is never reinitialized.
Just know that getting rid of ElmishViewModel.terminateOnViewUnloaded Terminate
means that graph "auto update" will continue running in the background when you switch tabs. But maybe that's ok if you do want your views to be singletons.
I went ahead and removed ElmishViewModel.terminateOnViewUnloaded Terminate
from all the viewmodels as it was causing the same problem for all of them.
I fixed ChartViewModel.fs
so that AutoUpdate is disabled on view.Unloaded
event (without fully terminating the vm):
let vm =
AvaloniaProgram.mkSimple init update bindings
|> AvaloniaProgram.withSubscription subscriptions
|> ElmishViewModel.create
|> ElmishViewModel.subscribe (fun view model dispatch ->
view.Unloaded |> Observable.subscribe (fun _ ->
dispatch (Msg.SetIsAutoUpdateChecked false)
)
)
Pretty cool that ElmishViewModel.subscribe
gives you a view
, a model
and dispatch
, eh? 😎
That is fascinating... and useful.
On a total side note - as I was clicking through the site I noticed that the color scheme of the button controls in the Chart view had changed, and the "Ok" buttons had gone missing from a few views. I thought it was a good example of that global message but has become a bit ragged now that it's even missing from the About View. Is there any reason for that? It's not a deal breaker - just curious.
Looks like the Ok buttons were commented out in the XPlat views.
Probably because the change to use TabControl
for navigation would break the GoHome
message.
You could hook it back up if you wanted to, but the implementation would have to change.
feel free to mess with that, it didn’t feel as natural to me in a single window flow with tabs but both work and are interesting examples. Am 10/25/23 um 10:22 PM schrieb Jordan Marr @.***>: Looks like the Ok buttons were commented out in the XPlat views. Probably because the change to use TabControl for navigation would break the GoHome message. You could hook it back up if you wanted to, but the implementation would have to change.
Subscribe to GoHome message in MainViewModel Create a "SelectedTab" binding to programmatically set the currently selected tab
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>
You make a good point - it begs the question of what to show in an "example" for interactivity in navigation. I wouldn't necessarily want to over complicate things by having two navigation styles in one app. Does it warrant two branches?
Either way this is relatively new to me so I'm learning as I go.
It's interesting that I got prompted again this morning to do a workload restore and it started pulling bits for .NET7 (which asked my question if those workloads were there for .NET7)
Then I run fun.build and I'm getting the Android .NET6 +7 bits...
PIPELINE CI is finished in 304694 ms
It keeps hinting I have a reboot pending so will do the honors and come back (this is all just to get the Avalonia previewer in VSCode to give me something back - I have Rider but I'm a curious type ) :)
So - rebooted and re-ran fun.build and seemed to go OK other than the fact that after the run the Avalonia extension still doesn't recognize that the project has been built (and therefore the preview should display)
It's also interesting to note that in one case there's an error message in the build-on-boot process where I'm seeing a prompt to go and download wasm-tools-net7 as opposed to what I've seen for other workloads and fun.build just fetching what it needs.
Determining projects to restore...
C:\Program Files\dotnet\sdk\8.0.100-preview.7.23376.3\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.ImportWorkloads.targets(38,5): error NETSDK1147: To build this project, the following workloads must be installed: wasm-tools-net7 [C:\repos\Elmish.Marr.Avalonia\src\Samples\AvaloniaXPlatExample\AvaloniaXPlatExample.Web\AvaloniaXPlatExample.Web.fsproj]
C:\Program Files\dotnet\sdk\8.0.100-preview.7.23376.3\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.ImportWorkloads.targets(38,5): error NETSDK1147: To install these workloads, run the following command: dotnet workload restore [C:\repos\Elmish.Marr.Avalonia\src\Samples\AvaloniaXPlatExample\AvaloniaXPlatExample.Web\AvaloniaXPlatExample.Web.fsproj]
So in a fit of pique I decided to run dotnet workload restore
to see what comes back and it says that everything was successfully loaded.
dotnet workload restore
Installing workloads:
Successfully installed workload(s) android ios macos wasm-tools.
So again I don't want to get wrapped around the axle but it seems like there's a bit of a misalignment between what fun.build is building and what VSCode's Avalonia extension can "see" as having been built.
Sorry for spamming the thread - just an FYI that Rider seems fine.
Oh wait - desktop runs but web fails
C:\Users\h3tec\AppData\Local\Programs\Rider\plugins\dpa\DotFiles\JetBrains.DPA.Runner.exe --handle=8396 --backend-pid=14268 --etw-collect-flags=3 --detach-event-name=dpa.detach.8396 "C:\Program Files\dotnet\dotnet.exe" C:/repos/Elmish.Marr.Avalonia/src/Samples/AvaloniaXPlatExample/AvaloniaXPlatExample.Web/bin/Debug/net7.0/browser-wasm/AvaloniaXPlatExample.Web.dll
A fatal error was encountered. The library 'hostpolicy.dll' required to execute the application was not found in 'C:\repos\Elmish.Marr.Avalonia\src\Samples\AvaloniaXPlatExample\AvaloniaXPlatExample.Web\bin\Debug\net7.0\browser-wasm\'.
Failed to run as a self-contained app.
- The application was run as a self-contained app because 'C:\repos\Elmish.Marr.Avalonia\src\Samples\AvaloniaXPlatExample\AvaloniaXPlatExample.Web\bin\Debug\net7.0\browser-wasm\AvaloniaXPlatExample.Web.runtimeconfig.json' did not specify a framework.
- If this should be a framework-dependent app, specify the appropriate framework in 'C:\repos\Elmish.Marr.Avalonia\src\Samples\AvaloniaXPlatExample\AvaloniaXPlatExample.Web\bin\Debug\net7.0\browser-wasm\AvaloniaXPlatExample.Web.runtimeconfig.json'.
Process finished with exit code -2,147,450,749.
OK - so after putting ALL projects on .NET7 I get web to build - but now it just gives me the "powered by Avalonia UI" splash page and nothing else.
Well I'm out of ideas with the XPlat for now but have the desktop sample app running on .net6 with no complaints. So that's where I'm going to focus for the moment. 👍
Could be that the global.json is affecting things wrt net6/net7?
Could be that the global.json is affecting things wrt net6/net7?
I went through and updated all of the global.json files as well as retargeted the fsprojs and so far only the desktop on .net6 will build and run.
What I'm seeing is some complaints about the Avalonia version not supporting .net6 - I understand why there's a push to get everything on 11.0.5/.NET7 - I'm just not sure "how to square the circle" in the build script such that those dependencies are changed consistently when the target(s) change.
C:\repos\Elmish.Marr.Avalonia\src\Samples\AvaloniaXPlatExample\AvaloniaXPlatExample.Android\AvaloniaXPlatExample.Android.fsproj : error NU1202: Package Avalonia.Android 11.0.5 is not compatible with net6.0-android31.0 (.NETCoreApp,Versio
n=v6.0). Package Avalonia.Android 11.0.5 supports: net7.0-android33.0 (.NETCoreApp,Version=v7.0) [C:\repos\Elmish.Marr.Avalonia\src\Samples\AvaloniaXPlatExample\AvaloniaXPlatExample.sln]
I’ll see if I can get web working again. It has been a while since I checked. My general instinct is to move forward since 8 is nearly here and just troubleshoot 7 but that might be a mistake. Re the ok button, it sounds like having it is more useful and keeps the apps consistent so please feel free to restore that. When I was wiring up the file picker, I was wondering how that would behave on web and mobile and whether it would break those environments. Am 10/26/23 um 7:15 AM schrieb Houston Haynes @.***>:
Could be that the global.json is affecting things wrt net6/net7?
I went through and updated all of the global.json files as well as retargeted the fsprojs and so far only the desktop on .net6 will build and run.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>
well hell - I partially take it back - moving EVERYTHING to .NET7 and upgrading deps on Elmish.Avalonia to Avalonia 11.0.5 meant that XPlat desktop works. There's still the wrinkle of the WASM client not behaving - and Android doesn't like my target being set to <TargetFramework>net7.0-android</TargetFramework>
. I did a little sniffing around SO and the web to see if there's something I can suss out - but no joy for the few things I've tried.
Has the iOS project ALWAYS been a .csproj?
I could have sworn I ran this on my iPhone and it didn't jump out at me at the time.
I haven’t touched it - that’s from the original avalalonia template Am 10/26/23 um 7:40 AM schrieb Houston Haynes @.***>: Has the iOS project ALWAYS been a .csproj?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>
OK - yeah I guess I didn't move the change back to the sample project because I definitely make is an fsproj in my "SunFlwr" project. Sorry about that - pretty high-distraction environment. 😄 I was trying to get Bluetooth to work between the phone and my WildernessLabs Meadow board.
IMO, it's not worth creating a new branch just for that since it already exists in the original non-xplat example.
It would be nice to have a more formalized navigation subsystem baked into the project. The current version works, but is kind of ad-hoc.
A fully-fledged nav system would:
Not sure if that has a place in a library like this, or if it would be more a 3rd party library concern, but it would be nice to have. Might make it a little less like the "wild west".
I agree that we are so close to net8 that we should probably just keep looking forward as much as possible. Especially considering that this is all very bleeding edge. net6 is soon to be behind us!
I had lots of issues with getting the workloads working properly in the build. Unfortunately, what worked on my machine when I ran the script locally did not always work on the build machine.
For example, I originally wanted to just do a dotnet workload restore {sln path}
as that worked locally, but it failed on the build server. I ended up manually installing certain workloads in the build script which made the build server happy.
So, the build.fsx is kind of targeted specifically to the GitHub build environment at this point (for better or for worse).
Workloads are still new to me, (although I am also doing a MAUI project which uses them as well), so I'm totally stumbling along here.
So I re-sync'd my forked repo to yours here and then tried to build and all sorts of things started going sideways. I thought it might have been me doing something wrong in rebasing so I cloned your repo directly and tried do a workload restore and re-build. After giving me some guff about System.ReactiveUI needing to be on 5.0 (which I complied with) I got an entire litany of errors. It's been a while so I'm just wondering if a missed a memo. Any thoughts? Thanks!